Ubuntu Wiki

While handling a security update, one must prepare the upload, then follow these steps to publish.

Publishing an Update to Soyuz

Upload/Build/Publish

1. Prepare your local configuration

2. Set the name of the source package being updated: export SRCPKG="srcpkg1 srcpkg2..."

3. Upload the updated source packages via dput to each release's Security PPA target. Notification about failed builds should be automatically sent to security@ubuntu.com.

4. Wait for the finished builds on all supported architectures to finish and appear at the Ubuntu Security PPA: $UCT/scripts/sis-changes --action check-build $SRCPKG

5. Unembargo by copying the packages into the archive accepted queue with: $UQT/security-tools/unembargo $SRCPKG

Announce Publication

(for main/restricted publications)

1. Assign a USN (format is NNN-S, and the following instructions assume $USN has been set as desired):

   1. For a new issue, run: USN=$(ssh people.canonical.com "~ubuntu-security/bin/get-next-usn" log message) including a log message explaining why and for whom the USN is to be issued for.

   2. For an old issue that needs correction or continuation, start with the issue's original USN, keep NNN and increase S. (e.g. original issue was 42-1, updated USN will be 42-2).

   3. For a new issue that affects different software with identical CVEs, get a new USN normally for the first source package, and then keep NNN and increase S for each additional source package. (e.g. CVE-2008-1693 affected both poppler and koffice, so 603-1 was used for poppler and 603-2 was used for koffice). Please note that different versions of the same software (e.g. emacs21 and emacs22) should not do this, but instead use a single USN with S=1.

2. To create the USN template script, run: $UCT/scripts/sis-changes --download /tmp/pending $SRCPKG && cd /tmp/pending && $UCT/scripts/sis-generate-usn $USN *.changes > ~/new-usn.sh

3. Edit ~/new-usn.sh to include a correct title, summary, action, description, and then limit the binary list to only those affected by the USN. Leave all URLs as-is. Have the description proofread by somebody else.

4. To populate the USN database with the new USN details and generate the template email (sent to security@ubuntu.com), run: bash ~/new-usn.sh

5. Wait until the packages are actually mirrored to the archive; the publisher runs hourly at :03, and updates should usually appear on security.ubuntu.com within 20-40 minutes, depending on the size and number of binary packages. (Note 0403 UTC publication run is skipped due to the Contents generation job.) To verify that the packages have arrived, run: ssh people.canonical.com "~ubuntu-security/bin/check-upload $USN"

6. Once packages are in the archive, GPG sign and send the USN email to ubuntu-security-announce@lists.ubuntu.com; CC bugtraq@securityfocus.com and full-disclosure@lists.grok.org.uk with a Reply-to: header set as Ubuntu Security <security@ubuntu.com>.

7. Approve the USN mail on https://lists.ubuntu.com/mailman/admindb/ubuntu-security-announce. Ensure to reject duplicate mails from you (some list subscribers bounce mails back unmodified). Verify it went through in https://lists.ubuntu.com/archives/ubuntu-security-announce/.

8. Create a new USN page for this USN via staging.www.ubuntu.com. First log into the staging server, then it can be done automatically or manually:

   1. automatically: ssh people "~ubuntu-security/bin/usn-text $USN" | $UST/usn-tools/mutt/bin/publish-usn

   2. manually: Copy&paste the USN email text, but without the file list, wrapped in a "div class=usn" tag, include the cve file path, and a list of all the CVEs, mark for publishing, and add the USN path.

9. Request the web team sync the staging server (ask newz2000)

10. Copy the updated USN database by running: ssh people.canonical.com "~ubuntu-security/bin/push-usn-db"

11. To help reduce the load on security.archive.com, new packages in -security should be automatically copied to -updates at :58. For large updates (OOo, firefox, kernel, kdebase) be sure to verify that they did indeed get copied. If not, ping an archive admin about doing a pocket-copy from -security to -updates. Please note that security fake syncs will need to be manually copied to -updates by an archive admin. (ssh forced-command needed!)

