-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
what to do with UUID? #25590
Comments
One issue is that |
+1 for a UUIDs stdlib package. |
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 The other thing we'd need for |
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 |
😂 We don't really need both |
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. |
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. |
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. |
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 ***@***.***> 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
<#25590 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAH_aF-8PM1Cniu0GnVakn_JZiuSRfvSks5tLSBZgaJpZM4RgTRB>
.
|
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. |
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 |
Once #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.The text was updated successfully, but these errors were encountered: