Re: Long term improvement to Debian's security and LTS
On Fri, 30 Oct 2015, Moritz Muehlenhoff wrote:
> > > - improving the security infrastructure
>
> That has certainly the best net positive from my point of view.
>From my point of view too. But I'm not sure I would put the same
emphasis as you on dak related work.
I would possibly suggest to work on the security tracker:
- have stats about security updates on all packages so that we can
easily identify which packages should be targetted in any pro-active
security work
- have stats on the delay between issues appearing in our radar and having
the issue fixed
- have stats on the number of open issues in each Debian release
- https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=security-tracker;dist=unstable
The general workflow of the security teams can possibly be improved with
better tools.
Also when Holger worked on the security tracker, he mentionned more than once
that it would possibly benefit from a clean rewrite.
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796095 and
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796784 are bugs
> which would make our lives easier.
>
> Also the orig tarball handling is quite an nuisance (no bug for
> that, but outlined here:
> https://wiki.debian.org/DebianSecurity/AdvisoryCreation/dak-bugs
>
> I'm not sure whether that can be speeded up by submitting patches
> from the LTS team or rather be reaching out whether FTP masters
> can work on that on a paid basis.
I don't know. I just fear that this could cause issues within the
ftpmasters team if someone of the team gets paid to work on dak.
On the other hand, Thorsten Alteholz is ftp assistant and is a member of
the paid LTS contributors.
> > > - adding DEP-8 tests to packages with regular security updates
>
> Or rather have the proper infrastructure integrated into the
> security workflow so that the tests are automatically executed
> and test results are send around (compared to the previous status).
That would be nice but that kind of infrastructure gets interesting
when you have DEP-8 tests so I think it makes sense to contribute
some DEP-8 test suite to some packages with regular security updates.
Also this is not going to be easy:
- the test infrastructure needs to have access to unreleased packages
waiting in the security queue (possibly the embargoed one)
- we decided that the LTS team would not use any "queue" in front of the
repository, so that would be problematic to filter packages with failing
tests...
Thus I wonder if it doesn't make sense to have such a service working as
an external gateway: you upload the package to the test service, the
package gets tested and if it's OK it's uploaded to the target repository,
otherwise it's withheld.
> > > - work on security features targeting stretch packages
>
> That's all fairly well covered since people rather like to work
> on new thungs rather than maintaining the old. E.g. rootless x
> is already implemented in stretch. There are some worthwhile tasks
> in terms of upstream work, but not's not in the scope of some
> unused LTS hours.
While I mostly agree with this, there are things which are not
very well covered: we lack good apparmor profiles for many
(server) applications for examples.
> > > - work on stretch to make sure it can be supported over 5 years
> > > (trying to identify packages which are too old/unsupported)
>
> That's also more or less covered I think. Release team is usually
> very supportive to these kinds of request. Most of the problems
> we have a mindset problems at various upstreams.
When I wrote this, I thought in particular of many Java packages
which have new upstream versions which are supported but where we keep
around old versions for various reasons (including because they are
build-depends of other packages).
Filing bugs requesting new upstream versions and having at least a
documented trace of why we lag behind on such packages would be useful.
In the end, introducing a way for each maintainer to document how long
upstream supports each version would be useful. This could be a new
feature of the package tracker.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/
Reply to: