Could the relationship between `crypto-common` and `block-buffer` be reversed?
tarcieri opened this issue · 4 comments
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.
The only reason why block-buffer depends on crypto-common is the BlockSizes trait. Moving it into the block-buffer crate is probably not a good idea. I guess we could replace compile-time check with runtime check or maybe even with a monomorphization error.
@newpavlov what about moving crypto-common into utils?
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-buffer is used only by the digest crate. Maybe we could simply move the block-buffer code into it?
That works!