[Secure-testing-team] Keeping us busy in Oldenburg
jmm at inutil.org
Tue Sep 20 14:29:18 UTC 2005
some "agenda" items from Micah (the part above) and from me. Unfortunately
I didn't have had the time to organize the list a bit more, there are
some duplications. Any additions? (IME discussions tend to be more productive
if people have the chance to brainstorm about the topics in advance).
Things having to do with Stable Security:
1. The perception of debian-security being broken
a. lack of communication with developers who have security bugs
b. lack of communication with the project as a whole
a. no mirrors of security.debian.org (recent heiss article)
a. The structure of the debian-security group, its not a delegated
position, there is no clear way of joining, and there is no clear reason
why there are so many people who are part of the group but only Joey is
doing work (ie. there is no clear way of removing people)
a. tracking security issues
b. preparing fixes
c. issuing advisories
d. publishing security information (such as the php security policy)
2. Fixing debian-security
a. ways that testing security can help with stable security?
b. resolving kernel security issues (getting someone from
debian-kernel as a member of debian-security?)
Things having to do with Testing Security:
1. Overview of how people do work to see where we are missing things,
such as watching uploads for CAN fixes? Are there ways to automate
checking if vulnerabilities affect Debian?
2. Documentation of workflow (claiming, filing bugs, working with
package maintainers, etc.) handling kernel issues; embedded source
issues; severity levels; obtaining CVE identifiers; mailing lists to
monitor; websites to frequent/aggregate...
2. key signing ;)
3. Kernel issues
5. Fixing unresolved problems
- We should automate fishing security related bugs from bugs-dist,
which is too crowded to read it completely by hand.
- All currently opened security bugs should be checked wrt versioned
bug tracking and appropriate found/notfound tags should be added
- The developer's reference entry wrt handling security bugs should
be updated/extended, it's currently too terse and lacks important
- Add the proposed syntax improvements from Florian Weimer
We should keep the CAN/list syntax fixed from now, so let's better
make it right
- It would be nice to have a collaborative SVN of security patches.
Finding patches takes time (even if no non-security changes have to
be stripped and if it's only digging in Bugzilla for half an hour)
and it's also handy for review.
- Monitoring publicly available exploits is time-consuming, but there
are some services like the "exploit tree" that make this a bit more
feasible. This could be evaluated so that more urgent matters can
be addressed faster.
- At least one security update for non-free never made it into testing
for several months, because non-free is not fully auto built and due
to arch asyncronity no transition took place. I was told that
unofficial autobuilders for non-free exist. How can we use these to
prevent such issues in the future?
- What can be done to improve kernel support? At least for 2.4 manual
porter building will be required further, how can we prevent situations
where missing kernel builds block transitions? How can we make the
whole kernel with it's plethora of vulnerabilities more transparent?
- We should have a run over all long-standing security issues in sid
and prepare patches/NMUs for as many as possible.
- The tracking page should be generated for sid as well, it seems to me
that security bugs in packages not in testing are currently vanishing
from our radar.
- Add daily syntax checks based on Florian's Python lib code
- Check, which work is required to cope with the change in the CVE naming
scheme. We should also discuss what to do with older CANs already moved
- Generate package specific security overviews for the PTS, this includes
having a complete sweep over the CAN/list to convert information formerly
included in NOTE:s into not-affected and possibly also converting some
severities from low into unimportant
- Add a search function to s-t.debian.net to allow users direct checks,
whether Debian is affected by a vulnerability.
- Review/refine the current DTSA processing process, fix some bugs in
the scripts involved
- I'm planning to finish tsck, so that a system specific security overview
can be generated
- Embedded code copies should be tracked better and more efficiently.
Early stages are already checked in CVN as embedded-code-copies.txt,
but this needs improving. Each maintainer should know best, so we
should use that knowledge. Furthermore it might be fruitful to
evaluate automatic methods. In scientific literature they are called
"type 0 clones" (with types greater than 0 being more complex semantic
clones) and Baxter/Baker have described methods to find them. We should
check, whether free implementations exist. Ubuntu will have such a list
as well, we should keep probably maintain this together.
- There has been an offer by a company for their proprietary solution of
doing static analysis on binaries. There were some organisational hurdles
IIRC, should we come back to them?
- Find a way how security issues should be documented that don't have a bug
and are already fixed
- Packages, which have been removed from testing by the RMs due to security
bugs should be handled separately, they might get lost from our radar,
although they're still installed
More information about the Secure-testing-team