email> 
 17:27:11 
 tests= 
 FOURLA= 
 RCVD_ 
 domain: . 
 xWqJV_ 
 fedrtdeggddukeduheekucetufdo 
 rihhlpdfurfetoffkrfgpnffqhge 
 ihqddqteefjeefqddtgeculdehtd 
  
 From: debian@fabian.gruenbichler.email 
  
 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 
  
 [continued in next message] 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2)