19:09:12 
 0.1, 
 RCVD_ 
 01, 
 h/aQpLofzmXsbfOKpw@localhost 
 From: bunk@debian.org 
  
 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 
  
  
 [continued in next message] 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2)