Groups | Search | Server Info | Login | Register

Groups > linux.debian.devel > #119468

Re: Hard Rust requirements from May onward

Show all headers | View raw

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.

Back to linux.debian.devel | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Hard Rust requirements from May onward Julian Andres Klode <jak@debian.org> - 2025-10-31 21:50 +0100
  Re: Hard Rust requirements from May onward John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> - 2025-10-31 22:40 +0100
    Re: Hard Rust requirements from May onward Simon Richter <sjr@debian.org> - 2025-11-01 04:20 +0100
      Re: Hard Rust requirements from May onward Geert Stappers <stappers@stappers.nl> - 2025-11-01 08:40 +0100
        Re: Hard Rust requirements from May onward Bjørn Mork <bjorn@mork.no> - 2025-11-01 13:40 +0100
          Re: Hard Rust requirements from May onward Simon Josefsson <simon@josefsson.org> - 2025-11-01 14:40 +0100
            Re: Hard Rust requirements from May onward Andrey Rakhmatullin <wrar@debian.org> - 2025-11-01 15:40 +0100
              Re: Hard Rust requirements from May onward Simon Josefsson <simon@josefsson.org> - 2025-11-01 20:40 +0100
                Re: Hard Rust requirements from May onward Philipp Kern <pkern@debian.org> - 2025-11-01 21:10 +0100
                Re: Hard Rust requirements from May onward Holger Levsen <holger@layer-acht.org> - 2025-11-02 00:20 +0100
                Re: Hard Rust requirements from May onward Simon Josefsson <simon@josefsson.org> - 2025-11-02 10:30 +0100
                Re: Hard Rust requirements from May onward Simon Josefsson <simon@josefsson.org> - 2025-11-02 10:40 +0100
                Re: Hard Rust requirements from May onward Philipp Kern <pkern@debian.org> - 2025-11-09 21:40 +0100
                Re: Hard Rust requirements from May onward Simon Josefsson <simon@josefsson.org> - 2025-11-09 23:00 +0100
                Re: Hard Rust requirements from May onward Philipp Kern <phil@philkern.de> - 2025-11-09 23:30 +0100
                Re: Hard Rust requirements from May onward Simon Josefsson <simon@josefsson.org> - 2025-11-10 11:40 +0100
                Re: Hard Rust requirements from May onward Andrey Rakhmatullin <wrar@debian.org> - 2025-11-10 12:20 +0100
                Re: Hard Rust requirements from May onward Holger Levsen <holger@layer-acht.org> - 2025-11-10 13:40 +0100
                Re: Hard Rust requirements from May onward Simon Richter <sjr@debian.org> - 2025-11-10 04:10 +0100
                Re: Hard Rust requirements from May onward Simon Josefsson <simon@josefsson.org> - 2025-11-10 12:00 +0100
                Re: Hard Rust requirements from May onward Simon Richter <sjr@debian.org> - 2025-11-10 15:00 +0100
                Re: Hard Rust requirements from May onward David Kalnischkies <david@kalnischkies.de> - 2025-11-10 17:50 +0100
                Re: Hard Rust requirements from May onward Simon Josefsson <simon@josefsson.org> - 2025-11-10 20:20 +0100
                Re: Hard Rust requirements from May onward Simon Josefsson <simon@josefsson.org> - 2025-11-10 20:30 +0100
                Re: purpose of InRelease in apt [was: non-GPG signatures; was: Rust  requirements] Simon McVittie <smcv@debian.org> - 2025-11-10 17:10 +0100
                Re: purpose of InRelease in apt [was: non-GPG signatures; was: Rust  requirements] Stefano Rivera <stefanor@debian.org> - 2025-11-13 13:20 +0100
                Re: purpose of InRelease in apt [was: non-GPG signatures; was: Rust  requirements] Simon Josefsson <simon@josefsson.org> - 2025-11-13 18:20 +0100
          Re: Hard Rust requirements from May onward Russ Allbery <rra@debian.org> - 2025-11-01 17:50 +0100
          Re: Hard Rust requirements from May onward Christoph Biedl <debian.axhn@manchmal.in-ulm.de> - 2025-11-05 09:10 +0100
        Re: Re: Hard Rust requirements from May onward John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> - 2025-11-02 11:20 +0100
    Re: Hard Rust requirements from May onward Antoni Boucher <bouanto@zoho.com> - 2025-11-01 16:30 +0100
      Re: Hard Rust requirements from May onward John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> - 2025-11-02 11:50 +0100
        Re: Hard Rust requirements from May onward Antoni Boucher <bouanto@zoho.com> - 2025-11-02 16:30 +0100
  Re: Hard Rust requirements from May onward Julian Andres Klode <jak@debian.org> - 2025-10-31 22:50 +0100
  Re: Hard Rust requirements from May onward Paul Tagliamonte <paultag@debian.org> - 2025-11-01 15:20 +0100
    Re: Hard Rust requirements from May onward Paul Tagliamonte <paultag@debian.org> - 2025-11-01 15:20 +0100
    Re: Re: Hard Rust requirements from May onward John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> - 2025-11-02 11:30 +0100
    Re: Hard Rust requirements from May onward Bill Allombert <ballombe@debian.org> - 2025-11-02 15:40 +0100
  Re: Hard Rust requirements from May onward Joerg Jaspert <joerg@debian.org> - 2025-11-02 13:10 +0100
    Re: Hard Rust requirements from May onward Richard Lewis <richard.lewis.debian@googlemail.com> - 2025-11-02 16:20 +0100
      Re: Hard Rust requirements from May onward Adrian Bunk <bunk@debian.org> - 2025-11-02 18:10 +0100
    Re: Hard Rust requirements from May onward Julian Andres Klode <jak@debian.org> - 2025-11-02 17:30 +0100
      Re: Hard Rust requirements from May onward Joerg Jaspert <joerg@debian.org> - 2025-11-02 17:40 +0100
    Re: Hard Rust requirements from May onward Adrian Bunk <bunk@debian.org> - 2025-11-03 23:20 +0100
      Re: Hard Rust requirements from May onward Ansgar 🙀 <ansgar@debian.org> - 2025-11-04 07:30 +0100
        Re: Hard Rust requirements from May onward Mike Hommey <mh@glandium.org> - 2025-11-04 08:10 +0100
        Re: Hard Rust requirements from May onward Adrian Bunk <bunk@debian.org> - 2025-11-04 11:50 +0100
          Re: Hard Rust requirements from May onward Simon Richter <sjr@debian.org> - 2025-11-04 12:10 +0100
            Re: Hard Rust requirements from May onward Adrian Bunk <bunk@debian.org> - 2025-11-04 13:30 +0100
              Vendoring Simon Richter <sjr@debian.org> - 2025-11-04 13:50 +0100
          Re: Hard Rust requirements from May onward Holger Levsen <holger@layer-acht.org> - 2025-11-04 13:20 +0100
            Re: Hard Rust requirements from May onward Simon Richter <sjr@debian.org> - 2025-11-04 13:30 +0100
            Re: Hard Rust requirements from May onward Adrian Bunk <bunk@debian.org> - 2025-11-04 16:00 +0100
              Re: Hard Rust requirements from May onward Holger Levsen <holger@layer-acht.org> - 2025-11-04 16:50 +0100
                Re: Hard Rust requirements from May onward Adrian Bunk <bunk@debian.org> - 2025-11-04 19:40 +0100
        Re: Hard Rust requirements from May onward Stephan Verbücheln <verbuecheln@posteo.de> - 2025-11-04 15:30 +0100
          Re: Hard Rust requirements from May onward Fabian Grünbichler <debian@fabian.gruenbichler.email> - 2025-11-04 18:40 +0100
      Re: Hard Rust requirements from May onward Fabian Grünbichler <debian@fabian.gruenbichler.email> - 2025-11-04 18:30 +0100
        Re: Hard Rust requirements from May onward Sebastian Ramacher <sramacher@debian.org> - 2025-11-04 19:10 +0100
          Re: Hard Rust requirements from May onward Fabian Grünbichler <debian@fabian.gruenbichler.email> - 2025-11-04 19:40 +0100
        Re: Hard Rust requirements from May onward Adrian Bunk <bunk@debian.org> - 2025-11-04 20:10 +0100
          Re: Hard Rust requirements from May onward Adrian Bunk <bunk@debian.org> - 2025-11-04 21:50 +0100
          Re: Hard Rust requirements from May onward Fabian Grünbichler <debian@fabian.gruenbichler.email> - 2025-11-05 07:50 +0100
            Re: Hard Rust requirements from May onward Adrian Bunk <bunk@debian.org> - 2025-11-05 12:10 +0100
        Re: Hard Rust requirements from May onward Adrian Bunk <bunk@debian.org> - 2025-11-05 18:40 +0100
        Re: Hard Rust requirements from May onward Philipp Kern <pkern@debian.org> - 2025-11-06 22:10 +0100
    Re: Hard Rust requirements from May onward Sean Whitton <spwhitton@spwhitton.name> - 2025-11-05 16:00 +0100
  Re: Hard Rust requirements from May onward David Kalnischkies <david@kalnischkies.de> - 2025-11-03 13:40 +0100
    apt-ftparchive alternatives (was: Hard Rust requirements from May  onward) Jeremy Stanley <fungi@yuggoth.org> - 2025-11-03 19:00 +0100
      Re: apt-ftparchive alternatives (was: Hard Rust requirements from  May onward) nick black <dankamongmen@gmail.com> - 2025-11-03 19:50 +0100
        Re: apt-ftparchive alternatives (was: Hard Rust requirements from  May onward) Jeremy Stanley <fungi@yuggoth.org> - 2025-11-03 20:00 +0100
          Re: apt-ftparchive alternatives (was: Hard Rust requirements from  May onward) Peter Pentchev <roam@ringlet.net> - 2025-11-03 21:00 +0100
          Re: apt-ftparchive alternatives Richard Lewis <richard.lewis.debian@googlemail.com> - 2025-11-15 14:00 +0100
      Re: apt-ftparchive alternatives (was: Hard Rust requirements from  May onward) David Kalnischkies <david@kalnischkies.de> - 2025-11-05 16:10 +0100
        Re: apt-ftparchive alternatives Ahmad Khalifa <ahmad@khalifa.ws> - 2025-11-06 22:20 +0100
          Re: apt-ftparchive alternatives David Kalnischkies <david@kalnischkies.de> - 2025-11-09 17:00 +0100
            Re: apt-ftparchive alternatives Ahmad Khalifa <ahmad@khalifa.ws> - 2025-11-09 21:50 +0100
              Re: apt-ftparchive alternatives David Kalnischkies <david@kalnischkies.de> - 2025-11-10 14:00 +0100

csiph-web