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

Groups > linux.debian.security > #5426

Re: Workflow for handling security issues in testing

Cross-posted to 2 groups.

Show all headers | View raw

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

Back to linux.debian.security | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web