12. Check for any outstanding LP bugs tied to the CVEs that are resolved with the USN. https://bugs.launchpad.net/bugs/cve/YYYY-NNNN

13. Delete SRCPKG from Security PPA.

Editing a Published USN

1. Update the USN database with ssh -t people.canonical.com ~ubuntu-security/bin/edit-usn NNN-S, where NNN-S corresponds to the edited USN, eg 582-2.

2. Copy the updated USN database by running: ssh people.canonical.com "~ubuntu-security/bin/push-usn-db"

3. Republish the USN to the website (see below)

Republishing a USN

1. Delete the USN from http://staging.www.ubuntu.com/.

2. Regenerate template and push: ssh people "~ubuntu-security/bin/usn-text $USN" | $UST/usn-tools/mutt/bin/publish-usn

3. Request the web team sync the staging server (ask newz2000)

Removing a Published USN

1. On people.canonical.com, create/verify a new database with the USN removed, and copy it into place:

   $ cd ~ubuntu-security/usn
   # make a backup of the original
   $ cp ./database.pickle ./database.pickle.bak
   # create the new db:
   $ cd ~ubuntu-security/usn
   $ ../bzr-pulls/usn-tool/usn.py --export --db=./database.pickle > ./orig.yaml
   $ cp ./orig.yaml updated.yaml
   ... edit updated.yaml to remove the USN ...
   $ cat ./updated.yaml | ../bzr-pulls/usn-tool/usn.py --import --db=./database.pickle.new
   # verify the db
   $ ../bzr-pulls/usn-tool/usn.py --export --db=./database.pickle.new > ./verify.yaml
   $ diff ./updated.yaml ./verify.yaml # should be identical
   $ diff ./orig.yaml ./verify.yaml    # should have only the USN removed
   # copy into place
   $ mv ./database.pickle.new ./database.pickle

2. Copy the updated USN database by running: ssh people.canonical.com "~ubuntu-security/bin/push-usn-db"

Local Configuration

1. Make sure ~/.ubuntu-cve-tracker.conf is fully configured (see the u-c-t README), and set the path to the ubuntu-cve-tracker bzr tree check-out: UCT=/path/to/ubuntu-cve-tracker

2. set UQT to the ubuntu-qa-tools tree check-out: UQT=/path/to/ubuntu-qa-tools

3. Set up ~/.dput.cf with the appropriate Security PPA upload entries:

   • [security-dapper]
     fqdn = ppa.launchpad.net
     incoming = ~ubuntu-security/ubuntu/dapper
     login = anonymous
     
     [security-hardy]
     fqdn = ppa.launchpad.net
     incoming = ~ubuntu-security/ubuntu/hardy
     login = anonymous
     
     [security-intrepid]
     fqdn = ppa.launchpad.net
     incoming = ~ubuntu-security/ubuntu/intrepid
     login = anonymous
     
     [security-jaunty]
     fqdn = ppa.launchpad.net
     incoming = ~ubuntu-security/ubuntu/jaunty
     login = anonymous

4. Now you can upload with dput. For example:

   • $ dput -s security-jaunty ./*_source.changes  # dry run
     $ dput security-jaunty ./*_source.changes

Security Proposed PPA

This ppa is a public PPA which builds packages with only -security enabled. It is used to build packages that need wider testing. Packages can either be tested directly from this PPA, or more often pocket copied into the -proposed. A member of ubuntu-archive is required to copy packages from this PPA to -proposed.

To use the security-proposed PPA:

1. Set up ~/.dput.cf to have an entry like this for each release:

   • [security-proposed-jaunty]
     fqdn = ppa.launchpad.net
     incoming = ~ubuntu-security-proposed/ubuntu/jaunty
     login = anonymous

2. Then can upload with:

   • $ dput -s security-proposed-jaunty ./*_source.changes  # dry run
     $ dput security-proposed-jaunty ./*_source.changes

DAK

DAK has been superseded by Soyuz. The old process can be seen in UpdateProceduresDAK.

CategorySecurityTeam CategoryProcess