Replies: 1 comment 4 replies
-
This change is pretty trivial to make, since we don't use the hashing much. Here's a draft PR of what it would look like: #894 I tested against the calculator9 documentation example, and it didn't change the generated hash in that case, which is a good thing. The use of the hashing is just to compare files for possible rebuild. So this isn't a security relevant use of crypto - IMO even an md5 sum would be just fine for this use case. That said, I don't like unmaintained crates. It does seem true to me that the RustCrypto crates are more widely used and actively maintained, while tiny-keccak is not. That said, I'm having trouble finding any sort of general community guidance around appropriate crypto crates to use. The recent xz situation has me a little sensitive to "hey grab this dependency" sorts of asks. I think I'm tentatively in support of making this change. Unmaintained crates are major problems waiting to happen. I'd love to hear some other maintainers thoughts though. |
Beta Was this translation helpful? Give feedback.
-
Disclaimer: new to Rust and lalrpop.
I'm trying to import the lalrpop crate at work but the tiny-keccak dependency is giving our security reviewers some pause.
Will you be willing to migrate lalrpop from tiny-keccak to the sha3 crate?
The comments given were: "... more comfortable if we were importing the sha3 crate instead. Indeed, there hasn't been a commit in almost 4 years in https://github.com/debris/tiny-keccak, and conversely the RustCrypto organization has a track record of actively maintaining its crates, and of avoiding unsafe code whenever possible (e.g. https://github.com/RustCrypto/hashes/blob/master/sha3/src/lib.rs#L8). The RustCrypto crates are actively maintained and in this particular case the sha3 crate avoids unsafe code and has an extensive test suite."
Thanks!
Beta Was this translation helpful? Give feedback.
All reactions