AutoMerge feature request: Sanity check uuid for new packages

[GunnarFarneback]

UUIDs are standardized by RFC 4122 (and the recent followup RFC 9562) and it's a reasonable expectation that the uuid of a new Julia package should be generated by Julia's UUIDs stdlib, or if not still by a standards compliant generator. Most of the bits in a uuid are either random, timestamps, or random-looking, but there are some bits that are fixed by the specification. Specifically A and B marked below.

UUID("b1a8f88b-5968-4b8b-b9e8-905bb0cccf64")
                    A    B

A is the 4 bit version field. RFC 4122 defines versions 1-5. RFC 9562 adds 6-8. Julia 0.4 and later can generate versions 1 and 4. Julia 1.1 added version 5 and Julia 1.12 will add version 7.

The top two bits of B must be 10 if either RFC is followed, called the variant. I.e., B can be either 8, 9, a, or b.

Unfortunately Julia's version 1 implementation has been buggy (fix in JuliaLang/julia#59428), setting the variant bits to 00 instead of 10.

Realistically we must accept Julia's incorrect uuid version 1, so a sanity check for automerge of new packages could be

using UUIDs: UUID, uuid_version
function uuid_passes_sanity_check(uuid::UUID)
    version = uuid_version(uuid)
    variant = Int((uuid.value >> 62) & 0x3)
    return (variant == 2 && 1 <= version <= 8) || (variant == 0 && version == 1)
end

Addendum: 34 of the currently registered packages in General do not pass this sanity check. Obviously we cannot do anything about that.

[StefanKarpinski]

It always bothers me when there are UUIDs in General that were clearly not generated correctly, so would be great to check this.

I think that we could at some point stop accepting new UUID1 values that aren't correct.

It might also be good to do some compression testing on UUIDs that are supposed to be random and maybe some testing that time-based UUIDs have reasonable time values.

[GunnarFarneback]

I tried some retrospective analysis of the compressibility of existing uuids, using

using UUIDs: UUID
using CodecZlib: DeflateCompressorStream
compressed_length(uuid::UUID) = length(read(DeflateCompressorStream(IOBuffer(string(uuid)))))

The length distribution is

length	frequency
19	1
21	1
33	6
34	13
35	129
36	998
37	754
38	10683

The two most compressible are clearly written, or at least edited, by hand (and fail the sanity check):

19: 00000000-1111-2222-3333-444444444444
21: 8ac6971d-971d-971d-971d-971d5ab1a71a

The ones compressible to 33 bytes look more or less suspicious.

33444335-3134-4342-4659-594331344435
656a7065-6f73-6c65-7465-6e646e617262
72656b73-756c-7461-726b-72656b6b696b
72696420-646e-6120-6e77-6f6420746567
aaaaaaaa-4a10-5553-b683-e707b00e83ce
aaaaaaaa-a6ca-5380-bf3e-84a91bcd477e

Among the 34 bytes ones I'd say that most, but not all, look plausible to be correctly generated.

[StefanKarpinski]

Those long sequences of a's sure look funny. The others are less clear cut but I agree they look suspicious. 34 seems like a good cutoff. We always have the option to override the check.

[ericphanson]

uuid_passes_sanity_check seems like a good guideline to add for new packages

[ericphanson]

#631 gives access to the uuid, which surprisingly we did not have before for new packages (since it requires parsing the Project.toml; it's not in the registry yet, nor the PR body). So this check would be relatively easy to add once that PR is in. (it would run after check_project_toml, pull the ProjectInfo field from the data object, and validate the uuid field of it).