Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.security > #5422 > unrolled thread

Workflow for handling security issues in testing

Back to article view | Back to linux.debian.security

Contents

  Workflow for handling security issues in testing Jonathan Nieder <jrnieder@gmail.com> - 2018-05-30 18:10 +0200
    Re: Workflow for handling security issues in testing Niels Thykier <niels@thykier.net> - 2018-05-30 21:00 +0200
      Re: Workflow for handling security issues in testing Jonathan Nieder <jrnieder@gmail.com> - 2018-06-01 07:40 +0200
        Re: Workflow for handling security issues in testing Adrian Bunk <bunk@debian.org> - 2018-06-01 21:20 +0200
          Re: Workflow for handling security issues in testing Adrian Bunk <bunk@debian.org> - 2018-06-02 12:10 +0200
        Re: Workflow for handling security issues in testing Niels Thykier <niels@thykier.net> - 2018-06-04 08:00 +0200

#5422 — Workflow for handling security issues in testing

Hi,

https://security-tracker.debian.org/tracker/CVE-2018-11235
(https://public-inbox.org/git/xmqqy3g2flb6.fsf@gitster-ct.c.googlers.com/)
reminded me that I don't fully understand the process for handling
embargoed security issues in sid and testing.

When preparing updates for an embargoed issue in stable
(https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#bug-security),
the packager uploads to security-master and auto-builders are able to
build for supported platforms before the embargo expires.  Once the
embargo expires, the package is released and available quickly for
users to upgrade.

After preparing updates for an embargoed issue in sid, the packager
uploads to ftp-master once the embargo expires.  There is an additional
delay for auto-builders to build the package before the binary package
is available, unless the packager prepares binary packages locally in
advance and uploads them as well.  Is that the recommended practice?

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

[toc] | [next] | [standalone]

#5423

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

[toc] | [prev] | [next] | [standalone]

#5424

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.

[toc] | [prev] | [next] | [standalone]

#5425

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

[toc] | [prev] | [next] | [standalone]

#5426

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

[toc] | [prev] | [next] | [standalone]

#5427

Jonathan Nieder:
> 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?
> 

No.  A "ignore-piuparts" hint could have done it (but we would probably
have preferred waiting for the retest, which you requested).

> [...]>>   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
> 
> [...]
Historically, we tend to prefer "age-days 2" over "urgent" to ensure
some basic level of testing; I suspect that is what you would end up
getting in the general case if you requested an "urgent"-hint.
  Changing this will require a lot more maturity in our autopkgtests
infrastructure: primarily a majority of all packages having useful
autopkgtests and autopkgtests regressions being a testing blocker.  At
that point we will probably start to become more likely to waive the
aging requirement for packages with fixes for security issues.  But even
then that does not imply that there will be a general carte blanch
exemption on the QA tests for these packages (i.e. I expect that
autopkgtests, piuparts, etc. should still pass).

But on a related note: I have considered Philipp's idea of importing
data from the security-tracker and I think that is a good idea.  For
now, we could use it to automatically bump the urgency and as the QA
matures, we could eventually use it to waive the age requirement
entirely for packages with sufficient levels of automated QA (that passes).

Thanks,
~Niels

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.security

csiph-web