<> = Allocating a DSA Number and writing the advisory text = There's a fairly standard template for this in the security-tracker repository. You can run the command: {{{ bin/gen-DSA --save "CVEs" '#bugs' }}} or (if your package's changelog entry lists CVEs and bug numbers): {{{ bin/gen-DSA --save /path/to/.changes }}} which will allocate a new DSA id from the list and generate a DSA draft. Don't forget to set $DEBFULLNAME and $DEBEMAIL in the environment. Make sure to commit data/DSA/list, so that the ID is allocated. 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 }}} Once this is done, you can edit the saved DSA draft to add some information about the vulnerability, you can use an existing DSA from [[http://lists.debian.org/debian-security-announce/ | debian-security-announce]] as an example. Special case: If updating a previous DSA, note what was wrong/missing about the previous one and how this update is different. When CVE IDs exist for the vulnerability, list them, with a description of the nature of the flaw (buffer overflow, XSS, integer overflow, etc.) and the worst-known exploitability (DoS, privilege escalation, arbitrary code). Note what's possible; don't downplay or overstate the threat. Give brief acknowledgment to the discoverer of the flaw, if they're known. If multiple people worked to assess the vulnerability, note them too. = Checking the regression status once the upload is on security-master = Before releasing a DSA we want to be sure the new version doesn't introduce regressions in its reverse dependencies. This can be verified on {{{seger}}}. * For stable: {{{ seb@seger:~$ elinks /srv/security-team.debian.org/autopkgtest/britney2/data-stable/output/excuses_buildd-stable-security.html }}} * For oldstable: {{{ seb@seger:~$ elinks /srv/security-team.debian.org/autopkgtest/britney2/data-oldstable/output/excuses_buildd-oldstable-security.html }}} The setup used to produce those results is described in details [[https://salsa.debian.org/security-team/britney2/-/blob/master/scripts/autopkgtests.md|here]]. = Releasing an update = There now follows a worked example of issuing DSA-2156-1 for "pcsc". Always enter a tmux or screen session first, as the installation process can take a rather long time and it shouldn't be interrupted. Run `dak new-security-install`: {{{ skx@seger:~$ screen skx@seger:~$ cd /srv/security-master.debian.org/queue/embargoed/ skx@seger:/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:~/security-tracker$ bin/gen-DSA 1317-1 tinymux "buffer overflow" CVE-2007-1655 417539 [The advisory text is previewed] user@host:~/security-tracker$ 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. = 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: * 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: debian-security-announce@lists.debian.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; you can do that directly on {{{seger}}}, which is a popular option with existing team members, but otherwise you'll of course need a correctly configured local MTA: {{{ bin/sign-advisory.sh DSA-2498-1 /usr/lib/sendmail -ti < DSA-2498-1.signed }}} Note that if the advisory contains non-ASCII characters, for instance in first or last names for credits, we need to send it as UTF-8. In this case the following two lines need to be manually added to the DSA text headers '''before signing the advisory with `sign-advisory.sh`''': {{{ Content-Transfer-Encoding: 8bit Content-type: text/plain; charset=UTF-8 }}} Due to the announce list only accepting inline signed mails, it is though still recommended to only use ASCII in DSA announcements, and thus changing names of people to ASCII variants. It is known that Sylpheed has a bug that might sometimes result in wrong signature reported for users using non-UTF-8 locales (DebianBug:580896). Make sure your MTA does not relay directly to gmail or another provider implementing DKIM: lists.debian.org rewrites the subject, and this breaks the DKIM signature. If you send a DSA sponsoring a text prepared by someone else, make sure to set the `From:` to the person you are sending the mail on behalf of and the `Sender: ` to the address of the person actually sending and signing the mail. = 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".) = Creating website pages (not needed in the general case) = Every announce is also published as a [[http://www.debian.org/security/#DSAS|webpage]]. The Debian WWW team takes care of updating these. In cornercases it might be needed to create the outselves: In order to create and upload this website page on your own, you have to be in the [[https://salsa.debian.org/webmaster-team/webwml|webwml project]]. 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 [[https://salsa.debian.org/webmaster-team/webwml/tree/master/english/security|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 [[ https://salsa.debian.org/webmaster-team/webwml/blob/master/english/security/parse-advisory.pl|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 Git repository: {{{ git add 2007/dsa-1317.wml 2007/dsa-1317.data }}} And commit, using the advisory subject as message: {{{ git commit -m '[DSA 2510-1] extplorer security update' }}} and push it {{{ git push origin master }}}. = 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 }}} After recieving the REJECTED mail a fixed upload might reuse the original version since dak on security masters performs the required cleanups (In former times this required a roundtrip to notify wb-team@buildd.d.o which is not needed anymore). = BinNMUs = 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. Example used to reschedule the binNMU for `libxrender` after the fix for `libx11` for [[https://www.debian.org/security/2015/dsa-3224|DSA-3224-1]]: {{{ user@buildd:$ wb nmu libxrender . ANY . wheezy-security . -m 'Rebuild against fixed libx11 for DSA 3224' --extra-depends 'libx11-dev (>= 2:1.5.0-1+deb7u2)' }}} Access to wb needs to be setup separately from security group membership. More details can be found at https://lists.debian.org/debian-wb-team/2015/05/msg00001.html. {{{#!wiki warning '''Warning''' For multiarch enabled packages this possiblity is currently blocked by DebianBug:782596 }}} = Give-Backs = If a build fails (temporarily) you might want to give back the build and let try the buildds to build the binary package again. This can be done with the same syntax as described in [[https://release.debian.org/wanna-build.html|wanna-build]]: {{{ user@buildd:$ wb gb iceweasel . armhf . -d wheezy-security }}} = FAQ & common issues = == 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 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. == The DSA refers to TEMP issues (issues with no CVE id assigned) == When the DSA report includes fixes to issues without CVE id assigned, the security tracker cannot build the cross-reference to `DSA/list`. Therefore, the information that the security upload fixes CVE-XXXX issues (a.k.a. TEMP issues) needs to be included manually. For example, DSA 3547-1 announces that imagemagick_8:6.7.7.10-5+deb7u4 fixes a vulnerability without an CVE id. The following line in `CVE/list` should be added manually: {{{ CVE-2016-XXXX [Multiple minor security issues] - imagemagick 8:6.8.9.9-7 (bug #811308) + [wheezy] - imagemagick 8:6.7.7.10-5+deb7u4 NOTE: CVE Request: http://www.openwall.com/lists/oss-security/2016/02/22/4 }}} == A specific autopkgtest run needs to be retried == This is done by hitting the corresponding [[https://ci.debian.net/api/doc#POST_/v1/retry/{run_id}|debci API endpoint]], for instance with something like this: {{{ seb@localhost:~$ curl -v -H "Auth-Key: $DEBSEC_CI_TOKEN" -X POST https://ci.debian.net/api/v1/retry/$run_id }}}