Re: Hard Rust requirements from May onward
On Mon, Nov 3, 2025, at 10:59 PM, Adrian Bunk wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> 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).
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
- 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.
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.
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.
I suspect this would not be too hard to write once S-B-U is finalized and has
more adoption. it would also be nice for unstable binNMUs after non-security
updates, although at least in the Rust part of the archive those happen
regularly anyway, triggered by the toolchain's 6 week release cadence.
did I miss any blockers? please reach out if you have more input or want to
work on improving the situation!
Fabian
0: https://lists.debian.org/debian-rust/2024/11/msg00001.html
1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069256
2: packaged in Debian ;)
Reply to: