Deprecation of `GenericArray` in v0.14.8 causes big problem with `aes` create (and probably others)

[lordmulder]

The problem is that current latest version of aes requires generic-array v0.x and can not use version v1.x.

So we are forced to stick with generic-array v0.x, which is also re-exported from current latest cipher::generic-array.

But this will now suddenly trigger a deprecation warning!

For everybody following the general recommendation to build with -Dwarnings this will cause the build to fail 😥

See also:
RustCrypto/block-ciphers#509 (comment)

Regards.

[novacrazy]

This is intended. 1.x has been available for two years now. 0.14 is indeed deprecated.

Edit: See #158 (comment) for more info on this decision.

[newpavlov]

I believe this creates unnecessary friction for downstream users (same as yanking old versions, which was infamously done by the ring crate). Use of outdated crates can be found using separate tools (e.g. cargo outdated or deps.rs badges). Annoying users with unconditional deprecation warnings is a bad way to force updates which may be buried deep in their dependency tree.

In RustCrypto we migrated from generic-array to hybrid-array, but haven't released new versions yet (not counting pre-releases), so users have no options but to continue to rely on generic-array v0.14 in the near future.

[bugadani]

Besides being rather rude to a number of users, the deprecation warning is actually a semver-breaking change:

7. Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backward compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated.

[maxdexh]

Besides being rather rude to a number of users, the deprecation warning is actually a semver-breaking change:

7. Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backward compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated.

Your quote specifically includes x > 0 as a requirement for needing to bump Y in x.Y.z. In 0.x.Y, the last number is the minor release number, not the patch number. So this was fully semver compliant.

Edit: Just to note, this is not a statement of whether I agree with the change, I personally would probably not have made this change, because of the linter's lack of configurability over deprecation warnings. Sadly there is no better option for library authors at the moment.

[maxdexh]

As a suggestion, maybe add a feature flag to disable the deprecation warnings?

[lordmulder]

The problem is, when there is a deprecation warning, then there should be a proper alternative that we can actually use to get rid of the deprecation warning and still achieve what we used to be able to achieve.

Unfortunately, using the latest version of GenericArray v0.x gives a deprecation warning, but it is not possible to resolve this by using GenericArray v1.x instead, because essential crates, like aes (latest stable version!) can not work with it:

error[E0308]: mismatched types
    |
 40 |     let cipher = Aes256::new(GenericArray::from_slice(&full_key));
    |                  ----------- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `&GenericArray<u8, UInt<..., ...>>`, found `&GenericArray<u8, _>`
    |                  |
    |                  arguments to this function are incorrect
    |
note: two different versions of crate `generic_array` are being used; two types coming from two different versions of the same crate are different types even if they look the same
   --> C:\Users\user\.cargo\registry\src\index.crates.io-1949cf8c6b5b557f\generic-array-1.3.3\src\lib.rs:470:1

Pinning generic_array to version 0.14.7 in my Cargo.toml of my lib also is not a good idea, because the "main" application may also be using generic_array but would likely use the latest version (i.e. 0.14.8) which gives version requirement conflict!

---

Also, please be aware that cipher::generic_array (in the latest stable version of cipher) re-exports the now deprecated GenericArray v0.x, probably giving this deprecation warning to everybody using cipher right now.

---

As a suggestion, maybe add a feature flag to disable the deprecation warnings?

IMHO, that sounds like overengineering.

Please just let generic_array v0.x and v1.x exist "side-by-side". Only use deprecation for things that are deprecated within each branch (major version) and that actually can be "fixed" within the respective branch (major version).

I think that would be the "semver" way of doing things.

TTBOMK, users should never be forced to "upgrade" to a new major version of a library in order to resolve a deprecation warning. That is because, in "semver", different major versions of a library are essential totally different (non-compatible) libraries – and there may be good reason why you can't simply switch to a different library. It could break other things 😨

Regards.

[Turbo87]

but it is not possible to resolve this by using GenericArray v1.x instead, because essential crates, like aes (latest stable version!) can not work with it

FWIW that is not a problem of this crate, but a problem of the aes crate which is still using the old version. I don't think we should blame the generic-array maintainers for that 😉

[lordmulder]

but it is not possible to resolve this by using GenericArray v1.x instead, because essential crates, like aes (latest stable version!) can not work with it

FWIW that is not a problem of this crate, but a problem of the aes crate which is still using the old version. I don't think we should blame the generic-array maintainers for that 😉

IMO, the whole point (or at least an important point) of "semver" is that you don't break things in retrospective.

At the time when aes was created, generic_array v0.x was the "proper" thing to be used. And now you should not break that existing library, in retrospective, by suddenly changing the dependency in an incompatible way. For as long as existing libraries use generic_array v0.x, they are free to do so and that is perfectly fine. These libraries should not get a deprecation warning - unless there is a better replacement for the deprecated function or type within the v0.x branch of generic_array.

Maye, at some time in the future, there will be a new major version of aes that uses generic_array v1.x. But even then, you can not expect everybody to "upgrade" to that new major version of aes immediately. Users may have a good reason to stick with the previous version major version of aes, which means they will still depend on generic_array v0.x. And rightfully so.

I think depreaction should exclusively be used to mark functions and types for which there is a better alternative already available in the currently used version of the library. It should not be used to force people to upgrade to a new major version of the library, which (in "semver") is essentially a totally different library and therefore is expected to break all sorts of things...

Regards.

[Turbo87]

I agree on your definition of semver, but this library has not broken anything. A deprecation warning is a warning, not an error, and does not prevent you from compiling the library. If you use -D warnings to turn warnings into hard errors then that breakage is not caused by the library.

That said, since the compiler can only be configured to warn or error for deprecations in general, but not for specific deprecations, this change is still causing quite a bit of friction, since there is not much the end-user can do about it.

Then again, I can understand that the library author wants to nudge people into using a supported version of this crate. Especially since this crate is used in a lot of cryptographic libraries, it seems a bit unfortunate that they all still depend on the old, unsupported library version.

[novacrazy]

If there were a more gentle approach that actually worked, I’d consider it, but RustCrypto in particular was one of the first to be aware of 1.0, personally. There were conversations on reddit and Discord over two years ago (some of which are lost now thanks to restructuring) when I was looking for feedback on the 1.0 PR, that dismissed 1.0 saying “hybrid-array” was almost complete even at the time and they’d not bother with anything else.

There have been no improvements to 0.14 in over two years, and a massive player in the ecosystem has prevented almost all users from enjoying 1.x.

[newpavlov]

In RustCrypto we finished migration to hybrid-array more than a year ago, the crate releases got delayed for a number of reasons, but even if they were already released, users would still not "enjoy" generic-array v1.0, since they would use hybrid-array instead. I really doubt that RustCrypto crates somehow inhibit adoption rate of generic-array v1.0 in practice.

Harassing users with the deprecation warning serves little to no purpose and will not result in any additional adoption from the RustCrypto side. If anything, such behavior only made me glad that we made the decision to drop the generic-array dependency from our crates.

Keeping dependencies up-to-date in downstream crates is responsibility of the downstream crates, not of their upstream dependencies.