- Allocating a DSA Number
- Releasing an update
- Creating website pages
- Sending out the announcement to debian-security-announce
- Tips for the DSA body text
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.
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) ...long pause... Triggering metadata export for packages.d.o and other consumers Lock released.
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.
Stable and oldstable sharing the same upstream tarball
The first upload (and only the first upload) of any given fixed package to the security build system should include the upstream source (e.g. dpkg-buildpackage -sa or pdebuild --debbuildopts -sa). Use rmadison to find out whether the source is already in the security build archive.
If you have to upload which is new both for oldstable-security and stable-security and furthermore has the same orig tarball, special care needs to be applied when uploading the package. The first one you upload should be built with -sa to include the orig tarball. The second upload for the second suite then should not include the orig tarball in the upload.
Following this, both dak new-security-install and the subsequent upload to ftp.upload.debian.org will work.
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 firstname.lastname@example.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 email@example.com with an appropriate subject.
It must satisfy the following conditions, or it may be silently dropped:
- Subject "[DSA XXXX-1] xxx security update"
- The template must be "gpg --clearsign"d
- The signer must be a Debian Developer in the "security" group.
- There is a signature cache to prevent replay attacks, so you need to make a new signature in case of an error.
The text "Mailing-List: firstname.lastname@example.org" must be in the body text.
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
- The description of the issues shouldn't be taken from MITRE, they have too much irrelevant detail (for our users) in their data. Better look at the patch and make sure you fully understand the issue and are able to write a text on your own, that's usually simpler and better
- Try to give credit to the discoverer where it's known, e.g. "John Woo discovered that an integer overflow...". When they belong to an organisation or company, the company might need to be mentioned (e.g. "John Doe from IT corp".)
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 email@example.com, 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).
Occasionally an issue can be fixed via binNMUs, e.g. if a source package has been fixed and another package has that package in its Built-Using field.
Note that the package to be binNMUed needs to be already in the security archive. Otherwise, a (no-change) sourceful upload is required.
They will end up in the policy queue as long as no package with the same version number has been accepted yet (which can happen with binNMU version skew between architectures). In the latter case, you just have to make sure there are no ACCEPT(ED) comments for the uploads.