Bug#929011: unblock: singularity-container/3.1.1+ds-1
On June 28, 2019 5:00:00 AM EDT, Ivo De Decker wrote: >Hi, > >On Thu, Jun 27, 2019 at 09:30:09AM -0400, Afif Elghraoui wrote: >> On June 27, 2019 9:06:41 AM EDT, Afif Elghraoui >wrote: >> > >> > >> >On June 27, 2019 5:47:28 AM EDT, Ivo De Decker >> >wrote: >> >>Hi, >> >>> >> >>> So I think the two options we have is (in order of preference): >1. >> >>> unblock singularity-container and let the 3.1 based version in to >> >>> buster, or 2. remove singularity-container from buster. >> >> >> >>It's really too late for option 1. Sorry. >> >> >> >>I added a removal hint. >> >> >> > >> >This request was not just filed recently. I don't understand why I'm >> >being penalized for this being late--the version requested for >> >unblocking as been in unstable for 43 days with no new bugs. And >it's >> >also a leaf package. >> > >> >Please reconsider. >> > >> >> I at least want to know what I could have done because, from my >perspective, >> I did everything in my power to do this as quickly as possible. At >the time >> I made the request, the buster release date had not yet even been >set. > >Please look at the freeze policy: > >https://release.debian.org/buster/freeze_policy.html I have seen it. I hoped we would be trying to make the best possible release rather than just following the freeze policy for its own sake. My understanding of its strictness is to keep packages with reverse-dependencies from breaking them with large changes. This was a very low/no-risk request because it is a leaf package. firefox-esr updates to new versions all the time for security support and actually does break reverse-dependency packages in Stable much of the time as a result. > >The upload of 3.1.1+ds-1 was done on 2019-05-15, the full freeze >started on >2019-03-12. > >During the full freeze, we only accept targeted fixes. Your upload >didn't come >close to that, as you admitted yourself in your original mail to the >unblock >request. The chances of such a request being granted were extremely >small, >even at the point the request was made. > >The unblock won't be granted. Sorry. > Removal of the existing version in buster, on the other hand, I thought was too extreme. I would have tried to support 3.0.3 in buster if any CVEs in it came up and, if that proved too difficult, asked for the exemption to bump to this 3.1 lts version again at that point. regards Afif
Bug#929011: unblock: singularity-container/3.1.1+ds-1
Control: reopen -1 On June 27, 2019 9:06:41 AM EDT, Afif Elghraoui wrote: > > >On June 27, 2019 5:47:28 AM EDT, Ivo De Decker >wrote: >>Hi, >>> >>> So I think the two options we have is (in order of preference): 1. >>> unblock singularity-container and let the 3.1 based version in to >>> buster, or 2. remove singularity-container from buster. >> >>It's really too late for option 1. Sorry. >> >>I added a removal hint. >> > >This request was not just filed recently. I don't understand why I'm >being penalized for this being late--the version requested for >unblocking as been in unstable for 43 days with no new bugs. And it's >also a leaf package. > >Please reconsider. > I at least want to know what I could have done because, from my perspective, I did everything in my power to do this as quickly as possible. At the time I made the request, the buster release date had not yet even been set. I followed up on the docker bugs and offered to help and was told by the maintainer it was under control. The singularity community was really looking forward to having the package in Debian Stable this time around. regards Afif
Bug#929011: unblock: singularity-container/3.1.1+ds-1
Control: tag -1 - moreinfo On June 25, 2019 4:16:17 PM EDT, Salvatore Bonaccorso wrote: >Hi Paul, hi Afif, > [...] >> >> Your proposed changes very much do not align with the freeze policy, >so >> you're asking for an exception for a new upstream release. This >package >> is currently listed to be auto-removed due to docker.io, so I am not >> going to review it now. docker.io is a major concern for the >> security-team so that needs to be resolved first. If that gets >resolved >> in a timely manner, i.e. before it is auto-removed, please ping this >bug >> (e.g. by removing the moreinfo bug). > >I do agree that the changes are not really reviewable given the size >of the diff. But with Afifs argument and now the package not beeing >marked as autoremoved: if we want to support singularity-container >security wise in buster we would need to bite into the apple and >accept this late new version bump for buster as the 3.1 version. > >So I think the two options we have is (in order of preference): 1. >unblock singularity-container and let the 3.1 based version in to >buster, or 2. remove singularity-container from buster. > >Cc'in team@s.d.o for further comments. > Thanks, Salvatore. I'm removing the moreinfo tag as Paul said to do since the autoremoval warning has been lifted. regards Afif
Bug#929011: unblock: singularity-container/3.1.1+ds-1
Hi Paul, hi Afif, On Sat, Jun 08, 2019 at 09:26:06PM +0200, Paul Gevers wrote: > Control: tags -1 moreinfo > > Hi Afif, > > On Wed, 15 May 2019 03:47:28 -0400 Afif Elghraoui wrote: > > Please unblock package singularity-container/3.1.1+ds-1 > > > > This package is prone to security vulnerabilities. Upstream provides > > long-term support for selected versions to their paid users, but also > > releases all code changes (including backported security patches) to the > > community. > > > > Both 3.0.x and 3.1.x were released earlier this year and it was not > > known at the time which of these would be the LTS version. 3.0.3 is what > > I bet on and what is in Testing now, but it now turns out that I was > > wrong and it's actually 3.1. Using it would greatly facilitate our > > ability to provide support over the lifetime of Buster. > > > > The benefits of doing this have also just been clearly demonstrated: > > Upstream just released 3.2.0, adding new features as well as fixing > > security issues affecting versions 3.1.0 and up, but because 3.1 is > > under LTS support for their paid users, they also provided the security > > patches backported to 3.1 (see the 3.2.0 release notes - > > https://github.com/sylabs/singularity/releases/tag/v3.2.0 ). > > > > So I apologize for the large diff, but I think we'd be in much better > > shape having this upstream version in Buster. Especially because of the > > large diff, backporting patches to 3.0 without the help from upstream > > that we'd get by using 3.1 would be unnecessarily more burdensome. > > > > many thanks for your time and consideration > > Your proposed changes very much do not align with the freeze policy, so > you're asking for an exception for a new upstream release. This package > is currently listed to be auto-removed due to docker.io, so I am not > going to review it now. docker.io is a major concern for the > security-team so that needs to be resolved first. If that gets resolved > in a timely manner, i.e. before it is auto-removed, please ping this bug > (e.g. by removing the moreinfo bug). I do agree that the changes are not really reviewable given the size of the diff. But with Afifs argument and now the package not beeing marked as autoremoved: if we want to support singularity-container security wise in buster we would need to bite into the apple and accept this late new version bump for buster as the 3.1 version. So I think the two options we have is (in order of preference): 1. unblock singularity-container and let the 3.1 based version in to buster, or 2. remove singularity-container from buster. Cc'in team@s.d.o for further comments. Regards, Salvatore
Bug#929011: unblock: singularity-container/3.1.1+ds-1
Control: tag -1 - moreinfo Paul Gevers writes: > On Wed, 15 May 2019 03:47:28 -0400 Afif Elghraoui wrote: >> Please unblock package singularity-container/3.1.1+ds-1 >> >> This package is prone to security vulnerabilities. Upstream provides >> long-term support for selected versions to their paid users, but also >> releases all code changes (including backported security patches) to the >> community. >> >> Both 3.0.x and 3.1.x were released earlier this year and it was not >> known at the time which of these would be the LTS version. 3.0.3 is what >> I bet on and what is in Testing now, but it now turns out that I was >> wrong and it's actually 3.1. Using it would greatly facilitate our >> ability to provide support over the lifetime of Buster. >> >> The benefits of doing this have also just been clearly demonstrated: >> Upstream just released 3.2.0, adding new features as well as fixing >> security issues affecting versions 3.1.0 and up, but because 3.1 is >> under LTS support for their paid users, they also provided the security >> patches backported to 3.1 (see the 3.2.0 release notes - >> https://github.com/sylabs/singularity/releases/tag/v3.2.0 ). >> >> So I apologize for the large diff, but I think we'd be in much better >> shape having this upstream version in Buster. Especially because of the >> large diff, backporting patches to 3.0 without the help from upstream >> that we'd get by using 3.1 would be unnecessarily more burdensome. >> >> many thanks for your time and consideration > > Your proposed changes very much do not align with the freeze policy, so > you're asking for an exception for a new upstream release. This package > is currently listed to be auto-removed due to docker.io, so I am not > going to review it now. docker.io is a major concern for the > security-team so that needs to be resolved first. If that gets resolved > in a timely manner, i.e. before it is auto-removed, please ping this bug > (e.g. by removing the moreinfo bug). I've removed the moreinfo tag as docker.io was unblocked. Ansgar
Bug#929011: unblock: singularity-container/3.1.1+ds-1
Control: tags -1 moreinfo Hi Afif, On Wed, 15 May 2019 03:47:28 -0400 Afif Elghraoui wrote: > Please unblock package singularity-container/3.1.1+ds-1 > > This package is prone to security vulnerabilities. Upstream provides > long-term support for selected versions to their paid users, but also > releases all code changes (including backported security patches) to the > community. > > Both 3.0.x and 3.1.x were released earlier this year and it was not > known at the time which of these would be the LTS version. 3.0.3 is what > I bet on and what is in Testing now, but it now turns out that I was > wrong and it's actually 3.1. Using it would greatly facilitate our > ability to provide support over the lifetime of Buster. > > The benefits of doing this have also just been clearly demonstrated: > Upstream just released 3.2.0, adding new features as well as fixing > security issues affecting versions 3.1.0 and up, but because 3.1 is > under LTS support for their paid users, they also provided the security > patches backported to 3.1 (see the 3.2.0 release notes - > https://github.com/sylabs/singularity/releases/tag/v3.2.0 ). > > So I apologize for the large diff, but I think we'd be in much better > shape having this upstream version in Buster. Especially because of the > large diff, backporting patches to 3.0 without the help from upstream > that we'd get by using 3.1 would be unnecessarily more burdensome. > > many thanks for your time and consideration Your proposed changes very much do not align with the freeze policy, so you're asking for an exception for a new upstream release. This package is currently listed to be auto-removed due to docker.io, so I am not going to review it now. docker.io is a major concern for the security-team so that needs to be resolved first. If that gets resolved in a timely manner, i.e. before it is auto-removed, please ping this bug (e.g. by removing the moreinfo bug). Paul signature.asc Description: OpenPGP digital signature
