Re: Should singularity-container make it to next release?

[Salvatore Bonaccorso <carnil@debian.org>]

Hi Andreas,

[Note if you want direct input from the Debian security team it's
usually better to loop in the team email address directly rather the
general discussion list debian-security, adding team@s.d.o to
recipients]

On Mon, Jan 09, 2023 at 02:28:22PM +0100, Andreas Tille wrote:
> Hi,
> 
> it would be great if someone from Security Team might raise some
> opinion to this question.
> 
> Kind regards
>     Andreas.
> 
> Am Mon, Jan 09, 2023 at 03:51:10PM +0530 schrieb Nilesh Patra:
> > Hi,
> > 
> > On Wed, Oct 12, 2022 at 09:38:27PM +0530, Nilesh Patra wrote:
> > > src:singularity-container was lying around in a bad shape for several years
> > > and had missed 2 debian releases until me and Andreas picked it up again.
> > > It is currently in a reasonably good condition. I was excited to have it in
> > > stable release again, but I have a couple of doubts over it.
> > > 
> > > 1. A little background:
> > > singularity-container sync the code from the upstream codebase for sylabs[1]
> > > and there also exists a community-maintained fork called apptainer.
> > > Sylabs singularity CE seems to sync up a lot of code with apptainer in
> > > many releases. The apptainer community announcement page about the split also
> > > hints towards saying similar stuff, but this is all the more confusing as it is
> > > hard to draw a line b/w them.
> > > A while back, I found a reddit comment[4] from the current maintainer of sylabs
> > > singularity which has a statement:
> > > 
> > > | At this point there it appears that Apptainer 1.0 will be very close
> > > | to SingularityCE 3.9 which we released recently, given
> > > | the picks from SingularityCE into the code base.
> > > 
> > > So I am absolutely confused if it makes sense to package apptainer at all or
> > > should I just let it be?
> > > 
> > > 2. The _more_ important question:
> > > There are CVEs being discovered in singularity-container -- no biggie. However, some
> > > of the CVE fixes are simply _hidden_ from the user view.
> > > As a concrete example, there was
> > > a "CVE-2021-33622" opened[5] against singularity-CE, and the only information
> > > upstream provides is that it has been fixed in the 3.7.x of the community edition
> > > but there is no information about _what_ the fix was.
> > > I tried asking upstream about this but did not get a pin-pointed reply[6] and it
> > > appears that upstream is somewhat discrete about these.
> > > 
> > > A similar bug has been fixed in the latest release, CVE-2022-39237 here[7] but it
> > > does not say _what_ patch fixes it exactly.
> > > And the problem is that apptainer has addressed the exact same bug in
> > > its latest release and they too are un-clear about it[8].
> > > 
> > > So my fear is that: Once singularity-container hits stable release, and there is
> > > a CVE being found. It'd be a hellhole for me/others to find what exactly
> > > fixed the CVE (unless it is being clearly stated), and apply that. The only
> > > option left would be to upgrade the package to fix the CVE and I don't know if
> > > release team would allow that.
> > > 
> > > And I don't see this problem getting fixed with apptainer as well, since there
> > > are bugs that both the codebases would keep on inheriting from one another.
> > > And thus I am not sure if this situation is OK for stable release or not.
> > > 
> > > OTOH, singularity is an important package and many users would be happy to have
> > > it in stable -- I have even got a couple of bug reports/texts saying
> > > people are happy to see a new update of singularity.
> > 
> > I started this thread a while back, and decided to simply ask upstream about what their
> > opinion is[9]
> > It looks like the situation still not fully certain on whether to let singularity make it to stable
> > or not.
> > 
> > I'd appreciate if someone on the list could chime in and give an opinion on if they
> > consider it do-able or not for upcoming bookworm release.
> > 
> > I've kept upstream in CC to avoid ping-pong, and thanks David for a nice elaborate reply.
> > 
> > > [1]: https://github.com/sylabs/singularity
> > > [2]: https://github.com/apptainer/apptainer
> > > [3]: https://apptainer.org/news/community-announcement-20211130/
> > > [4]: https://www.reddit.com/r/HPC/comments/r61bto/comment/hmspn72/?utm_source=share&utm_medium=web2x&context=3
> > > [5]: https://support.sylabs.io/support/solutions/articles/42000087130-3-5-8-security-release-cve-2021-33622-
> > > [6]: https://github.com/sylabs/singularity/issues/586
> > > [7]: https://github.com/sylabs/sif/security/advisories/GHSA-m5m3-46gj-wch8
> > > [8]: https://github.com/apptainer/apptainer/releases/tag/v1.1.2
> > [9]: https://github.com/sylabs/singularity/issues/1235#issuecomment-1375334909

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.

Regards,
Salvatore