Bastien Roucaries <rouca@debian.org> writes: > Le mercredi 14 janvier 2026, 10:51:31 heure normale d’Europe centrale > Simon Josefsson a écrit : >> Jonas Smedegaard <dr@jones.dk> writes: >> >> > Concerns over NEW queue processing apparently is now the direct cause >> > for lovering severity of some bugs: See bug#1124241 >> >> Another approach is to vendor code, pending uploads. > > And increase the surface attack to the attack of clone ? > > I have an academic paper on debconf2025 about this kind of approach. > > Vendoring is bad. Agreed. Not solving known security vulnerabilities is also bad. Which is worse, if you have to chose? /Simon > rouca >> >> Compare 'opkssh' that had a security vulnerability in testing which was >> fixed in more recent versions, but updating to that version required >> packaging of two new dependencies that depends on each other. The first >> one of those (golang-github-thediveo-success) is in the NEW queue for 3 >> months, and I've been holding off uploading the second dependency >> (golang-github-thediveo-enumflags) until the first one has been accepted >> because the latter one depend on the former. For this situation, I >> think vendoring is acceptable because we are talking about <500 lines of >> code that had simple copyright and license consistent with the original >> package. Of course, debian/copyright and debian/REAME.source needs to >> cover this. >> >> For Go packages, the recursive dependency-on-dependency-on-dependency >> churn is common, as is security problems solved by later upstreams. >> >> I'm seeing this situation for several packages. Getting all the >> recursive dependencies into the archive to allow upgrading Sigstore's >> 'cosign' to the non-vulnerable 3.x series will not be possible before >> forky with the current NEW processing speed. See >> https://bugs.debian.org/1121251 for a dependency tracking chain (which >> is not complete, it just tracks some obvious blockers). For Sigstore, >> vendoring code will lead to lead to a really unmaintainable situation, >> so I avoided it. >> >> Also, what is with NEW uploads that doesn't close any bugs? Couldn't >> they be auto-rejected? It is challenging to review and discuss anything >> when there is no bug report associated with an upload. There are >> several "interesting" packages in the NEW queue that I believe ought to >> have a public fora for discussion, including debian-fastforward (archive >> signing keys for a non-Debian apt sources) and coreutils-from (altering >> fundamental tools). Moving ftp-master discussion with maintainers to >> the bug reports would be a nice transparency improvement IMHO. I never >> understood why the discussion with ftp-masters about package uploads are >> conducted in private, it seems contrary to Debian's social contract to >> not hide things. >> >> /Simon >> >
Attachment:
signature.asc
Description: PGP signature