[Secure-testing-team] Mini-meeting at DebConf - minutes

[Neil McGovern]

Hi all,

At a 'working lunch' during DebConf about security in Debian, we came up with
the following bits and pieces. Hopefully this should help get a quicker and
more efficient response to security in Debian.

Increase the visibility of testing security
-------------------------------------------
It was pointed out (I think by me) that a lot of the work isn't visible, as it
often involves making sure things get pushed through unstable, rather than
issuing a DTSA. This is especially true at release time.

One possibility would be to use debsecan to automatically work out what has
been moved where, and generate reports based on this. However, the number of
false positives, and email format of debsecan needs improvement before this can
occur.

More bugs should be filed against packages with open security vulnerabilities.
It seems that the maintainers are often (somehow) unaware that their package
has an open issue.

For unstable fixes, we should just NMU with no delay or notification (making
sure that it's just the security fix though) to ensure that migration can start
to happen as soon as possible.

How to improve the tracker[0]
-----------------------------
Public submission to the tracker would help a lot, we lack the current
man-power to effectively track everything. Part of the problem involved with
this is the way the advisory and code system is in the same repository as the
tracking data. This should be split up.

It would be nice if the tracker data was somehow integrated with the PTS as
well.

How to get maintainers to help us
---------------------------------
It seems that maintainers are a little confused as to what should happen if
there's a security issue, mostly due to the documentation being out of date in
various places (dev-ref etc). It was also pointed out that the vast majority of
security uploads should be done with a high priority. See [Documentation]
below.

An additional NM question could be introduced, along the lines of "How long
should you support your package for security issues?" as some maintainers seem
to be resistant to fixing bugs in their packages that no longer exist in
unstable.

Lenny plans
-----------
Some packages were released with etch that are very hard to support by the SST.
It would be good to try and avoid these getting into testing or even unstable
all together.

Embedded code copies are still causing problems. There's a policy bug open
(http://bugs.debian.org/392362), and Neil McGovern will ask the RMs to make 'no
embedded code copies' a release goal.

Documentation
-------------
Documentation should be written/updated for the following groups:
Maintainers: how to be nice to the security team.
Tracker submitters: how to help us (one for DDs, and one for non-DDs).
dev-ref: it could do with a lot of improvement to reflect current practice.

A 'bits from the security team' to d-d-a may be useful once this is done.

Disto agnostic patch/tracking/magic system/conference/mad-idea
--------------------------------------------------------------
A mad idea was formed to look at the possibility of creating a more harmonised
approach to security in Linux generally. A patch repository and/or tracking
system that could be used for all distributions may be useful. This may help
create a more unified approach to security, and stop work being duplicated.

Additionally, a global Linux distro security teams summit may be something that
would help kick-start this approach.


I think this is fairly accurate. Any comments?

Cheers,
Neil
[0] http://security-tracker.debian.net/
-- 
<hermanr> 10 people enough for a Debconf?  If they were all Germans, maybe...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20070625/4005dde5/attachment.pgp