Backport (security) fixes and release 1.26.3

[dekellum]

Before flat out denying this request, please give people time to provide situational reasons for or express pros/cons. Thank you!

[dekellum]

Background

From the Announcing Rust 1.27 blog post:

Additionally, we would like to draw attention to something: just before the release of 1.27.0, we found a bug in the ‘default match bindings’ feature introduced in 1.26.0 that can possibly introduce unsoundness. Since it was discovered very late in the release process, and has been present since 1.26.0, we decided to stick to our release train model. We expect to put out a 1.27.1 with that fix applied soon, and if there’s demand, possibly a 1.26.3 as well. More information about the specifics here will come in that release announcement.

(emphasis mine)

The Announcing Rust 1.27.1 blog post doesn't mention 1.26.3

A users forum: Rust 1.27.1 is out! thread linked to that post, has a response from @Mark-Simulacrum which sounds a bit less supportive of a 1.26.3 release.

[pietroalbini]

Why do you need a 1.26.3? Not trying to be dismissive, but if we do that there should be a pretty strong argument for it, especially because 1.27 has been released for some time and we're approaching 1.28.

[dekellum]

Motivation

For some published crates, I have an update policy of supporting the last 3 minor (M.m) stable releases. This policy is not unlike other prominent projects see tokio-rs/tokio#465 and its policy which is similarly expressed in CI, as an established standard, for lack of cargo support. As the discussion of tokio-rs/tokio#465 suggests, these policies must be stable for dependency crates, as they can have long reaching effects. For example, for the body-image crate, I updated the minimum rust support to 1.26.x for my 0.3.0 release which now uses impl Trait. It has been argued that if I was to increase the rust dependency again (say to 1.27.1) that I would need to publish it as a 1.x release. See rust-lang/api-guidelines#123 , this comment and also this. See also RFC 1619, this comment.

Your well intended stewardship and guidance has lead to this rather significant meaning of "1.26" that can not be adequately subsumed by and patched via "1.27.1". We need a "1.26.3" because your guidance and the ecosystem actors have made that a meaningful distinction.

Its also a practical and valuable distinction if you step back a little and consider the meaning and spirit of semantic versioning. There is a real and practical reason we reserve the patch release number for bug fixes. There is therefore a reason for a rust version dependency that allows for few M.N releases prior: stability! In fact it was made clear that the 1.27.1 release fixes issues arising from new features added in 1.26. There is similarly a chance for regressions to be induced by new 1.27 features like SIMD.

From the detailed release notes of 1.27.1, here are the things I believe should be backported to a 1.26.3 patch fix release:

• rustdoc would execute plugins in the /tmp/rustdoc/plugins directory when running, which enabled executing code as some other user on a given machine. This release fixes that vulnerability; you can read more about this on the blog. Thank you to Red Hat for responsibly disclosing this vulnerability to us.

• The borrow checker was fixed to avoid an additional potential unsoundness when using match ergonomics: #51415, #49534.

[cuviper]

My understanding is that match-ergo code which compiles successfully with the newer rustc should also be fine with the 1.26.x releases. In other words, the older ones would allow things that they shouldn't, but truly correct code should be fine either way.

[Mark-Simulacrum]

rustdoc would execute plugins in the /tmp/rustdoc/plugins directory when running ....

This change presumably does not affect library authors in that if you support 1.27.x then downstream users can utilize this patch. Rust does not currently support anything except for the last stable release for security and other similar patches; distros are of course welcome to backport as much as they want.

The borrow checker was fixed to avoid an additional potential unsoundness when using match ergonomics ...

This change (like @cuviper says) only stops incorrect code from functioning; if your library compiles on latest stable and 1.26.2 then it will do the right thing on 1.26.2 as well; the borrow checker does not affect the code generated.

So, I think that any given library which wants to support 1.26.x can continue to do so without an additional 1.26.3 release with backports from 1.27; we have not changed functionality in such a way that a correct library (i.e., a compiling one on latest stable) will function correctly or only on one of these releases.

Do you have arguments against that position?

[dekellum]

I think I understand your position, but it considerably weakens the minimum rust version promise that I'm attempting to offer users, and their expectations, if they can't find a patched version of 1.26.x without security or soundness problems? Makes me look the fool that should have stayed on 1.25 and avoided using 'impl Trait'. To recast this as a fairness argument: it seems you've guided the ecosystem toward stringent minimum rust vesrion policies while also not being willing to backport. Is it really super difficult to produce a 1.26.3 with these fixes in place? If so, what's the root cause of that difficulty? Can I help (beyond shutting up here)?

[Ixrec]

I thought every version of Rust since 1.0 has had some known soundness bugs. For example, #10184 and #18510 and #27282 have been known for years (though now all of them have at least one failed or upcoming attempt to fix).

[dekellum]

Yet another way of saying it: Your position effectively is an End-Of-Life for rust 1.26.x. I wouldn't have bumped my minimum version to 1.26.x if I knew that EOL was coming so soon. I would have instead waited to see if 1.27 or 1.28 were effectively stable for practical use.

[cuviper]

Rust doesn't do LTS (yet). Every release except the current stable is EOL, if you want to think of it that way.

[dekellum]

"LTS" is a straw-man conflation of what I've asked for here. Industry use of Long Term would imply at least a 1 year of Support, but 1.27.1 is the latest stable, and 1.26.3 is only one minor release prior, with 1.26.0 released May 10, 2018 (2 months ago).

If you on one hand think it reasonable that ecosystem crate libs have minimum rust version policies like 2 or 3 stable releases from the latest stable, then you shouldn't, for consistency and practical application, be unwilling to patch that many stable releases back.

Applying your position on 1.26.3 as precedent, logically also effects the practical direction of rust-lang/api-guidelines#123 and any future rebirth of rust-lang/rfcs#1619.

Close this if you prefer.

[Mark-Simulacrum]

I think what (my, at least) confusion with your request is rooted in is that I don't understand how a library supporting compilation on 1.26.x is affected by future patches to the compiler. While there may be soundness bugs in a 1.26.x compiler, or security flaws, that's the users decision. The library may want to test itself on nightly to make sure it does not contain code that accidentally exploited any unsound behavior, but that does not affect the minimum version of Rust it supports.

With that in mind, can you explain why these patches would be necessary?

[dekellum]

In practical terms I think a known security issue (rustdoc is part of compiler or part of an effective rust runtime?) and soundness compiler bugs have a chilling effect on users when they are making decisions on when and what to upgrade to (in development, CI, and production), and if a library's minimum rust is acceptable.

You may not think this request is reasonable now, but like it or not, you are going to receive more requests like this when something like rust-lang/rfcs#2495 is implemented.