summaryrefslogtreecommitdiffstats
path: root/doc/how-to-DTSA
blob: 3a2b76ba67ff2eadba74a192ebbe2eb965856066 (plain) (blame)
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
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/index.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 ".1lenny1". 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 install the packages in the security archive with something
like:

dak new-security-install DTSA-36-1 mydns_1.1.0-7.1lenny1_*.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.

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
==========

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



22:37 < micah> sf: you got the key! now to rescue the princess

© 2014-2024 Faster IT GmbH | imprint | privacy policy