Le mercredi 14 janvier 2026, 11:05:39 heure normale d’Europe centrale Simon Josefsson a écrit : > 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? I prefer a well identified problem then a disseminated problem In environmental science it is preferable to have a well identified hot spot of pollution, compared to a disseminated problem like CO2 or eternal pollutant. I think we should take the same approach, rouca > > /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: This is a digitally signed message part.