add my talk

git-svn-id: svn+ssh://svn.debian.org/svn/secure-testing@1441 e39458fd-73e7-0310-bf30-c45bca0a0e42

5 files changed, 680 insertions, 0 deletions

diff --git a/doc/talks/debconf5/Makefile b/doc/talks/debconf5/Makefile
new file mode 100644
index 0000000000..07320e45c8
--- /dev/null
+++ b/doc/talks/debconf5/Makefile
@@ -0,0 +1,39 @@
+TEX    = latex
+DVIPS  = dvips
+PDFTEX = pdflatex
+
+.PHONY: clean
+.SILENT: all dvi clean
+
+
+SOURCES = $(shell ls | grep -e '\.tex')
+SOURCE  = ts_debconf5
+
+all: pdf
+
+pdf: $(SOURCES:.tex=.pdf)
+
+dvi: $(SOURCES:.tex=.dvi) 
+
+ps:  buildps
+
+buildps: $(SOURCES:.dvi=.ps)
+
+.tex.dvi:
+	$(TEX) $(TEXARGS) $(SOURCE)
+
+.dvi.ps:
+	$(DVIPS) $(DVIPSARGS) $<
+
+ts_debconf5.pdf: ts_debconf5.tex
+	$(PDFTEX) $<
+	$(PDFTEX) $<
+
+.tex.pdf:
+	$(PDFTEX) $(PDFTEXARGS) $<
+
+clean:
+	rm -rf *.log *.nav *.out *.snm *.toc *.aux
+
+distclean: clean
+	rm -rf *.pdf *.dvi *.ps
diff --git a/doc/talks/debconf5/debian-swirl.png b/doc/talks/debconf5/debian-swirl.png
new file mode 100644
index 0000000000..500075c597
--- /dev/null
+++ b/doc/talks/debconf5/debian-swirl.png
diff --git a/doc/talks/debconf5/notes b/doc/talks/debconf5/notes
new file mode 100644
index 0000000000..66b4dada55
--- /dev/null
+++ b/doc/talks/debconf5/notes
@@ -0,0 +1,104 @@
+5 intro
+10 how it works
+5 how to help
+10 how well it works
+?? next steps
+15 questions/discussion
+--
+45 minutes
+
+intro:
+	What is the testing distribution:
+	- Query audience: Who doesn't know how testing works.
+		- Automatically stabelised version of unstable.
+		- Dependency, testing delay and RC bug metrics used to
+		  decide when to update packages.
+		- Unique amoung linux distributions.
+		- Unique challenges, including security.
+	
+	Why testing cannot be secured: <next slide>
+	All of these are real challenges the team faces.
+
+	- Query audience: raise hands if you use testing
+		(Don't worry, the camera isn't pointing at you -- noone
+		will know!)
+	
+	Using testing is still attractive:
+		- desktop users
+		- custom Debian distributions
+	
+
+how it works:
+
+	Team:
+	- Formed last fall (5 years after testing)
+	- Open team of DDs and non-DDs
+	- Members participate because:
+	
+		- Hired by custom Debian distro that is based on testing.
+		  (Skolelinux, Univention Corporate Server)
+		- University deploying sarge on a large scale
+			
+			(Above is 1/2 of team; which explains why it took
+			this long to start the team)
+		
+		  which needs to keep track of security issues anyway.
+		- Want testing to be usable by our users and for faster
+		  releases.
+		- Want to make unstable more secure.
+		- Like the transparency of the team.
+		- "It's fun"
+	- Team is designed to scale well and be easy to grow.
+	- Low barriers for entry to team.
+	- No team members currently have priviliged info (vendor-sec).
+		- And we don't care! Much.
+
+	Data:
+	- [ Maybe do a quick demo of running through CAN list ]
+	- Track data from DSAs, CVE ids, debbugs, full-discolsure, bugtraq.
+	  Mostly CVE.
+	- Not vendor-sec -- open team
+	- Use simple database to track holes
+	- Just keeping up with this data is a large portion of our work.
+	- And it's parallizable.
+	- And its very helpful if all debian changelogs mention CVE ids.
+
+	Getting things fixed:
+	- Team members work on finding/writing patches and bug filing.
+	- Some (DD) members work on NMUs to unstable.
+	- In the future, we hope to do advisories and NMUs via
+	  testing-security direct to testing.
+
+how to help:
+
+	DDs: <next slide>
+
+	anyone:
+	- grab an unfixed bug from the page, fix it, file a bug
+	  with a patch, NMU as necessary, communicate to the team the
+	  fixed package version and bug number.
+	- join the team, help check CANs, develop policy, etc
+	- ideas/patches to improve the interface, website and translations
+	- adapt the changelog autochecker from ubuntu (the python script
+	  that scans ubuntu changelogs and generates
+	  http://people.ubuntu.com/~pitti/ubuntu-cve.html)
+
+how well it works: "Lies, damn lies, and .."
+
+	- Stats arn't my thing.
+	- Too busy working to try to gather much data.
+	- Most time-to-fix comparisons are innately flawed in one way or
+	  another.
+	- Show the tracking page and explain how to read.
+	- One comparison: <next slide>
+	- Better comparisons would involve looking at kernel security holes
+	- Or putting up honeypots
+
+next steps
+
+	- making DTSA announcements
+	- getting fix delay down to 4 days
+	- i386 support to start with
+	- autobuilders, etc..
+
+<last slide>
diff --git a/doc/talks/debconf5/testing-security.paper b/doc/talks/debconf5/testing-security.paper
new file mode 100644
index 0000000000..7f7403bdbf
--- /dev/null
+++ b/doc/talks/debconf5/testing-security.paper
@@ -0,0 +1,450 @@
+# Securing the Testing Distribution #
+
+Joey Hess, DebConf5, Helsinki Finland
+
+----------------------------------------------------------------------------
+
+## Introduction ##
+
+Debian's unique "testing" distribution is a potentially useful distribution
+for both Debian end users and Custom Debian Distributions, who need a
+reasonably up-to-date but not unstable version of Debian. One of the
+distribution's main downfalls in attracting users has always been the lack
+of security support. Over the past year, efforts have begun to change that.
+
+## The "testing" Distribution ##
+
+Debian's "testing" distribution is intended to be an automatically
+stabilised version of Debian unstable, which is, in theory, kept free
+of most of the release critical bugs that block a Debian release, while
+still containing reasonably up-to-date software. Testing is intended to be
+suitable as the basis for a stable Debian release at all times.
+
+Testing grew out of the difficulty of managing a release based on the
+unstable distribution. Before the advent of testing, Debian releases began
+by taking a snapshot of unstable, fixing any show-stopper bugs, testing it,
+and eventually releasing the snapshot as stable. As Debian grew larger and
+supported more architectures, this process did not scale well, freeze
+periods became ever longer, and Debian releases more out of date and less
+internally consistent. These problems led to the invention of the testing
+distribution in 2000 by Anthony Towns.
+
+Updated packages reach testing under the control of a program (`britney`)
+which ensures that several conditions are always met before a package in
+testing can be updated to a newer version:
+
+  * The new version cannot have more release critical bugs than the
+    version already in testing.
+  * The new package has to have aged and been tested for 10 days in
+    Debian's "unstable" distribution, to help ensure it has no serious bugs.
+    However, this delay can be reduced to 5 or even 2 days if packages have
+    an urgent reason to be updated.
+  * The new version of the package must have been built successfully on
+    all the architectures Debian plans to release.
+  * All the dependencies of the new version must be satisfied by packages
+    in testing.
+
+Handing most of the day-to-day management of a linux distribution over to a
+program is a bold and unique idea among linux distributions, and making it
+work has involved some unique challenges, many of them beyond the scope of
+this discussion. On the whole, though, the resulting distribution has been
+useful for its intended purpose of serving as a base for stable Debian
+releases.
+
+But ever since it was introduced, testing has seemed an attractive
+distribution for other purposes as well. It's seemed useful for those who
+need newer software than stable, such as updated desktop software, but
+cannot deal with the problems inherent in using unstable. One example is
+installing Debian on hundreds of desktops at a company or school, another
+is installing it on a single computer which one does not have much time to
+maintain. A third example is a Custom Debian Distribution, such as
+[Debian-Edu](http://skolelinux.org).
+
+While testing is used in all of these ways, a nasty little problem has kept
+it from being widely used, limiting its users to a few with enough manpower
+to do a lot of additional work, and a few who would rather not admit they're
+using it. That problem is the difficulty in securing this distribution.
+
+## Problems With Securing Testing ##
+
+There are many problems that keep testing from being secure, and most have
+their roots in the same conditions that are used to automatically control
+the upgrading of packages in testing. Indeed, every one of those conditions
+causes its own problems that can keep a security update in unstable from
+reaching testing in an appropriately fast time span for testing to be safe
+and secure.
+
+  * Most security problems are release critical bugs, but if the package in
+    testing has additional release critical bugs besides the security fix,
+    these can hold a crucial security fix out of testing indefinitely.
+
+    The only way to avoid this is by back-porting the security fixes to the
+    package version that is in testing, but besides often being difficult
+    and introducing new bugs, back-ports need an upload queue like
+    testing-proposed-updates or testing-security, and Debian has not kept
+    these queues functional between stable releases.
+  * The built-in delays in propagation of packages to testing keep any
+    security fix out of testing for at least a couple of days, and possibly
+    longer if it was not marked as being of high urgency.
+
+    Release managers are able to reduce these delays, but some delay still
+    exists, and reducing the delay increases the risk of buggy packages
+    entering testing, which has to be weighed against the security problem
+    if testing is to meet its original purpose.
+  * If a package fails to auto-build on even one architecture, or if an
+    architecture's auto-builder is slow or backlogged, this will keep it
+    from reaching testing.
+
+    Release managers are able to force in a package on the architectures
+    for which it's already built, but breaking the consistency of testing
+    like this can cause other problems and must be done with care.
+  * A new version of a package often has dependencies on other new
+    package versions, and anything that delays those packages from reaching
+    testing can delay a security fix.
+
+    Unlike all the other problems listed above, no solution is known for
+    this problem. It can be ameliorated by avoiding overly tight library
+    dependencies, but not avoided.
+  * Testing is based on unstable which is always in a state of flux and for
+    which security is by no means guaranteed.
+
+All of these problems seem so insurmountable that for years no-one dared to
+try to work on making testing more secure. Recently though a team has
+formed that intended to do that, although the problems above remain as
+constraints that must be constantly worked around.
+
+## The Testing Security Team ##
+
+The testing security team was formed in the fall of 2004. It is an open
+team which currently has a combined membership of half a dozen Debian
+developers and users. 
+
+Team members spend between a few hours, up to a day or two of work time per
+week on tracking and fixing security issues in testing. This is a fairly
+large ongoing time commitment for a volunteer group, and in a survey of
+some of the participants, they gave some reasons for working on the
+security of testing that are not common in Debian, as well as some that
+will be familiar to many Debian developers:
+
+  * One member works for a organization which is deploying Debian sarge
+    on a large scale and needs to keep track of security issues anyway.
+    
+  * One member works for the Debian-Edu distribution, which is based on
+    Debian sarge, had to provide its own security support for its prior 
+    release (Skolelinux) which was based on Debian woody, and needs to deal
+    with security holes in testing.
+  
+  * One member works on another derived distribution (Univention Corporate
+    Server), which is not based directly on sarge, and needs to keep track
+    of security issues and cherry-pick fixes from Debian, and finds tracking
+    and fixing security holes in testing a useful way to do this.
+  
+  * One member wants to work on Debian as a whole, not just on maintaining
+    some packages, and finds working on security interesting.
+    
+  * Several members are interested in helping sarge release.
+  
+  * Several members want testing to have security support since they
+    perceive it to be a useful alternative to stable for some Debian users.
+    
+  * Several members pointed out that the testing security team also makes
+    Debian unstable more secure.
+    
+  * Several members appreciate the openness and transparency of the testing
+    security team, in which everything is done in public mailing lists, bug
+    tracking systems, and code repositories; compared to the stable
+    security team which does many things in secret.
+    
+  * At least one member thinks that "it's fun".
+
+Half of the members of the team have day jobs that involve large scale
+Debian deployments, or distributions derived from Debian, all based on
+the testing distribution. This could explain why it took four years from 
+the introduction of testing to the formation of this team; it took nearly
+that long for such uses of testing to become both necessary and
+conceivable, and the pressure of trying to do these things with testing has
+been a powerful motivator for many team members. If that is the case then
+we can hope to see the team grow as others find themselves in similar
+positions.
+
+The testing security team is designed to scale up well and be easy to grow.
+All of the work is innately divisible; our database of potential security
+issues allows members to claim issues to check, and fixing the issues also
+parallelises nicely. Little communication is needed between team members;
+indeed days go by with the only communication being automatic updates on
+who has checked which issues and what holes have been fixed. 
+
+The barriers for entry to the team are as low as possible; team members do
+not need to be Debian developers, the team operates on public information
+about security issues, so there are no confidentiality requirements. The
+only significant requirement is that team members have the time and skills
+to do the work.
+
+Indeed one of the goals of the talk which this paper accompanies is to find
+someone new in the audience who can join the team. If you are interested or
+wish to contact the team, our mailing list is
+<secure-testing-team@lists.alioth.debian.org>.
+
+## Tracking Vulnerabilities ##
+
+A large part of the day to day job of the testing security team is simply
+keeping track of security issues as they are discovered and announced,
+checking whether they affect testing, and tracking fixes as they make their
+way from unstable to testing. Some of this has been automated, but a lot of
+the work must still be done by hand, and this work occupies a large part of
+the total time spent by the team on security.
+
+Different team members monitor different sources of data about new security
+holes, including the [bugtraq](http://www.securityfocus.com/archive/1) and
+[full-disclosure](http://lists.grok.org.uk/full-disclosure-charter.html)
+mailing lists, the Debian bug tracking system, security advisories from
+Debian stable, and security advisories from distributions related to
+Debian (such as Ubuntu) and not related (such as Gentoo).
+
+Unlike Debian's stable security team, we do not have access to the
+vendor-sec mailing list where unreleased security holes are disclosed for
+coordinated release by many linux distributions. From time to time we may
+be forwarded such information but then we have to keep it private until it
+is released, so only one team member will typically know about it. Since
+this makes it hard to work as a team, we prefer to work with disclosed
+security issues.
+
+Keeping all of these sources of security holes straight and correlating
+holes that are often mentioned in multiple places can be challenging.
+Luckily this is not a problem that is unique to this security team, and
+there is already a solution: The security community is standardising on the
+[Common Vulnerabilities and Exposures](http://www.cve.mitre.org/)
+dictionary. CVE is a global way to identify security issues that may affect
+multiple distribution or operating systems. Each new security issue is
+assigned a CVE ID, and these IDs are used to identify the issue in
+advisories, bug reports, changelogs, and so on.
+
+A sample CVE ID is "CAN-2005-1263", which refers to a linux kernel core
+dump privilege escalation. Dozens to hundreds of new CVE IDs are issued
+each week for security holes in linux and many other operating systems and
+other software, and we try to have all the new IDs checked within a day of
+each update.
+
+This is one of the most parallelisable parts of the work of the testing
+security team, and also often one of the most tedious, as the majority of
+CVE entries are for software not in Debian, and some CVEs lack much useful
+information or are unlikely to really be security holes, and we have to
+check them manually, one at a time. Debian contains so many packages and
+there are enough different ways to write the name of a price of software
+that it can involve quite a bit of checking just to see if a given piece
+of software is in the distribution. Also, many CVE items affect multiple
+packages in Debian due to code duplication and static linking, which can
+make checking much harder.
+
+Debian developers can do three things to make the testing security team's
+CVE tracking easier.
+
+1. If a security hole does not yet have a CVE ID assigned, contact the
+   team or someone else and work to get one assigned.
+2. Always list CVEs in the subjects of bug reports about security issues.
+3. Always list CVEs in the changelog for security fixes.
+
+As of June 2005, the testing security team had checked 8600 unique CVEs,
+of which 1054 affected Debian. This included retroactively checking all
+CVEs issued since the release of Debian 3.0.
+
+## Fixing Vulnerabilities ##
+
+The other half of the job of the testing security team is to work with
+developers to get vulnerabilities fixed. Once we have identified a new
+security hole, we will ensure that there is a bug in the Debian BTS for it
+and if the maintainer can use our help, will work to find a patch or new
+upstream release that fixes the hole, and if necessary, team members who
+are Debian developers will make a Non-Maintainer Upload to fix the problem
+in unstable.
+
+Once a package is fixed in unstable, we can automatically track its
+progress into testing, and will work with the release managers and others
+to deal with any issues that might keep it out of testing. Some of the
+techniques we use to deal with problems that might hold a package out of
+testing include:
+
+ * Uploading a back-ported security fix to the testing-proposed-updates
+   queue, if that queue is functional.
+   
+ * Fixing unrelated release critical but not security-related bugs that are
+   blocking the security fix from reaching testing.
+   
+ * Getting hints added to move a package into testing more quickly if it
+   was uploaded with too low an urgency.
+ 
+ * Dealing with problems that cause failure to build from source on the
+   auto-builders, or bringing auto-builder problems to the attention of the
+   package maintainer and/or auto-builder administrators.
+
+ * Getting hopelessly insecure packages removed from testing.
+
+ * Making it easy for the release team to follow what issues are keeping
+   security fixes out of testing, so they can use the above and other
+   techniques. They often do a better job than the testing security team
+   at pushing the fixes into testing.
+
+One further step is needed in the vulnerability fixing process before most
+people will consider testing to really be security supported; that is
+uploading fixes immediately to a temporary repository (such as
+security.debian.org), and posting advisories so users can know a fix is
+available for a security hole.
+
+The testing security team hopes to do this, but is hampered by lack of
+access to security.debian.org and lack of auto-builder support for testing.
+We hope that these infrastuctural issues will be resolved after the release
+of sarge. If not, we do plan to work around them and try to offer a
+security repository and advisories anyway. We consider this very important
+as without these last two pieces, most users will still consider testing to
+be insecure and not security supported, and will not take into account all
+the work we are already doing.
+
+## Results ##
+
+Anyone deciding whether to use testing and rely on the security support
+provided by the testing security team, or to instead use stable, or even
+unstable, would like to see a comparison of how long it takes to fix holes
+in each of these versions of Debian. 
+
+For example, we could examine all security holes for which Debian Security
+Advisories (DSAs) have been issued for stable in the past year, and check
+to see how much longer it took the holes to be fixed in testing. Or we
+could examine all holes that have been known to affect testing and compare
+how long it took to get the hole fixed in unstable with how long it took to
+get the same fix into testing.
+
+But this kind of comparison of how well the fixing of security holes is
+managed is often flawed. Some of the pitfalls include:
+
+  * Security holes differ widely in their severity, ease of exploitation,
+    how many systems are vulnerable, etc. Simply counting security holes
+    is not a good metric, and rating security holes or selecting only
+    "important" holes to concentrate on can be subjective.
+    
+    This becomes very complex when security holes can be combined in
+    different ways to produce a working exploit, as is often the case with
+    remote code execution and local root exploit holes.
+
+  * A single security hole can affect one package, or dozens of packages,
+    and these can be fixed at different times and need to be tracked
+    separately. However, a security hole that affects a dozen packages may
+    still impact fewer machines than a hole that affects a single package.
+    
+  * Not all security holes will affect all distributions, but this doesn't
+    necessarily mean that the distribution with less security holes is more
+    secure. Instead it can mean that fewer people are reporting holes in
+    its code-base, for whatever reason, or that the same holes exist in its
+    code-base, but are not obvious due to code reorganizations. Or fewer
+    holes might exist, but be more more serious. Or expectations of what
+    constitutes a security hole can vary.
+
+    These problems often show up in comparisons of the security of Windows
+    and Linux, and of Linux and other Unix clones.
+
+  * While the testing security team has comprehensive lists of all holes
+    we've identified to affect testing, and have checked every CVE ID
+    since 2002, no equivalent lists exist for stable, and our lists may be
+    incomplete for unstable.
+    
+    The list of stable DSAs is known to be an incomplete list of security
+    holes that affect stable, because the stable security team triages the
+    more important and/or easy to fix hole first, and may never find the time
+    or reason to fix all holes.
+
+    So even getting a list of holes that affect the distributions to
+    compare is problematic, without repeating all the work that has been
+    done for testing, for the other distributions.
+
+The comparisons that follow should be read with the above caveats in mind.
+The only foolproof way to compare the security of two systems is probably
+to put honeypots installed with each up on the internet and watch what
+happens to them..
+
+### Comparing stable and testing ###
+
+A very rough comparison can be done with data the testing security team
+gathers on a daily basis. Since the beginning of this year, we have tracked
+whether security holes are already fixed in testing or not when a DSA is
+issued for the holes.
+
+However, no good data exists for the date that each of these holes was
+fixed in testing, so we cannot compare how much more quickly or slowly the
+fixes occurred, only which distribution fixed it first. And all of the
+caveats above apply; security holes in DSAs vary in severity; DSAs can
+cover multiple packages or holes; multiple DSAs may be released for one
+hole; and a list of DSAs is not a complete list of holes that were
+discovered in this time period.
+
+Of 112 DSAs issued between January and May of 2005, 56 (exactly 50%) were
+not fixed in testing before the DSA was released; 37 (33%) were fixed in
+testing first, and 19 (17%) did not affect software in testing.
+
+### Comparing testing and unstable ###
+
+To track which holes are not fixed in unstable yet, and which holes have
+been fixed in unstable but have not reached testing, we use an
+[automatically updated list](http://newraff.debian.org/~joeyh/testing-security.html).
+
+This list includes a count of the numbers of each type of unfixed hole, and
+comparing these numbers is a useful (if flawed) metric to see if there is
+typically more delay associated with fixing a hole in unstable in the first
+place, or with getting the fix accepted into testing.
+
+Unfortunately historical data is not available for these numbers, however
+they have been roughly equal during most of this year, which suggests that
+on average approximately half of the time to fix a hole is spent in getting
+the hole fixed and into unstable, and half in getting the fix into testing.
+
+One interesting consequence of this is that it might be a better use of the
+testing security teams's time to focus more effort on getting holes fixed
+in unstable, since this is a more tractable problem than working on issues
+that can block a fix from reaching testing, and since this would benefit
+users of both distributions. However, it's probably too soon to tell, since
+the release team was aggressively working on pushing fixes into testing
+during this time period because of the impending release of sarge, and that
+has likely skewed the numbers.
+
+### Further Comparisons ###
+
+Kernel security holes are a class of hole that is especially interesting,
+because it can affect users of all versions of Debian, and because these
+holes can be easily categorised into a few sets:
+
+* remote root exploits
+* local root exploits
+* remote code execution
+* remote denial of service
+* local denial of service
+
+Gathering the data and comparing the security history of testing with that
+of stable during the first six months of 2005 would be a worthwhile
+approach to better characterising the relative security of stable and
+testing.
+
+Other comparisons would be useful, especially if they were based on better
+data and perhaps performed by a statistician. Real-world data about how
+Debian machines are exploited would be even more useful in determining the
+relative value of the work done by Debian's stable and testing security
+teams. 
+
+## Conclusions ##
+
+The mantra that "testing is insecure" has become less true over the past
+year thanks to the work of the testing security team, but much work still
+remains before users can count on the security of testing. The team needs
+to grow to the point that it can begin issuing formal advisories for
+security holes in testing, so that users can begin to take these security
+efforts seriously.
+
+This effort began on the sidelines as a not-quite-official Debian project,
+with many contributors who are not Debian developers; it is already
+becoming a more recognised part of Debian as users, developers and even 
+release managers realise its usefulness, and it can be hoped that this will
+grow into a formal security support for testing on the same par as Debian's
+security support for stable.
+
+---------------------------------------------------------------------------
+
+Copyright 2005 by Joey Hess <joeyh@debian.org>. 
+
+Licensed under the GNU General Public License.
diff --git a/doc/talks/debconf5/ts_debconf5.tex b/doc/talks/debconf5/ts_debconf5.tex
new file mode 100644
index 0000000000..ed8e519be1
--- /dev/null
+++ b/doc/talks/debconf5/ts_debconf5.tex
@@ -0,0 +1,87 @@
+\documentclass{beamer}
+
+
+\mode<presentation>
+{
+}
+
+\usepackage[english]{babel}
+
+\title[] % (optional, use only with long paper titles)
+{Securing the testing distribution}
+
+\author[] % (optional, use only with lots of authors)
+{Joey ~Hess}
+
+\date[] % (optional, should be abbreviation of conference name)
+{DebConf5}
+
+\pgfdeclareimage[height=2cm]{debian-logo}{debian-swirl}
+\logo{\pgfuseimage{debian-logo}}
+
+\begin{document}
+
+\begin{frame}
+  \titlepage
+\end{frame}
+
+\begin{frame}
+  \frametitle{The Debian testing distribution: insecure by design}
+	\begin{itemize}
+	\item
+		dependency hell
+	\item
+		unrelated release critical bugs can block security fixes
+	\item
+		built in "testing" delays
+	\item
+		autobuilder lag
+	\item
+		based on unstable, which has no security team
+	\end{itemize}
+\end{frame}
+
+\begin{frame}
+  \frametitle{How Debian developers can help}
+	\begin{itemize}
+	\item
+		include CVE ids in changeogs and bug reports
+	\item
+		get CVE ids asigned for security holes that lack ids
+	\item
+		don't hide security fixes
+	\item
+		respond quickly to security bugs (or be NMUed)
+	\item
+		communicate with the team
+	\end{itemize}
+\end{frame}
+
+\begin{frame}
+  \frametitle{A rough comparison of stable and testing}
+	112 DSAs issued between January and May 2005
+	\begin{itemize}
+	\item
+		56 (50\%) fixed in stable first
+	\item
+		37 (33\%) fixed in testing first
+	\item
+		19 (17\%) did not affect testing
+	\item
+		XXX (XX\%) affected stable with DSA
+	\item
+		XXX (XX\%) did not affect stable
+	\end{itemize}
+\end{frame}
+
+\begin{frame}
+  \frametitle{Links}
+  	\begin{itemize}
+		\item
+			Testing Security Team: http://secure-testing.alioth.debian.org/
+		\item
+			Tracking page: http://newraff.debian.org/~joeyh/testing-security.html
+	\end{itemize}
+\end{frame}
+
+\end{document}