1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
|
<html>
<head>
<title>Debian testing security team</title>
</head>
<h1>Goals</h1>
<p>
The Debian testing security team is a group of debian developers
and users who are working to improve the state of security in
Debian's testing branch. Lack of security support for testing has
long been one of the key problems to using testing, and we aim to
eventually provide full security support for testing.
</p>
<h1>Activities</h1>
<p>
The team's first activity was to check all security holes since the
release of Debian 3.0, to ensure that all the holes are fixed in
sarge and to provide a baseline for future work.
</p>
<p>
Now the team is tracking new holes on an ongoing basis, making sure
maintainers are informed of them and that there are bugs in the
Debian BTS, writing patches and doing NMUs as necessary, and
tracking the fixed packages and working with the Debian Release
Managers to make sure fixes reach testing quickly. Thanks to this
work we now have
<a href="http://spohr.debian.org/~joeyh/testing-security.html">a
web page</a>, that tracks open security holes in testing.
</p>
<h1>Future plans</h1>
<p>
After sarge is released and once the autobuilder infrastructure is
in place, we hope to begin issuing security advisories for holes in
testing, and providing fixed packages immediatly on
security.debian.org or a similar site, without the regular delay
involved in getting a fixed package into testing.
</p>
<h1>Data sources</h1>
<p>
Currently we're limiting ourselves to tracking security holes that
have been the subject of a Debian Security Advisory, or are in the
<a href="http://www.cve.mitre.org/cve/index.html">CVE</a> database.
It's very helpful to us if bug reports and Debian changelog entries
include CVE numbers for security holes. If you don't have a CVE
number, we can help you get one.
</p>
<p>
The team maintains a database (actually some files) that contain
our notes about all CVEs, CANs, and DSAs. This database is available
<a href="http://svn.debian.org/wsvn/secure-testing">from subversion</a>,
and may be checked out from
<tt>svn://svn.debian.org/secure-testing/</tt>.
</p>
<h1>Uploads to the secure-testing repository</h1>
<p>
To upload a package to the secure-testing repository, follow this
checklist:
<ol>
<li>Only upload changes that have already been made in
unstable and are blocked by reaching testing by some other
issues. This is both to keep things in sync once the
new version from unstable reaches testing, and to avoid
breaking secure-testing too badly with fixes that have not
been tested first in unstable.</li>
<li>Only make uploads for issues that the testing security
team plans to issue a DTSA announcement for.</li>
<li>Use a version number that is less than the version
number of the fix in unstable, but greater than the version
number of the fix in testing. For example, if the fix is in
a new upstream version 1.0-1 in unstable, upload version
1.0-0.1etch1 to secure-testing. If the fix is in version
1.5-10 in unstable, use version 1.5-9etch1 in
secure-testing.</li>
<li>Use "testing" as the distribution in the
changelog.</li>
<li>Build the package in a testing chroot using pbuilder
so that all the dependencies are ok.</li>
<li>Test the package.</li>
<li>Upload to <tt>secure-testing-master.debian.net</tt>.
Here is a dput.cf snippet for that upload queue:
<pre>
[secure-testing]
fqdn = secure-testing-master.debian.net
method = ftp
incoming = /pub/UploadQueue/
login = anonymous
</pre>
</li>
</ol>
</p>
<p>
Note that the above instructions are provisional until we get
everything set up.
</p>
<h1>Members and contacting the team</h1>
<p>
While some individual members may have sources of prior information
about security advisories (such as vendor-sec), the team as a whole
operates only on publically available information. Any Debian
developers with an interest in participating are welcome to join
the team, and we also welcome others who have the skills and desire
to help us.
</p>
<p>
The team can be contacted through its mailing list,
<a href="http://lists.alioth.debian.org/mailman/listinfo/secure-testing-team">secure-testing-team@lists.alioth.debian.org</a>.
There is a second mailing list,
<a href="http://lists.alioth.debian.org/mailman/listinfo/secure-testing-commits">secure-testing-commits@lists.alioth.debian.org</a>
that receives commit messages to our repository. An
<a href="http://alioth.debian.org/projects/secure-testing/">alioth
project page</a> is also available.
</p>
<hr>
$Id$
</html>
|
