Re: Should singularity-container make it to next release?
On 26 January 2023 10:26:05 pm IST, Andreas Tille wrote: >Am Thu, Jan 26, 2023 at 08:22:15AM -0700 schrieb Sam Hartman: >> >> Well, if you and a group of people believe you can maintain it in stable >> given the additional discussions ith upstream, then explicitly say >> you're ready to sign up to maintaining in stable. >> I think that's the kind of sing-up-to-do-the-work that the security and >> release team are waiting for. > >I'd be happy if singularity would be in stable. I'm not sure how far >I can help out since I'm lacking competence in Go but if needed I might >contribute to my limited skills. I'd be happy to have it in stable as well, but by no means am I a professional go programmer, and to be really honest I've fixed CVEs only in one or two instances. Thus, I find it impractical to commit myself (alone) to maintaining it in stable. But if someone is willing to help out on these fronts, I'd be glad to know. -- Best, Nilesh
Re: Should singularity-container make it to next release?
Am Thu, Jan 26, 2023 at 08:22:15AM -0700 schrieb Sam Hartman: > > Well, if you and a group of people believe you can maintain it in stable > given the additional discussions ith upstream, then explicitly say > you're ready to sign up to maintaining in stable. > I think that's the kind of sing-up-to-do-the-work that the security and > release team are waiting for. I'd be happy if singularity would be in stable. I'm not sure how far I can help out since I'm lacking competence in Go but if needed I might contribute to my limited skills. Kind regards Andreas. -- http://fam-tille.de
Re: Should singularity-container make it to next release?
> "Nilesh" == Nilesh Patra writes: Nilesh> Since I had done quite a bit of work on this, I'm a sad to Nilesh> see this happen, as fasttrack still has much less visibility Nilesh> / availability than an official stable release, or even Nilesh> backports. Well, if you and a group of people believe you can maintain it in stable given the additional discussions ith upstream, then explicitly say you're ready to sign up to maintaining in stable. I think that's the kind of sing-up-to-do-the-work that the security and release team are waiting for. signature.asc Description: PGP signature
Re: Should singularity-container make it to next release?
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 OpenPGP_signature Description: OpenPGP digital signature
Re: Should singularity-container make it to next release?
On Thu, Jan 26, 2023 at 09:51:21AM +0100, Paul Gevers wrote: > On 25-01-2023 20:14, Moritz Muehlenhoff wrote: > > 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. 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 have forwarded this message as bug #1029669. Unless we get more confidence > that it's supportable, let's keep it out of stable. I guess fasttrack [1] is > currently the best forum to supply singularity-container to our users. Since I had done quite a bit of work on this, I'm a sad to see this happen, as fasttrack still has much less visibility / availability than an official stable release, or even backports. > [1] https://fasttrack.debian.net/ -- Best, Nilesh signature.asc Description: PGP signature
Re: Should singularity-container make it to next release?
Hi, On 25-01-2023 20:14, Moritz Muehlenhoff wrote: 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 I have forwarded this message as bug #1029669. Unless we get more confidence that it's supportable, let's keep it out of stable. I guess fasttrack [1] is currently the best forum to supply singularity-container to our users. Paul [1] https://fasttrack.debian.net/ OpenPGP_signature Description: OpenPGP digital signature
Re: Should singularity-container make it to next release?
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
Re: Should singularity-container make it to next release?
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_medium=web2x=3 > > > [5]: > > > https://support.sylabs.io/support/solutions/articles/4287130-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,
Re: Should singularity-container make it to next release?
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_medium=web2x=3 > > [5]: > > https://support.sylabs.io/support/solutions/articles/4287130-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 > > -- > Best, > Nilesh -- http://fam-tille.de
