MSRV in the future

[reaperhulk]

When we added Rust to cryptography we originally required a rustc of >=1.45. Through initial feedback we dropped this MSRV to 1.41 to ease the transition. Time, however, marches ever onward. We will need to update it in the future (and in version 38.0 we've announced an increase in MSRV to 1.48). How conservative should we be moving forward?

Some data: Wheels vs sdists

A very large percentage of our users obtain a wheel. Here is the last 30 days of downloads:

Within just the Rust-required versions (35+):

Due to the sheer volume of downloads even a less than 2% sdist rate results in nearly 2 million sdist downloads. It is that <2% (along with distribution packagers) who are potentially affected by choices around our MSRV.

Advantages of conservatism

Users who do not receive a wheel need to install a compatible rustc. With newer version requirements the odds of needing to use rustup rather than the system package manager increase. Ubuntu backports newer rustc, but most other distributions do not. Additionally, users who do compile (and do not use CI systems where newer rust is automatically installed and upgraded over time) will occasionally have their systems break due to an MSRV increase.

Advantages to aggressive upgrades

Some potential features and performance optimizations are gated behind newer rustc versions. For example, support for SSH certificate parsing could be added via ssh-key, except the MSRV is 1.57. Similarly, we've had multiple PRs to our own asn1 crate blocked by MSRV concerns:

• Fixes #236 -- switch from using chrono to time alex/rust-asn1#239 is blocked until 1.51
• OID macro! alex/rust-asn1#181 merged only after our decision to move to 1.48

I am tentatively in favor of being significantly more aggressive in our MSRV, but Alex and I are both interested in hearing from the community.

[simo5]

That <2% may very well be a gateway to a much higher amount of users using cryptography via packaged distributions.

Packaged distributions tend to stay on a stable if not oldish version of Rust, although not too old, because the whole ecosystem is constantly pushing to adopt new versions of rust as well.

Rust 1.48 was released Nov. 19, 2020
I think if you keep a 18mo old release as guidance that should give time to all to adopt, probably 12mo is also acceptable.
Unfortunately that would mean stalling that rust-asn1 almost another 6 months on the 18mo lag, while it would be mergeable now on a 12mo lag base.

[reaperhulk]

@simo5 is the concern for packagers the backports style repositories? For distributions that package and then do not update (except for security patches) until the next major distribution release I would expect that rustc and the shipped cryptography version would remain compatible?

[simo5]

@reaperhulk I can talk for all distributions, but I can tell that in RHEL we simply can't handle a single fixed in stone rust version per major release (that's 10 years) at this time.
The toolset teams in RHEL periodically update the rust version and there is a somewhat special exception there.

The simple reason is that we need to ship Firefox and Firefox does not wait forever.
I guess if you align your rust version requirements to what mozilla does for Firefox that could be fine ...

I do not know how something like debian stable handle this.

A distribution that freezes everything and only does security backports is not something you should be concerned about, they would freeze the version of cryptography as well.

[reaperhulk]

@simo5 Is there an easy way to determine what the ESR Firefox MSRV is? That would be interesting to understand.

[reaperhulk]

Actually, https://firefox-source-docs.mozilla.org/writing-rust-code/update-policy.html contains the information needed. Since current ESR is Firefox 91 this would appear to mean 1.51 would be acceptable?

[simo5]

For Firefox 100 1.57 is required, so 1.51 is certainly acceptable

[simo5]

uhm you are right on the ESR one though, and the new ESR I think will come out in early summer, so I predict in a couple of months at least 1.59 will be acceptable.

[alex]

A review of the PyPI download data suggests that it's very common for users to install our sdists with a rustc version installed from their distributions packages manager. These versions tend to be older (e.g. debian buster, supported for another 2 years, still contains rustc 1.41.0).

While I am not advocating for no increases to our MSRV (I support the 1.48 bump that's coming in 38!), I do think we need to be a little conservative and probably can't be quite as aggressive as Firefox.

[alex]

We have the required input here.