Allocating a DSA Number

The procedure for allocating a unique DSA number is to add an entry to data/DSA/list in the secure-testing repository. The gen-dsa script in the secure-testing repository takes care of this for you (see below). Please do this before releasing a DSA to avoid accidental duplication. In this commit you may also want to include the version number of the fixed package. For example:

 [squeeze] - libxml2 2.7.8.dfsg-2+squeeze2
 [lenny] - libxml2 2.6.32.dfsg-5+lenny5

Releasing an update

There now follows a worked example of issuing DSA-2156-1 for "pcsc".

Always enter a screen first. The installation process runs for about 20 minutes, and it shouldn't be interrupted. If, for any reason, the command is terminated (disconnect, ^C, kill, etc.) archive breakage will occur.

Run new-security-install:

skx@chopin:~$ screen
skx@chopin:~$ cd /srv/security-master.debian.org/queue/embargoed/

skx@chopin:/srv/security-master.debian.org/queue/embargoed$ dak new-security-install pcsc*.changes
Non-dak user: skx
Would create ['/srv/security-master.debian.org/queue/embargoed/COMMENTS/ACCEPT.pcsc_1.2.3-4+squeeze1'] now and then go on to accept this package, if you allow me to.
Press Enter to continue
Locking unchecked
Installing accepted packages into security archive
Domination
Updating Packages and Sources files... This may take a while, be patient
Updating Release files...
Triggering security mirrors... (this may take a while)

If you had the globbing incorrect you can still Ctrl-C at the "Press Enter to continue" prompt.

To generate the advisory:

user@host:~/secure-testing$ bin/gen-DSA 1317-1 tinymux "buffer overflow" CVE-2007-1655 417539
[The advisory text is previewed]

user@host:~/secure-testing$ bin/gen-DSA --save 1317-1 tinymux "buffer overflow" CVE-2007-1655 417539
[The advisory text is now saved in ./DSA-1317-1 and the data/DSA/list entry added]

If the DSA id has been used before the script will refuse to continue. The script relies on the DEBFULLNAME and DEBEMAIL env vars that are used by devscripts. If you omit the DSA number the script will pick one for you. The script will ask you for any of the fixed version numbers.

There's also gen-DSA.py which is similar. It obtains information from the queues and hence some parts need to be run on security-master. Check its documentation for the gory details.

Troubleshooting

Stable and oldstable sharing the same upstream tarball (probably not valid with the new dak)

If you upload e.g. oldstable and then the stable update which shares the same tarball dak will unfortunately reject the package as the tarball is already there (building with -sa also doesn't help, dak won't find the tarball in this case). As a workaround until this is fixed in dak you can move the tarball to a different location after uploading the first update and then upload the second update.

Packages end up in security-master NEW queue

The built packages may end up in security-master's NEW queue instead of the (un)embargoed queues. This is the case when the package has a udeb.

You need to ask ftp-master to approve the packages from NEW. However, note that plainly approving them will install them into the security archive directly which is not what's normally desired. Ftp-master can add the override manually and then reprocess it through unchecked. Then it ends up in the embargoed queue like other packages.

There's an error in the advisory text

If after sending the DSA an error is discovered in the advisory text, it can be dealt with according to the severity of the error. In any case, it can always and should be corrected on the web version of the DSA. Commit an update to the www repository (or ask debian-www) as per the instructions below. If the error is significant, a clarification can be sent to debian-security@lists.debian.org. If it's really confusing, an updated advisory may be sent to the security announce list.

Fix was incomplete or introduced regressions

The released package did not (fully) fix the issue, or caused regressions. Create new flawless packages and have them built. Send out a new advisory with DSA-XXXX-1 replaced by DSA-XXXX-2. Use the first paragraph of the free form text to explain the regression and the fix, followed by "For reference, the original advisory text follows", followed by the original advisory text (for reference).

In data/DSA/list, -2 updates only get added if they have security impact (incomplete fix), not if it was a regression fix, because the latter doesn't change the fact that the actual vulnerability was fixed in the version released in -1.

Creating website pages

Every announce is also published as a webpage. In order to create and upload this website page, you have to be in the webwml group. If you are not, you can request to join it. The www team is happy when we upload our own web pages.

The relevant directory is webwml/english/security/, where you can find useful scripts and one directory for each year.

Over the output of ./bin/gen-DSA (or the mail), you have to run parse-advisory.pl to create the appropriate WML files:skx@klecker:~/webwml/english/security$ ./parse-advisory.pl ~/dsa-1317-1 .. ..

Add the two new files to the CVS repository: cvs add 2007/dsa-1317.wml 2007/dsa-1317.data

And commit, using the advisory subject as message: cvs commit -m '[DSA 2510-1] extplorer security update'

If you need more information about how CVS works, take a look to the tutorial page from the webwml group

Sending out the announcement to debian-security-announce

Mail the advisory template file to debian-security-announce@lists.debian.org with an appropriate subject.

It must satisfy the following conditions, or it may be silently dropped:

If you use bin/gen-dsa to generate your DSA template, the following snippet can be used to send the mail, providing you have a correctly configured local MTA:

(head -n 4 DSA-2498-1; tail -n +5 DSA-2498-1 |gpg --clearsign) | /usr/lib/sendmail -ti

Tips for the DSA body text

Rejecting

dak new-security-install does not support rejecting, you need an "echo NOTOK > COMMENTS/REJECT.package_version" in the queue directory. For example, to reject ffmpeg-debian 0.svn20080206-18+lenny2:

echo NOTOK > /srv/security-master.debian.org/queue/embargoed/COMMENTS/REJECT.ffmpeg-debian_0.svn20080206-18+lenny2

New packages need to have the version bumped since the buildds might be confused if they get the same version twice.

If you reject packages, always make sure to notify wb-team@buildd.d.o, because the buildd's don't understand that something has been rejected on our side (this is important in particular if you plan to reuse the version with a corrected package you want to upload).