Update RustCrypto crates #6
Conversation
| H: Update + FixedOutput + CoreProxy, | ||
| H::Core: HashMarker | ||
| + UpdateCore | ||
| + FixedOutputCore | ||
| + BufferKindUser<BufferKind = Eager> | ||
| + Default | ||
| + Clone, | ||
| <H::Core as BlockSizeUser>::BlockSize: IsLess<U256>, | ||
| Le<<H::Core as BlockSizeUser>::BlockSize, U256>: NonZero, |
There was a problem hiding this comment.
Can you explain these new constraints?
There was a problem hiding this comment.
I mainly copy-pasted them from Hmac https://docs.rs/hmac/latest/src/hmac/optim.rs.html#20-36
| let mut mac = <Hmac<H> as Mac>::new_from_slice(secret).unwrap(); | ||
| <Hmac<H> as Update>::update(&mut mac, &to_bytes(time / step)); |
There was a problem hiding this comment.
It is still a method, but both the Update and the UpdateCore traits implement update, so I had to let the compiler know which of the two implementations to use
|
Nice, thanks @paolobarbolini, I was looking through the dependencies of Vaultwarden, and saw an easy update on duplicate crates here. This saves me creating an PR ;). And @fosskers thanks for this crate, works really nice with Vaultwarden, would be great to have an updated release! |
|
I just released |
Shouldn't it be |
|
Could a break actually occur? Even if they imported say |
Nope, because the traits are from a different version of the |
|
|
It might be improbable, maybe nobody will ever complain about this release, but upgrading a public dependency in a backwards incompatible way is a breaking change. It's annoying sometimes but it gives strong semver guarantees 😃 |
|
Well I wouldn't want to break semver. So be it, I just released |
No description provided.