Re: Hard Rust requirements from May onward
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:
> [..]
>
>> - 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.
sure, it is in the "nice to have" category rather than the "absolute blocker"
one..
>> 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.
ack
> 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.
yes, Sebastinas already replied in the same vain :)
>> 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.
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).
> 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? ;)
> 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.
yes, this needs sorting out - Sebastian's proposal sounds good.
> 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.
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.
please keep in mind that quite a bit of the analysis above only holds if
packages correctly emit Built-Using and Static-Built-Using.
FWIW, my plan is to focus on getting the S-B-U spec finalized and into policy,
and fixing the Rust aspect of its usage across the archive, for now. I am happy
to help with the rest, where possible.
Reply to: