[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: NEW queue processing causes relaxed treatment of security issues



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.

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


Reply to: