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
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
|
20:40 < micah> its good you are going through this, so we can note these
various undocumented things that are necessary
20:44 < micah> sf: its like a quest
20:45 < sf> the secure-testing adventure
Upload
======
The upload can be done by any DD and is described in
.../website/uploading.html.
If the orig.tar.gz is already on security.debian.org (either stable-security
or testing-security), then DON'T include it. Otherwise a bug in dak will
prevent the buildds from building it.
It is a good idea to check in the buildlog that all new patches
actually get applied. Maybe you forgot to put them in patches/series
or because of some bug dpatch ignored a patch.
Use debdiff, interdiff etc. Use debdiff on the binary packages, too.
The distribution needs to be "testing-security".
If you append something to the version number currently in testing, use something
like "+lenny1" or ".0lenny1". A simple "lenny1" is not enough because of binNMUs
adding "+b1".
dcut does not seem to work on security-master.debian.org, but someone
in the sec_public group (micah, neilm, sf, jmm) can remove broken
files from the upload queue when needed.
Requirements
============
Only DDs in the sec_public (and possibly the security?) group can
accept the uploads (or even login on klecker). They also need to be
member of the alias that gets the unembargoed build logs. See #88 on
rt.d.o.
Autobuilds
==========
When you have the buildlogs and the builds look ok, you have to sign
the changes file embedded in the buildlog and send it to the buildd
[1]. If you use your own script to do that: the Subject needs to be
exactly as in the buildlog mail, but with a "Re: " prepended.
A summary which buildlogs have arrived for which packages is at [2].
Some time after the buildd has received the signed .changes, it will
upload the packages to klecker to
/org/security.debian.org/queue/unembargoed/. "dak queue-report" gives
an overview, what packages have arrived in the queue.
If a buildd has problems: A list with the admins is at [3].
[1] http://wiki.debian.org/Buildd/BuildLogs
[2] http://www.sfritsch.de/~stf/secure-testing-buildlogs.html
[3] klecker:/org/security.debian.org/doc/buildd-admins.txt
Releasing the packages
======================
When all packages have arrived (or you want to release a subset
because some buildds are broken), go to
klecker:/org/security.debian.org/queue/unembargoed/
You can compare against a package in stable/updates with
LANG=en_GB ~joey/bin/diffpackages -d stable clamav
Otherwise do some debdiffing to ensure that the filelists and
dependencies look correct. You can do this by downloading the
binary packages from klecker and the compare them, like the following:
for i in *lenny1*.deb; do
oldpkg=$(echo $i | sed -e 's/+lenny1//')
debdiff debian.netcologne.de/debian/pool/main/c/cupsys/$oldpkg $i
done|less
If everything looks good, you can install the packages in the security
archive with something like:
dak new-security-install DTSA-36-1 mydns_1.1.0-7+lenny1_*.changes
DTSA-36-1 is an identifier that should be the name of the new DTSA.
However, every identifier can be used only once with dak. So if you
need a second run, use DTSA-36-1a or DTSA-36-2.
"dak new-security-install" gives you an advisory template. This is not
used for DTSAs. Ignore it by choosing Approve to continue, if everything
seems ok. If for some reason the dak run is not what you want, (for example
not all the required arches are listed), you can just choose Quit to abort
the dak run. Do not hit control-c or there will be problems. Quit will
allow you to re-run "dak new-security-install" again with the same DTSA
number without problems.
The dak options as they are presented are confusing:
Approve, [E]dit advisory, Show advisory, Reject, Quit?
Each of those can be triggered by their first letter (Q for quit, etc.),
its not clear why [E]dit looks different.
After the dak run, the new packages appear on security.debian.org and
the mirrors are notified. You should get a mail that the packages are
installed in testing-proposed-updates.
Announcing
==========
Currently, we are not doing DTSA announcements, and instead letting the
scripts include them in the automatic security update emails sent to
secure-testing-announce. However, the below information is kept for
posterity.
If there has been a new stable release since the last DTSA, change the
code names in all the scripts and templates ;-)
How to create the announcement and how to update the tracker is also
described in .../website/index.html
After you sent the announcement to the announce list, you need to
accept the mail on the moderator's page [4]. The sec_public people
should have the password.
Currently sf and luk (and possibly joeyh) can put the new announcements
on the website (it's on alius.turmzimmer.net). These two should not
forget to "chmod g+w" and "chgrp sectadm" the files.
[4] http://lists.alioth.debian.org/mailman/admindb/secure-testing-announce
Troubleshooting
===============
- If something fails with releasing the built packages and you have to restart
dak, use a different DTSA version since they can just be used once.
- If you think the .dak files are just tmp files and you delete them, move the
files from the queue into /org/ftp.root/pub/OpenSecurityUploadQueue and
wait for the cronjob to push this into the queue again with new .dak files
(check file permissions).
22:37 < micah> sf: you got the key! now to rescue the princess
|
