- How bad security affects Debian as a whole:  
   - RC bugs
   - lots of DSAs, security team overpowered
   - affects our *users*
   - bad publicity ("linux worm")

- Common security issues:
   - bad programming practices (even upstream): improper data input
     handling (XSS, SQL injection in web apps), buffer overflows,
     temporary files
     [ nothing new to see here ]
   - privilege separation (why run as root a daemon?)
   - setuid files
   - installation (bad defaults, like providing a default password
     for a database location)

- Work of the security audit team
   http://www.us.debian.org/security/audit/
   - Loosely cooperation
   - Most work "hidden" not even discussed on list
   - Known by DSAs 
   - Each member focused to one type of bugs
   - Review of packages
   - Some overlap with testing and stable team (bugs in other distros,
     make sure they are in Debian fixed too)
   - # of bugs found (time period, loose dedication) - 122, march 2006,
   - # of DSAs emitted - 82, march 2006 (graph per year or month)
   - Lessons learned:
     * developers have to be explained the security bugs
     * many more *security* bugs present waiting to be 
       removed (specially in non-popular softwarE)
     * too much software, too few hands
     * high time to fix (low) security bugs (temp files) DSA team
       over powered, better if fixed before getting into release

- How can a developer (or anyone) contribute:
   - find out bugs, in packages or (better) upstream
   - don't include software in the distribution if not secure
     (it will be more difficult to support) or do it bug don't let
     it go into testing
     READ
     http://www.dwheeler.com/oss_fs_eval.html#security
     http://www.dwheeler.com/oss_fs_eval.html#detailed_security
   - learn about code analysis tools (grep is your friend)
     also more inmature (more beta) -> more bugs
   - QA, QA, QA
   - help detect bugs (even those fixed by other vendors) and help push
     fixes to other developers
   - educate, educate
     READ http://www.dwheeler.com/secure-programs/
   [ This is not different from the approach taken by M$, mind you ]

- Future projects?
   - Improve automatic tools?
   - seccheck.debian.org ?  (ala lintian.debian.org)
   - Metrics? (if the package is under this value, it cannot go into
     Debian sid or testing)
   - Funded source-code reviews? (Coverity?)
  
- Conclusions and other stuff