Re: rails update
Hi Sylvain, On Wed, Jun 17, 2020 at 11:09:41PM +0200, Sylvain Beucler wrote: > Hi Security Team, > > I see that 'rails' is present in dsa-needed.txt. Right, current open rails issues would warrant a DSA. > I'm currently testing an update for jessie and I can prepare an update > for stretch (which appears to be similar). > (not sure what's the plan for buster) > Would you be interested? Yes if you are interested in contributing the updates, help is welcome. Apart the proposed debdiffs, would be ideal to hear what you were able to test/check. So assuming you are intersted in preparing the stretch-security one, would you as well work on the buster-security one? (it has different set of open CVEs to be addressed). > Note: since there's 2:4.2.7.1-1+deb9u2 in stretch-proposed-updates, > would it be OK to prepare a deb9u3 straight for stretch-security? Right, given 2:4.2.7.1-1+deb9u2 was uploaded to stretch-proposed-updates and as well already acked by SRM please just build on top of it as 2:4.2.7.1-1+deb9u3 for stretch-security. Regards, Salvatore
Re: rails update
Hi all, On Fri, Jun 19, 2020 at 3:10 PM Salvatore Bonaccorso wrote: > > I'm currently testing an update for jessie and I can prepare an update > > for stretch (which appears to be similar). > > (not sure what's the plan for buster) > > Would you be interested? > > Yes if you are interested in contributing the updates, help is > welcome. Apart the proposed debdiffs, would be ideal to hear what you > were able to test/check. Just letting you know with my rails' maintainer hat on.. I faced a regression where I think, activestorage (one of rails' binary), broke and in turn, it broke a bunch of other gems as well. Please ensure that the fix of these CVE(s) won't break other libraries because otherwise, it would mess up an instance. Of course, the tests would pass, but if you can check and ensure that it's not breaking other stuff, you're good to go! :) Best, Utkarsh
Re: rails update
On Fri, Jun 19, 2020 at 10:46 PM Utkarsh Gupta wrote: > Just letting you know with my rails' maintainer hat on.. > I faced a regression where I think, activestorage (one of rails' binary), > broke and in turn, it broke a bunch of other gems as well. > > Please ensure that the fix of these CVE(s) won't break other libraries > because otherwise, it would mess up an instance. > Of course, the tests would pass, but if you can check and ensure that > it's not breaking other stuff, you're good to go! :) Also, I think it originated due to babel (I am not sure though!), but that was the closest I got to when debugging. If so, then I don't think anything would break. Anyway, this was the patch that fixed the regression: https://salsa.debian.org/ruby-team/rails/-/commit/fe3206768ed30b8eb6a83e74fc813e616d7d0db3 Best, Utkarsh
Re: rails update
Hi Security Team, Utkarsh, On 19/06/2020 11:40, Salvatore Bonaccorso wrote: > On Wed, Jun 17, 2020 at 11:09:41PM +0200, Sylvain Beucler wrote: >> I'm currently testing an update for jessie and I can prepare an update >> for stretch (which appears to be similar). >> (not sure what's the plan for buster) >> Would you be interested? > > Yes if you are interested in contributing the updates, help is > welcome. Apart the proposed debdiffs, would be ideal to hear what you > were able to test/check. Here's the prepared stretch update: https://www.beuc.net/tmp/debian-lts/rails/ https://www.beuc.net/tmp/debian-lts/rails/debdiff.txt Testing was documented at: https://wiki.debian.org/LTS/TestSuites/rails It includes running the DEP-8 tests (which deploys a full app) and running the full upstream testsuite. Test cases for the 2 CVEs were backported. > So assuming you are intersted in preparing the stretch-security one, > would you as well work on the buster-security one? (it has different > set of open CVEs to be addressed). The buster version is different and introduces 3 new vulnerabilities, which strays a bit too far off my current work on rails. I believe the package maintainers (possibly Utkarsh) would be in better position to prepare the buster update. If the rails maintainers are not available though I can step in. On 19/06/2020 19:20, Utkarsh Gupta wrote: > On Fri, Jun 19, 2020 at 10:46 PM Utkarsh Gupta wrote: >> Just letting you know with my rails' maintainer hat on.. >> I faced a regression where I think, activestorage (one of rails' binary), >> broke and in turn, it broke a bunch of other gems as well. >> >> Please ensure that the fix of these CVE(s) won't break other libraries >> because otherwise, it would mess up an instance. >> Of course, the tests would pass, but if you can check and ensure that >> it's not breaking other stuff, you're good to go! :) > > Also, I think it originated due to babel (I am not sure though!), but that > was > the closest I got to when debugging. > If so, then I don't think anything would break. > > Anyway, this was the patch that fixed the regression: > https://salsa.debian.org/ruby-team/rails/-/commit/fe3206768ed30b8eb6a83e74fc813e616d7d0db3 As far as I understand, you experienced a regression but it isn't related to the current CVEs, is it? Is there a depending library/app that you would recommend testing with? Cheers! Sylvain
Re: libdatetime-timezone-perl
Hi I have added a note about this now. I have another question about this package, but I'll start a new thread about that. // Ola On Thu, 8 Nov 2018 at 10:08, Raphael Hertzog wrote: > > Hi, > > On Wed, 07 Nov 2018, Santiago Ruano Rincón wrote: > > I included it to dla-needed. It doesn't have any known security > > vulnerability, but its database is now out-of-date. I should be updated > > to 2018g, as it was done for stretch: > > https://tracker.debian.org/news/998425/accepted-libdatetime-timezone-perl-1209-12018g-source-into-proposed-updates-stable-new-proposed-updates/ > > > > Since there isn't point releases for LTS (we cannot propose updates for > > jessie), we have to update to jessie-security. > > It might be good to add a comment explaining what's to be done in such > cases. > > Cheers, > -- > Raphaël Hertzog ◈ Debian Developer > > Support Debian LTS: https://www.freexian.com/services/debian-lts.html > Learn to master Debian: https://debian-handbook.info/get/ -- --- Inguza Technology AB --- MSc in Information Technology | o...@inguza.como...@debian.org| | http://inguza.com/Mobile: +46 (0)70-332 1551 | ---
libdatetime-timezone-perl need to wait?
Hi Roberto In the DLA needed entry for libdatetime-timezone-perl you have mentioned that we need to wait for oldstable update via point release before the LTS update is made. When looking at the version numbers for the different releases I fail to see the necessity of that. Have I missed something? Or is this note false? Thanks in advance // Ola -- --- Inguza Technology AB --- MSc in Information Technology | o...@inguza.como...@debian.org| | http://inguza.com/Mobile: +46 (0)70-332 1551 | ---
Re: libdatetime-timezone-perl need to wait?
Hi, On 19/06/2020 23:29, Ola Lundqvist wrote: > In the DLA needed entry for libdatetime-timezone-perl you have > mentioned that we need to wait for oldstable update via point release > before the LTS update is made. When looking at the version numbers for > the different releases I fail to see the necessity of that. > > Have I missed something? Or is this note false? >From what I understand, we want to provide 2020a-0+deb8u1 but if we do before 2019c-0+deb9u1 -> 2020a-0+deb9u1 is done on stretch, people who upgrade jessie -> stretch will retain the jessie package (while they should use the stretch package). See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958995 Cheers! Sylvain
