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