Secure testing team - Mar 2006 - Keeping us busy in Oldenburg

* Moritz Muehlenhoff:
> - The developer''s reference entry wrt handling security bugs
should
>   be updated/extended, it''s currently too terse and lacks
important
>   information.
One big problem is that it gives developers the impression that *all*
security fixes should be sent privately to the security team, and not
the BTS, even if the issue is already publicly known.
> - 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.
<http://idssi.enyo.de/tracker/status/release/unstable>

It should be pretty accurate, perhaps more than the corresponding page
for testing.
> - 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?
Was it BugScan by chance?  They are gone.
> - 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,
This can be dealt with with tsck, but you need server-side support for
that.  (Not too hard to implement based on the database, especially if
the release tags I suggested are added to the list files.)

Hi,
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).

Cheers,
        Moritz
>--<
Things having to do with Stable Security:

1. The perception of debian-security being broken

Communication issues:
   a. lack of communication with developers who have security bugs
   b. lack of communication with the project as a whole

Infrastructure issues:
   a. no mirrors of security.debian.org (recent heiss article)

Policy issues:
   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)

Workflow issues
   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?)
   b. ...

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
4. tsck
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
  information.
- 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
  to CVEs
- 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