Re: Hard Rust requirements from May onward
On Tue, Nov 04, 2025 at 06:08:16PM +0100, Fabian Grünbichler wrote:
> On Mon, Nov 3, 2025, at 10:59 PM, Adrian Bunk wrote:
> > On Sun, Nov 02, 2025 at 01:08:06PM +0100, Joerg Jaspert wrote:
> >>...
> >> I think that shouldn't be on one maintainers decision alone.
> >>...
> >
> > In addition to that, discussion of relevant topics that would be part of
> > any normal decision process is also missing.
> >
> > Like people tend to forget about [1].
> > Has the Security team committed to change that in forky?
> > Has the Archive Operations Team committed to fixing their part of that?
> > Is all tooling automatic enough that handling 1k binNMUs per
> > architecture as part of a DSA or point release wouldn't cause problems?
> > Is anyone working on different binNMU version numbering in stable releases?
> >
> > Status quo is that sing Rust would reduce security support for apt.
> >
> > sqv (used by apt in trixie) is already affected by this.
> >
> > It has been known and discussed for a decade that we are not setup for
> > security support of static-only ecosystems, and I do not have the
> > impression that the proponents of more Rust in Debian care about
> > security.
>
> I am not sure if I would describe myself as a "proponent of more Rust in
> Debian", but as the maintainer of the Rust toolchain and related packaging
> helpers, I'd definitely like to get this fixed for Forky (I've actually already
> wanted to get the ball rolling again during the Trixie cycle, but failed[0]).
>
> AFAIU, there's a few mostly independent blockers for this:
>
> 1) lack of stabilization and adoption of Static-Built-Using
>
> while there has been some progress, S-B-U is still not finalized spec-wise[0],
> and (maybe partly as a consequence), many packages that should emit it don't.
>
> for most packages, this is actually not a huge blocker in practice, because
> until it is sorted out any tooling that wants to find out what needs to be
> rebuilt for a particular fix/update to become effective can also
> over-approximate using buildinfo files (what wasn't around at build time can't
> have been statically linked either), unless we are talking about multiple
> levels of static linking (e.g. C being updated, C being statically linked into
> B, and B being linked statically into A).
Multiple levels of static linking are used in the Haskell and OCaml
ecosystems, but all transition levels between C and A are already
covered through automatically emitted package dependencies there.
> a lintian tag for ecosystems where a B-D on the toolchain heavily implies
> S-B-U should be contained in the resulting binary package(s) was suggested, and
> would maybe help driving up adoption if combined with a MBF.
>
> 2) security infrastructure issues
>
> AFAIU, but my understanding here is very limited as I am neither part of DSA
> nor the security team:
> - the security archive/builders/dak instance are running inside VMs with not
> enough space for a full archive, which means no binNMU support
Even regular uploads do not work without manual work by the archive team
when the sources for Built-Using are missing.
The positive side is that this should not be very hard to solve.
> - there is no support for building sets of interdependent uploads without
> releasing them (which would be required for embargoed issues to first upload
> a fixed crate package, then rebuild everything linking it, then release all
> the packages together)
>
> this part is probably only solvable by or with involvement of the security team
> and DSA, for obvious reasons.
I would treat this as a bonus feature, not a mandatory one,
since it is not strictly necessary and not easy to implement.
> 3) lack of source NMUs
>
> there are no source NMUs, so any affected source package that builds an
> arch:all package and also happens to link the problematic source statically
> needs a real, sourceful upload, which scales a lot worse if the number of such
> packages is higher than a handful.
This is not true, that problem only exists when the arch:all package
itself contains a statically linked binary.
There are cases where this applies (e.g. open source firmware for a
microcontroller in an arch:all package), but these are rare.
> IIRC there are some plans for tackling this, not related to the issue we are
> discussing at the moment, because source NMUs would be awesome in general ;)
>
> 4) lack of tooling to analyze which packages need to be rebuilt
>
> for binNMUs in unstable, there is drt-tools[2] (which allows scheduling
> transition or ExtraSourceOnly related binNMUs, as well as built-by-maintainer
> ones via excuses). other similar workflows also have tools to assist with
> (re)building. TTBOMK, there is no such tooling for finding out which packages
> (potentially) need a rebuild because of an updated, statically linked package.
>...
drt-tools already supports checking X-Cargo-Built-Using and Static-Built-Using.
> did I miss any blockers? please reach out if you have more input or want to
> work on improving the situation!
>From my list above:
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.
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.
Are all steps automated enough that getting 10k uploads through
security-new -> security -> stable-new -> stable-pu -> stable
is feasible?
Especially for stable-pu -> stable on release day it also matters that
this is reasonably fast.
5. binNMU version numbering in stable releases
Currently stable releases (and testing) use the same binNMU versions as
unstable. The result of re-using a version like 1.0-1+b1 in stable when
the same version already is or was is either a reject of the upload by
dak, or two packages with the same version and different contents (#1072205).
The proper solution would be using something like 1.0-1+b0.13.1 in trixie.
Even that would not be sufficient for preventing stable-pu and security
to binNMU different packages with the same version for different reasons.
And a bonus item:
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.
> Fabian
>...
cu
Adrian
Reply to: