Julia: what to do with UUID?

[StefanKarpinski]

Once https://github.com/JuliaLang/julia/pull/25455 is merged, we'll depend on UUIDs in Base, so the type definition and basic methods have to be moved back out of Random. Should we have a UUIDs stdlib package and add methods for the other ways of generating UUIDs, but leave the type definition in Base for internal use? We already have working code for UUID versions 1, 3, 4 & 5 and version 2 seems to be pretty marginal, so we have pretty complete UUID support already, it could just stand to be wrapped up a little more nicely.

[StefanKarpinski]

One issue is that uuid3 and uuid5 depend on having MD5 and SHA1 implementations, respectively.

[JeffBezanson]

+1 for a UUIDs stdlib package.

[StefanKarpinski]

That seems to imply moving SHA.jl into the stdlib as well – @staticfloat, would that be ok with you? Any chance you'd be willing to move it? If you do, I can add support for the uuid5 method that I've implemented in Pkg3:

https://github.com/JuliaLang/Pkg3.jl/blob/b4df8a26b431a1ffb9b8a62f3a538aa2d044eea3/src/Types.jl#L23-L36

The other thing we'd need for uuid3 is MD5. Of course, we don't actually have to do all of this right now: we can create stdlib/UUIDs now with uuid1 and uuid4 from Base and later add uuid3 when we add stdlib/SHA and uuid5 when we add stdlib/MD5.

[staticfloat]

I'm going to bring @oxinabox in on this as well, as he has very recently built MD5.jl that shares a lot of code with SHA.jl. There's been a bit of an existential crisis around this in that I wasn't too keen on turning SHA.jl into a generic cryptography grabbag, but at the same time, it makes sense to not reinvent the block hash wheel for every digest function in the universe.

All that being said, I'm in favor of moving as much as makes sense into the stdlib; since these different UUIDs require two different hash functions (that seems strange to me btw; why do we need both SHA2 _and_ MD5?) perhaps we should create a Crypto package that has the necessary primitives, and has SHA/MD5 and whatever other digest functions on top easily accessible from the stdlib? I believe this is essentially what Lyndon wanted to turn SHA.jl into originally.

[StefanKarpinski]

it makes sense to not reinvent the block hash wheel for every digest function in the universe.

😂

We don't really need both uuid3 and uuid5 except that it seems suboptimal for a standard library UUIDs package not to implement all the standard UUID-generation methods (there's also 2 which seems to be standardized in some other document and not very widely used).

[StefanKarpinski]

I don't think it would be that terrible for a SHA package to include an MD5 implementation. It's kind of a legacy hash function at this point anyway.

[nalimilan]

I would find it more natural to use a broader name, e.g. Hashing/Hashes/HashingAlgorithms. That way when SHA will have been cracked in 2050, we won't have to release Julia version 26.0 just to rename that module.

[StefanKarpinski]

But is it going to implement all possible hashing functions? We can continue to have SHA in the stdlib as a legacy thing and just add modules for newer hashing algorithms.

[staticfloat]

How about we make something like CryptoSupport that has the common stuff
between SHA and MD5, then have the SHA/MD5 specific stuff in its own
module, and have all of that live in stdlib?

On Tue, Jan 16, 2018 at 2:19 PM, Stefan Karpinski [e-mail]
wrote:

But is it going to implement all possible hashing functions? We can
continue to have SHA in the stdlib as a legacy thing and just add modules
for newer hashing algorithms.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/JuliaLang/julia/issues/25590#issuecomment-358126898,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAH_aF-8PM1Cniu0GnVakn_JZiuSRfvSks5tLSBZgaJpZM4RgTRB
.

[StefanKarpinski]

Adding to the 1.0 milestone with the "stdlib" label, which means that this doesn't block a feature freeze since UUID isn't exported from Base and this only affects the standard library, but should get done before we do a final 1.0 release.

[o314]

How about we make something like CryptoSupport that has the common stuff
between SHA and MD5, then have the SHA/MD5 specific stuff in its own

We have an id generator that do not use crypto hash but a crypto random number generator (ie arc4random ). It would be great if we can plug it too.

I don't know if its possible in this timeframe.

FYI, here is the state of the crypto rng used to compute each new generated random

mutable struct Arc4random
    s :: OffsetArray{UInt8}
    i :: UInt8
    j :: UInt8
end