zeroize MSRV bump

[djc]

zeroize is used in relatively low-level libraries like rustls where we'd like to maintain a somewhat conservative MSRV (for example, to accomodate stable Debian). Recently, zeroize 1.8.0 was released which contained #1052 which bumps the MSRV from 1.60 all the way to 1.72. Would you be open to supporting older Rust versions, perhaps by adding a default-enabled feature for the __m512 stuff that downstream users who want to stick to something older can disable?

[tnull]

Yes please, a dependable and tested MSRV guarantee would be much appreciated as this currently breaks our MSRV (1.63) builds downstream of rustls.

[newpavlov]

We also could detect Rust compiler version using build script and gate implementations for types like __m512 on it.

[djc]

Yup, that's another option -- though it requires another compilation unit.

[tarcieri]

I'd prefer not to add hacks and complexity and additional compilation units, especially things that we can never get rid of like features just to work around MSRV. That's what we did for aarch64 and now we have a vestigial aarch64 feature that does nothing forever, or at least until a prospective v2.

When is rustls planning on bumping MSRV? I can yank this release and wait a bit longer. I had hoped N - 5 versus stable was enough but apparently not.

[tarcieri]

for example, to accomodate stable Debian

FWIW as someone who runs dozens of bare metal Debian servers, I've found their packaging of Rust to lag far too behind the latest releases to be usable for anything we want to compile. We use rustup to provision a container for doing Rust builds, and bump it whenever there's a Rust release.

That's my 2c anyway. I get why rustls wants to support the latest Debian without rustup, but IMO it's a Debian problem.

[tnull]

When is rustls planning on bumping MSRV? I can yank this release and wait a bit longer. I had hoped N - 5 versus stable was enough but apparently not.

As a downstream user I can only say "hopefully not anytime soon" as it would mean considerable pain for us. We have to support current computing platforms such as Debian bookworm, so bumping the minimum version to rustc 1.72 which was only released less than a year ago isn't feasible for us.

[tarcieri]

I yanked v1.8.0.

I hope we can release it again before we do our next big batch of all of our crate releases, but that's probably still several months off.

[tnull]

I yanked v1.8.0.

I hope we can release it again before we do our next big batch of all of our crate releases, but that's probably still several months off.

Thank you for the fast response and your understanding!

[djc]

When is rustls planning on bumping MSRV?

That might take a while -- we just bumped to 1.63 from 1.60 or 1.61, and we don't have many dependencies upstream of us that will force us to move faster.

I can yank this release and wait a bit longer.

Thanks!

[tarcieri]

How about releasing at N - 10, i.e. with the release of Rust 1.82, on October 17th, roughly 6 months away? That release is supposed to correspond to the 2024 edition as well.

That will likely still predate Debian 13 which currently only supports Rust 1.70.

[djc]

The previous Debian stable jump was from 1.48 to 1.63, so I think the next Debian stable will definitely move beyond 1.72, but it likely won't be released before around the summer of 2025, so I'm not sure we'll be able to take 1.72 in 6 months. But, let's discuss what the landscape looks like in 6 months?