Repository navigation
Could the relationship between crypto-common and block-buffer be reversed? #1662
Description
Note: I don't have a concrete proposal here, just spitballing.
One thing that's currently kind of tricky is updating block-buffer, because block-buffer (utils repo) depends on crypto-common (this repo), and digest (this repo) depends on block-buffer.
Would there be a way to reverse that so that crates in this repo only depend on crates in the utils repo, and not the other direction? That would simplify updates.
Alternatively, perhaps crypto-common could go in the utils repo.
Activity
newpavlov commentedon Sep 6, 2024
The only reason why
block-bufferdepends oncrypto-commonis theBlockSizestrait. Moving it into theblock-buffercrate is probably not a good idea. I guess we could replace compile-time check with runtime check or maybe even with a monomorphization error.tarcieri commentedon Sep 6, 2024
@newpavlov what about moving
crypto-commoninto utils?newpavlov commentedon Sep 6, 2024
Well, the crate literally contains "common cryptographic traits", so the utils repo looks like a wrong place for it.
If I am not missing something, it looks like in the new release cycle
block-bufferis used only by thedigestcrate. Maybe we could simply move theblock-buffercode into it?tarcieri commentedon Sep 6, 2024
That works!
block-buffer: remove dependency on crypto-common (#1115)