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. 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.