I must caution to please do not underestimate how much effort supporting such kinds of LTS needs. When we say LTS toolchain, what components in the Rust toolchain are we talking about? The bare minimum of {rustc, std}? The full distributed toolchain {rustc, std, cargo, clippy, rustfmt, ...}? The full toolchain + source included, including e.g. bootstrap?
I want to mention this because some of these components have chronically low maintenance bandwidth and are really difficult to backport certain patches for. E.g. as a volunteer maintainer I have approximately negative interest in dealing with LTS stuff (e.g. I don't even want to take up contracting even if Foundation or such is willing to pay for LTS support), supporting the latest {stable, beta, nightly} is already a ton of work. In particular, volunteer maintainer review time and debugging time is not free! They are donated.
My preliminary proposal is that the LTS would support the components which are a stable and supported part of the stable channel (and which the recommended way to use those components continues to be through the rustup distribution) for the LTS period (e.g. one year). Support would initially be the same as what the requirements for a stable backport are, i.e. security vulnerabilities when running the compiler (treating all compiled Rust code as trusted) and any severe stable-to-stable regressions. If a stable fix wouldn't merit a backport and we'd just tell people to update, then it shouldn't get an LTS backport.
Just like you don't need to use an LTS compiler toolchain to successfully build and maintain LTS software, we don't necessarily need to provide LTS for x/bootstrap to provide LTS for the toolchain it builds. Even if we do, it'd only need to be for x dist.
I'm working on a survey to try and get an understanding of what actual potential LTS customers expect when they hear "Rust LTS" mentioned. One of the questions is what software components the respondent expects to be supported. The current options are each rustup components, some "feels first-party" crate packages[1], and a write-in option.
Do excuse me being slower to respond this week and next — I'm moving in with my significant other. We're super excited, but there's a lot to do right now.
Crates like cc, libc, log, and regex. I have no intent of suggesting that "Rust LTS" should cover crates other than the stable sysroot; this is to help understand what enterprise users think they'd be getting from a Rust LTS and to understand their price expectations relative to that. ↩︎
The main thing that's unclear to me is which patches would be considered for backports. You said "security patches", but what does that mean? rustc itself is defined to trust its input so does that mean by definition we'll never backport compiler patches? In the past we've had CVEs for cargo issues (I guess that makes sense, it does network stuff), and for some standard library issues -- so are those also eligible for a backport? I don't think we ever had a CVE for a rustc issue. But is "has CVE" the right thing to look at? We certainly had point releases for things that are not CVEs, and arguably not security issues.
I would consider miscompiles to be security issues if they have more than a trivial chance of introducing security issues into the code being compiled. (For example, a bug which causes the compiler to sometimes forget to generate a bounds check would from my point of view be fairly clearly a security issue.)
There is no way we can commit to backporting miscompile fixes. Those often need LLVM upgrades or non-trivial changes to optimizations. If you want miscompile fixes, you need to live with the risk that those fixes may cause other problems.
For the spirit of LTS? Probably not. For satisfying the requirements that lead to requiring the usage of LTS? Quite possibly so, because now every patch to LTS can point to the documented problem it fixes for the needed justification for deploying the targeted change.
Wasn't there one where we were loading plugins automatically? Or was that also a cargo issue?
That was for rustdoc and it didn't require any particular code as input. It was loading from the world writable /tmp, so anyone on the same machine could exploit it to run code as someone who runs rustdoc: Security Advisory for rustdoc | Rust Blog
Now I'm wondering whether an LTS LLVM might be more useful than an LTS Rust.
Some miscompiles are caused by mir-opts (in which case they can presumably be safely fixed simply by disabling the optimisation in question), or undefined behaviour in the standard library (which I think could reasonably be fixed as a security fix), but LLVM is probably responsible for most of them. As such, it seems like the "low-risk updates only" nature of an LTS would likely be more useful on LLVM than on rustc (and in particular, if there isn't an LLVM version receiving low-risk updates only, then it is hard to see what backend an LTS rustc could depend on).
IINM LLVM LTS would have the same-ish problems, that backports can be not at all trivial, and for miscompile fixes their backports are at times not low-risk at all
LLVM is a good point. I don't think LLVM does any kind of long-term support, they only ever do patch releases for the latest version. They release a new version every 6 months. So we'd have to do the support work ourselves for at least another 6 months after that. That's not something we have the capacity to do, I think.
So I think we should be very clear that there will be no miscompile fixes, except when a miscompile can be fixed with a trivial revert (but those we usually discover during the first 6 weeks and we often already make a point release for that).
Distros are apparently fine with the LTS policy of GCC and clang. What does that look like?
To elaborate for future reference, for LTS-ish proposals like this, it would help everyone reading it if the proposal covers these from the very beginning:
Some concrete points one may wish to cover. This is not exhaustive and is also not intended to be "difficult", just that these are some clarifying questions folks would usually want to ask anyway (some of these were already asked above):
Motivation
"What problems am I having?" -> Maybe it's an XY problem?
Primary painpoints and needs versus papercuts
Priorities and importance for you: what bits are "must have" versus "nice to have"?
It helps a lot to spell out the problems one is facing, without prescribing LTS as the necessary solution.
What does the LTS actually entail?
Scope
Full toolchain incl. devtools like cargo, rust-analyzer, rustfmt, clippy, rustup?
"Core" bootstrapping toolchain {rustc, std}?
Include bootstrap (i.e. ./x.py or ./configure)?
Does it cover ecosystem dependencies used by the toolchain? E.g. rustc also makes sense of selected ecosystem crates. Do the proposed LTS cover those too?
Does it cover the selected codegen backend? (E.g. LLVM at the moment, but one can foresee e.g. cranelift or cg_gcc to give as example)
What does a Rust toolchain LTS mean for say fixes that involve LLVM changes?
What kind of things would you expect to backport?
Security fixes? All security fixes? Critical ones only? What might be the bar? Who/how would (we) determine if the bar is reached?
Soundness fixes? All soundness fixes? Or the most-likely to hit ones?
Important note: some security and soundness fixes rely on significant precusor changes to e.g. rustc/std/LLVM, and it's not a guaranteed that you can backport all such fixes, unless you also bring along all the precursor changes. That can easily tip the risk scale. Just to be clear, it is not trivial, and it becomes more challenging the longer the distance between latest development changes and the LTS target.
Target support? Architecture support? Tier 1/2/3 target? Please note that, sometimes we unfortunately have to straight up delete a target from existence. LTS for a target gone from development will not be fun...
What does the "LT" in LTS stand for? What does "long term" actually mean, here?
Based on the 6-week stable release cycle? I.e. by version numbers?
Based on time?
Intention for funding? Who's supposed to do the extra work for LTS maintenance? If the LTS has bugs?
Essentially: asking only volunteers to do LTS is basically not going to work, both in terms of time and effort, and that it's generally just "work". But there are almost certainly viable ways if such LTS work is pre-arranged and funded.
Do you have any vision for how LTS and LTS-adjacent work might be funded (this includes triaging if e.g. a backport should be applied to LTS branch too!)?
Unrestricted/restricted funding for the Rust Foundation Maintainer's Fund (RFMF) or to the Foundation?
Contracting? Employment?
Specific-purpose funding for e.g. project goals like approaches?
If the LTS has security problems, who's going to triage the report, coordinate the security response, coordinate the fix and responsible disclosure? Who's going to handle the release logistics? How would the LTS be released and distributed?
(NB: this is not intended specifically for this post, just to be clear.)
As a crate author, I wish the Rust Project or the Rust Foundation didn't do this, because 1) I'm worried that designating an "official" LTS would make people feel more entitled than Debian stable currently makes people feel entitled to complain to crate authors who increment MSRV in a crate update and 2), while I don't get to say what folks who work on Rust itself should work on, I'd prefer effort not getting diverted into LTS maintenance.
I think it would be worthwhile to more directly compare what's being proposed here with each of Debian, Ferrocene, and Red Hat Rust Toolset and to state more directly in each case why the proposed difference would be worth the diverted attention both from developers of Rust itself and from developers of crates.
(The OP's mention of Ferrocene is in the context of a "single standard timeline", which to me looks a lot like a way to put more pressure than currently on crate author regarding what MSRV is socially accepted for crates. To be clear: I have a positive view of Ferrocene, and, as a crate author, I have never had anyone complain to me about MSRV due to Ferrocene.)
The OP mentions "Rust’s API evolution policy necessarily allows for some changes that have the possibility to break downstream consumers." From personal anecdata, I think this is being afraid of the wrong thing. A Rust toolchain update causing code that previously compiled not to compile has occurred, but it's 1) rare and 2) very, very obvious that there's a compilation error that points at what to change. What has affected code that I've written more often is that a Rust toolchain update has made something that I've carefully optimized to be fast to become slower. I expect fixes to regressions that make things slower but don't cause incorrect values to be computed wouldn't be backported to LTS. But perhaps expected users of LTS don't care about that aspect that much.
Still, I feel like LTS is catering to perceived concerns of folks who aren't using Rust today, and while I understand the desire to get such folks use Rust, I think it's not good to continuously divert resources to cater to problems that current non-users anticipate but aren't actually a big practical issue when using Rust (even if this sounds like an argument from survivorship bias).