Source: singularity-container
Severity: serious
-------- Forwarded Message --------
Subject: Re: Should singularity-container make it to next release?
Resent-Date: Wed, 25 Jan 2023 19:25:56 +0000 (UTC)
Resent-From: [email protected]
Date: Wed, 25 Jan 2023 20:14:41 +0100
From: Moritz Muehlenhoff <[email protected]>
To: Andreas Tille <[email protected]>, Nilesh Patra <[email protected]>,
[email protected], [email protected], David
Trudgian <[email protected]>, [email protected],
Debian Security Team <[email protected]>
On Sat, Jan 21, 2023 at 08:34:40PM +0100, Salvatore Bonaccorso wrote:
> So in my understanding of the above the situation around singularity-container,
> which lead for buster to https://bugs.debian.org/917867 and keeping it out of
> the stable release, did not really change in the aspect of beeing able to patch
> vulnerabilities to the stable branch once upstream versions moved on, is this
> correct interpretation? In context from #917867, it was even in stretch at
> first, but needed to be removed after stretch was released in a point release.
>
> If this is correct, then we probably should not include singularity-container
> in bookworm, better than possibly need to remove it after bookworm release in a
> point release.
Agreed.
Cheers,
Moritz
Acknowledgement sent
to Paul Gevers <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian HPC Team <[email protected]>.
(Thu, 26 Jan 2023 09:39:03 GMT) (full text, mbox, link).
[Copy to the bug, I typo-ed the address]
Hi Nilesh,
On 26-01-2023 10:06, Nilesh Patra wrote:
> I guess something that changed since then is that upstream is aware
> about it and can help a bit with backporting. However the onus to
> maintain it in stable is still on the maintainer and security@ (to some
> extent)
> It is bit of a high-effort maintainance (in stable) as far as I can see.
I may (or may not) be misunderstanding you. As a maintainer, it's up to
you to commit to the effort. If you're up to it and judge it's feasible,
I'm not going to block you on that. I understood you raised a concern
about it being feasible, that's why we ended up here. If you commit
(obviously best effort, but we'll expect you to spend time on it) *and*
the security team agrees that with your commitment it's supportable,
I'll remove my concern. Our concern is that we *don't* want new versions
in stable to fix security issues if those new versions are not
bugfix-only releases. We have to accept that for browsers, because
shipping without them seems like a disservice to nearly all of our
users, but still it's something we really don't like.
> fasttrack still has much less visibility / availability than
> an official stable release, or even backports.
Obviously that will only be solved if it's more used (and/or if
eventually it can be moved to the debian.org namespace.) But indeed.
Paul
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.