Re: Workflow for handling security issues in testing
On Sat, Jun 02, 2018 at 11:00:20AM +0200, Philipp Kern wrote: > On 6/1/18 9:17 PM, Adrian Bunk wrote: > > On Thu, May 31, 2018 at 10:36:27PM -0700, Jonathan Nieder wrote: > >> ... > >> I don't think most users of testing realize that > >> they also need to include stable-backports in sources.list to get > >> security fixes. > >> ... > > > > No, this wouldn't get them all security fixes. > > > > It would only make a difference when the package with the security > > fix is backported at all *and* the backport is done before the > > package migrated to testing. > > Which is unfortunately against the rules of backports, as well. Packages > are supposed to enter testing before they are backported. There is an excemption for security fixes, in this case it is actually permitted to upload to backports before testing migration. But note that in the pretty common case that maintainer and backporter are different people the security fix might reach backports much later than testing. > [...] > > testing (and even unstable) often get security fixes after stable, > > and we should be honest about the fact that the security-supported > > part of Debian is a subset of stable[1] without backports. > > I still wonder if there's some way we can make this better for testing > users without resorting to a fatalistic attitude, though. ;-) > > In theory we know which unstable uploads contain security fixes because > the security tracker says so. That'd allow us to flag them and > potentially give them a higher priority to migrate. But it still doesn't > help when manual work is required because they are stuck behind a > transition. Or stuck behind a FTBFS, which is the reason why Chromium in testing is half a year and 100 CVEs behind Chromium in stable-security. "can make this better for testing users" is a dangerous way forward since nothing low-effort would actually provide security support for testing, and this should be clearly communicated. And any "solution" regarding transitions wouldn't solve the problem that there is no security support for unstable. There is nothing that would make security support for testing impossible, but for that there would have to be (again) a separate security team for testing that works on security support every day. > Kind regards > Philipp Kern cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Workflow for handling security issues in testing
On 6/1/18 9:17 PM, Adrian Bunk wrote: > On Thu, May 31, 2018 at 10:36:27PM -0700, Jonathan Nieder wrote: >> ... >> I don't think most users of testing realize that >> they also need to include stable-backports in sources.list to get >> security fixes. >> ... > > No, this wouldn't get them all security fixes. > > It would only make a difference when the package with the security > fix is backported at all *and* the backport is done before the > package migrated to testing. Which is unfortunately against the rules of backports, as well. Packages are supposed to enter testing before they are backported. [...] > testing (and even unstable) often get security fixes after stable, > and we should be honest about the fact that the security-supported > part of Debian is a subset of stable[1] without backports. I still wonder if there's some way we can make this better for testing users without resorting to a fatalistic attitude, though. ;-) In theory we know which unstable uploads contain security fixes because the security tracker says so. That'd allow us to flag them and potentially give them a higher priority to migrate. But it still doesn't help when manual work is required because they are stuck behind a transition. Kind regards Philipp Kern signature.asc Description: OpenPGP digital signature
Re: Workflow for handling security issues in testing
On Thu, May 31, 2018 at 10:36:27PM -0700, Jonathan Nieder wrote: >... > I don't think most users of testing realize that > they also need to include stable-backports in sources.list to get > security fixes. >... No, this wouldn't get them all security fixes. It would only make a difference when the package with the security fix is backported at all *and* the backport is done before the package migrated to testing. This might help in some special cases like your package here, but wouldn't make any difference for packages like chromium or firefox-esr that never get backported and sometimes don't migrate to testing for a long time. As an example, Chromium last migrated to testing in November. Telling users that including stable-backports to sources.list would make their testing system secure would just be hiding the problem that their browser is 3 DSAs and 100 CVEs (sic) behind the version in stable-security. testing (and even unstable) often get security fixes after stable, and we should be honest about the fact that the security-supported part of Debian is a subset of stable[1] without backports. cu Adrian [1] plus (old)oldstable -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Workflow for handling security issues in testing
Hi Niels, Niels Thykier wrote: > Jonathan Nieder: >> With severity=high, a security fix then takes two more days before it >> hits testing. Is there a way to expedite it? My experience with >> https://bugs.debian.org/871823 was "no". [...] > The 2 days are measured from the first time the package has been made > available by dak. And then there are some corner cases in how we handle > "aging" that may slightly complicates how "2 days" are defined here. > > It is *technically possible* to expedite an upload to migrate faster > than "2 days" (including omitting the delay entirely). However, at the > moment a signifiant part of our QA relies on the delay to catch > (obvious) mistakes. As such, we generally reserve such exemptions to > the aging for "very urgent" issues[1]. Thanks. That helps. Git appears to have been blocked today by https://alioth-lists.debian.net/pipermail/piuparts-devel/2018-May/007797.html. Would an "urgent" hint have prevented that? I would like to see the update in unstable to protect users. For example, see [2]. I don't think most users of testing realize that they also need to include stable-backports in sources.list to get security fixes. That said, by the time you read this message it's likely that it will have auto-migrated. :) > I am hoping we will eventually get to a point where the automated QA > tests provided to the testing migration decision can replace the > arbitrary delay we currently use to enable manual testing. Though I > doubt we are ready to do that any time soon. For next time, if I have done sufficient testing (manual piuparts run, having internal users use it in daily life, etc) privately during the embargo period, should I file a bug against the release.debian.org to make an "urgent" hint when the embargo expires? Thanks, Jonathan > [1] Deployed as an "urgent"-hint in britney: > > https://release.debian.org/doc/britney/hints.html#urgent-action-list [2] https://blog.npmjs.org/post/174411769410/how-npm-is-affected-by-the-recently-disclosed-git.
Re: Workflow for handling security issues in testing
Jonathan Nieder: > Hi, > > [...] > Hi Jonathan, Just replying to part of your enquiry > With severity=high, a security fix then takes two more days before it > hits testing. Is there a way to expedite it? My experience with > https://bugs.debian.org/871823 was "no". > > Is my understanding correct? Any other points? > > Thanks, > Jonathan > The 2 days are measured from the first time the package has been made available by dak. And then there are some corner cases in how we handle "aging" that may slightly complicates how "2 days" are defined here. It is *technically possible* to expedite an upload to migrate faster than "2 days" (including omitting the delay entirely). However, at the moment a signifiant part of our QA relies on the delay to catch (obvious) mistakes. As such, we generally reserve such exemptions to the aging for "very urgent" issues[1]. I am hoping we will eventually get to a point where the automated QA tests provided to the testing migration decision can replace the arbitrary delay we currently use to enable manual testing. Though I doubt we are ready to do that any time soon. Thanks, ~Niels [1] Deployed as an "urgent"-hint in britney: https://release.debian.org/doc/britney/hints.html#urgent-action-list
