Differences between revisions 8 and 9
Revision 8 as of 2010-04-03 14:44:58
Size: 2297
Editor: LucianoBello
Comment: how to know that "all builds are available"
Revision 9 as of 2011-10-24 12:23:53
Size: 3166
Comment: merge the "writing the advisory" section from SecurityDev
Deletions are marked like this. Additions are marked like this.
Line 38: Line 38:
Write an advisory. Examples can be found on klecker in ''/org/security.debian.org/advisories/DSA''. Note that the template advisory generated by ''dak new-security-install'' is broken in various regards; it's better to work from an existing advisory. There's a fairly standard template for this in the secure-testing repository. You can run the command:

{{{
bin/gen-dsa --save <package> <vulnerability> "CVEs" #bug
}}}

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.

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.

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, privelege 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.

= Finally =

Signing the builds for binary:any updates

In contrast to development in unstable, builds for arch:any packages need to be signed by the Security Team. Once they are signed, the compiled packages are uploaded to klecker.

Failed builds can be retried by replying to the buildd mail with a message containing a single line of retry or give-back.

Build mails can be signed with the dpkg-approve-buildd. There's also a config snippet for mutt. You can also manually extract the .changes file from the middle of the buildd log and sign it manually using debsign, or sign it using one of the methods below. After that, send it in reply to the message containing the buildd log. The buildd will eventually upload the package to /org/security.debian.org/queue/embargoed on klecker (this takes from a few minutes to an hour).

Using dpkg-approve-buildd

Adjust http://cvs.infodrom.org/tools/debian/dpkg-approve-buildd?cvsroot=infodrom for your name/email/paths/etc.

Save the buildd success logs to a directory, one per file.

Run dpkg-approve-buildd, passing it the filename to each log mail.

Using mutt and grab-changes.py

Fetch http://devin.com/debian/grab-changes.py ; put it in your $PATH.

Adjust this line for your .muttrc:

send-hook '~t buildd@ ~s success' "set pgp_autosign=yes indent_string='' edit_headers=yes editor='grab-changes.py' fast_reply=yes pgp_create_traditional=yes include=yes pgp_sign_as=username@debian.org"

You'll probably also want something like this to put things back afterward:

send-hook . "set editor='vi' fast_reply=no indent_string='> '"

Reply to each successful buildd notification. With a typical mutt setup you'll have to enter your passphrase only the first time.

Writing the advisory text

There's a fairly standard template for this in the secure-testing repository. You can run the command:

bin/gen-dsa --save <package> <vulnerability> "CVEs" #bug

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.

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 debian-security-announce as an example.

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, privelege 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.

Finally

Once all builds are available (only team@s.d.o has access to this) and the advisory text is ready, send a mail to team@security.debian.org. The update will be reviewed and released as described in the following section.