Re: Hard Rust requirements from May onward
On Wed, Nov 05, 2025 at 07:15:33AM +0100, Fabian Grünbichler wrote:
> On Tue, Nov 4, 2025, at 7:53 PM, Adrian Bunk wrote:
> > On Tue, Nov 04, 2025 at 06:08:16PM +0100, Fabian Grünbichler wrote:
>...
> > 4. Handling of many binNMUs
> >
> > As part of a DSA for src:rustc in forky we might be talking about
> >> 1k binNMUs per architecture, let's assume 10k binNMUs altogether.
>
> I think that over estimates the number of affected packages.
>
> by my count:
> - S-B-U rustc in unstable would be 169 (binary) packages (which very likely
> undercounts)
> - B-D rustc, cargo, or any of the related debhelper packages in unstable,
> filtering out source packages which only build `librust-.*-dev` packages, I
> end up with 310 source packages (which probably overcounts)
>
> so that gives us a rough number of packages currently possibly missing S-B-U
> (in the wider Rust ecosystem).
Sorry, my fault that I was estimating based on memory instead of double-checking.
Go actually has higher numbers here, with 372 packages having a golang
compiler in Built-Using on amd64/unstable (which gives ~ 2600 binNMUs
over 7 release architectures).
> > In unstable we are already seeing such numbers when a release team
> > member does "Rebuild for outdated Built-Using" (which also covers
> > Go and some other stuff), it takes a day and then it is finished.
>
> like I said - rustc updates every 6 weeks, so yeah, this is roughly everyday
> business for unstable.
>
> and while I do think that preparing for the worst case is a good idea, we
> should also be aware that this is the - hopefully rare to never occuring -
> worst case, the usual cases will be much smaller.
>
> most issues so far - AFAICT - did not affect the codegen part of the toolchain,
> but the toolchain itself (e.g., cargo's interaction with the system), and would
> only warrant a fix of the toolchain, without a rebuild of (parts of) the world.
>
> how would a codegen issue with security implications in GCC be handled? ;)
If affected packages can be narrowed down to a smaller number by
scanning all binary packages in the archive (which is not hard)
it's OK, otherwise it would be a disaster.
But CVEs in glibc are not rare,[1] and when I say src:rustc I am
thinking of libstd-rust-dev.
>...
> > 6. Non-flaky builds
> >
> > When we are talking about 10k binNMUs as part of a DSA, it would be a
> > real pain if only 99% of all builds are successful since that would be
> > 100 build failures the security team would have to handle manually.
>
> and this as part of QA is a good idea anyway, yes! the packages shipping
> binaries built from/with Rust code are already regularly rebuilt during the
> pre-release phase in unstable, either by virtue of natural churn, or by
> scheduled rebuilds because of rustc updates, so the risk here should be smaller
> than with other ecosystems where the last build might have been years ago.
>...
Santiago Vila is doing a really good job at finding those, but we might
need a policy from the release team that packages must build successfully
every single time and that it is an RC bug when the build succeeds only
in 99.9% of all attempts.
In a related note, the "giveback" option for DDs at buildd.d.o should
then perhaps be removed.
cu
Adrian
[1] The C ecosystem also has the problems of missing B-U, and that so far
never all packages have been rebuilt for B-U in point releases.
Reply to: