UpdatePublication

Differences between revisions 57 and 58
Revision 57 as of 2011-04-14 18:05:18
Size: 14436
Editor: pool-71-114-233-7
Comment:
Revision 58 as of 2011-04-14 18:09:21
Size: 14313
Editor: pool-71-114-233-7
Comment: more updates for use with the usn microsite
Deletions are marked like this. Additions are marked like this.
Line 73: Line 73:
=== Editing a Published USN === === Republishing/Editing a Published USN ===
Line 76: Line 76:
 0. Edit the USN in http://staging.www.ubuntu.com/usn
 0. Request the web team sync the staging server (ask `rhlee`, else `newz2000` or `mars`)

=== Republishing a USN ===
 0. Log in to http://staging.www.ubuntu.com/user
 0. Delete the USN from http://staging.www.ubuntu.com/usn.
 0. Regenerate template and push: `ssh people.canonical.com "~ubuntu-security/bin/usn-text $USN" | $UST/usn-tools/mutt/bin/publish-usn`
 0. Request the web team sync the staging server (ask `rhlee`, else `newz2000` or `mars`)
 0. Create a new USN page for this by navigating to http://www.ubuntu.com/usn/update/usn-###-#. Via the command line: `w3m -dump http://www.ubuntu.com/usn/update/usn-$USN`. This should return an 'Ok' message (eg, 'Loading USN-1110-1: Ok'). If this returns 'No such USN: usn-xxx', wait a couple of minutes and try again.
Line 104: Line 97:
 0. ask a LOSA to remove the USN from the usn microsite

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

Publishing an Update to Soyuz

Upload/Build/Publish

Stable releases

  1. If also unembargoing a development release from the Ubuntu Security PPA, unembargo the development release first (see below).

  2. Prepare your local configuration

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

  4. 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.

  5. 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

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

    • NOTE: if you are using unembargo to publish from a non-private PPA (eg, ubuntu-security-proposed or ubuntu-mozilla-security), you will have to also get an archive admin to adjust overrides (use find-bin-overrides and give to an archive admin).

Development release

In general, security updates are not under embargo and can be uploaded directly to the development release without a USN. For updates that are embargoed in the development release, the process is similar to the above, but different due to LP: #334858.

  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 the development release's Security PPA target. The distribution name should not contain the '-security' suffix. 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 --include-devel -r <development release> --action check-build $SRCPKG. NOTE: due to a bug in sis-changes, this doesn't actually work so you'll have to check the PPA manually.

  5. When the issue is public, unembargo by asking an archive admin to copy the package to the development release and adjust overrides (you can use the find-bin-overrides script from lp:ubuntu-qa-tools/security-tools for a list of overrides). Eg, to unembargo sudo 1.7.2p7-1ubuntu2 on maverick, you would ask the archive admin to run the following on cocoplum (see ArchiveAdministration for more information):

    $ copy-package.py -b --ppa=ubuntu-security -s maverick --to-suite maverick -e 1.7.2p7-1ubuntu2 sudo
    $ change-override.py -c universe -s maverick sudo-ldap
    • This may need to be done by a someone who is both a member of ubuntu-security and ubuntu-archive

  6. Delete SRCPKG from Security PPA for the development release. This should be done before unembargoing the stable releases to ensure it is copied only to the release pocket, and not the security pocket for the development release.

  7. At this point, the publication for the development release is completed (a USN is not issued for the development release). Proceed to unembargo the stable releases as needed (see above).

Kernel publication

  1. Prepare your local configuration

  2. Set the name of the source package being updated, using the ABI Packages page as a guide (git branches with stars are not handled by the Security Team): export SRCPKG="srcpkg1 srcpkg2..."

  3. Make sure to check the ABI is consistent: $UQT/security-tools/kernel-abi-check

    • This will say if the ABI has changed, and what the version was in the last published USN
    • Make sure you have the latest USN database: cd ${UCT} ; rsync -v -e ssh <username>@people.canonical.com:~ubuntu-security/public_html/usn/database.pickle ./database.pickle

  4. Make sure all the packages are in the archive: $UCT/scripts/sis-changes --action check-build $SRCPKG --ppa ubuntu -r REL

Announce Publication

(for main/restricted publications in stable releases)

  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 the USN was issued.

    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.

    • When announcing kernels, look at the *source.changes file that is now in /tmp/pending to make sure the CVEs for all the releases since the last USN are present. Make sure no CVE fixes have been reverted and are listed in ~/new-usn.sh by mistake, and that all the changelog entries since the last update are listed.

  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). If it is more than 3 hours before the packages are mirrored, then ask #is. 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 with the following headers:
    To: ubuntu-security-announce@lists.ubuntu.com
    Cc: bugtraq@securityfocus.com, full-disclosure@lists.grok.org.uk
    Reply-to: Ubuntu Security <security@ubuntu.com>
    Mail-Followup-to: 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. Copy the updated USN database by running: ssh people.canonical.com "~ubuntu-security/bin/push-usn-db"

  9. Create a new USN page for this by navigating to http://www.ubuntu.com/usn/update/usn-###-#. Via the command line: w3m -dump http://www.ubuntu.com/usn/update/usn-$USN. This should return an 'Ok' message (eg, 'Loading USN-1110-1: Ok'). If this returns 'No such USN: usn-xxx', wait a couple of minutes and try again. Bugs in the microsite can be filed at https://bugs.launchpad.net/usn-website. Urgent issues for problems that are identified as problems with the USN microsite should be directed to mhall119 (coding errors) or a LOSA (admin issues).

  10. Update your local USN database and update the CVE tracker:
    1. cd $UCT; wget -N http://people.canonical.com/~ubuntu-security/usn/database.pickle; ./scripts/sync-from-usns.py

      • For any missing CVEs, run ./scripts/active_edit -p PACKAGE -c CVE for each package and CVE that was fixed by the USN, and fill in the details in active/CVE with an editor.

      • Run ./scripts/sync-from-usns.py again with the -u option if visual inspection of updates looks correct.

  11. (This step is normally automated now.) 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 and any packages with a new source orig.tar.gz will need to be manually copied to -updates by an archive admin.

    • IMPORTANT: the copier verifies that the new changelog in -security is a direct descendant of what is in -updates if the package currently exists in -updates. This helps ensure that a change in -updates is not reverted by a -security update. If this verification step fails, the package will not be automatically copied and a security team member must verify the changes are ok, and ask an archive admin to copy it manually.

  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.

Republishing/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. Create a new USN page for this by navigating to http://www.ubuntu.com/usn/update/usn-###-#. Via the command line: w3m -dump http://www.ubuntu.com/usn/update/usn-$USN. This should return an 'Ok' message (eg, 'Loading USN-1110-1: Ok'). If this returns 'No such USN: usn-xxx', wait a couple of minutes and try again.

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"

  3. ask a LOSA to remove the USN from the usn microsite

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

SecurityTeam/UpdatePublication (last edited 2024-03-19 04:05:32 by alexmurray)