Tracking issue for next release series

[tarcieri]

This is a tracking issue for the next set of breaking releases which are currently under development on the master branch.

These are somewhat interdependent on RustCrypto/traits#1571 as noted below:

• block-buffer v0.11 (depends on crypto-common v0.3)
• block-padding v0.4 (depends on hybrid-array v0.3 v0.4)
• dbl v0.4 v0.5 (depends on hybrid-array v0.3)
• inout v0.2 (depends on block-padding v0.4)

[tarcieri]

@newpavlov I'm wondering if we can cut final releases of some or all of these now and start getting the ball rolling on stable releases

[newpavlov]

One potentially unresolved problem with block-buffer is efficient serialization of eager buffers (current version of digest serializes eager buffer into block size + 1 byte, while block size would be sufficient). Right now we have inherent serialization methods, but unfortunately they are a bit hard to combine with implementation of SerializableState. I will try to work on it during this weekend.

I also thought about moving buffer implementation used by the stream cipher wrapper to block-buffer, since it's the only place in cipher which uses unsafe.

Another change which I would like to introduce is a minor change to the blobby format as noted here.

Finally, regarding dbl, we probably should make a decision on #1077. It does not prevent us from cutting a release and deprecating it later, but I think it would be better to not cut a potentially quickly deprecated release.

Otherwise, I don't have objections to cutting the releases.

[tarcieri]

@newpavlov where are we on this now?

[newpavlov]

I thought about cutting releases after fixing RustCrypto/AEADs#716.

[newpavlov]

I opened #1217 after inspecting the block-padding code for one last time before creating a release PR.

Another potential change for block-buffer: constitfication of methods. It could be useful for RustCrypto/hashes#288, e.g. if we decide to provide free-standing hashing const fns in our crates. Unfortunately, it would involve a rework of the Lazy/Eager traits since we do not have const impl, so it requires some experimentation.

[newpavlov]

Unfortunately, it's not possible to constify the BlockBuffer::digest_blocks method on the current stable Rust. It accepts a generic closure, so we need at least ~const bounds. There is also a problem with const destruction, but it can be worked around by passing a reference to closure.

[newpavlov]

#1221 is not a blocker, but it would be nice to fix as part of the v0.4.0 release.

[baloo]

I know you already said it was not a blocker, but it looks ready.

Is there anything left before a release of block-padding other than #1222 ?
It looks like that's the last thing and it should unblock every other crate here?