Depreaction 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.

[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 know 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.