SponsorsQueue

Revision 3 as of 2009-12-11 17:10:16

Clear message

Purpose

The Security Sponsors Queue is used by the ubuntu-security-sponsors team to coordinate sponsored security uploads to an Ubuntu stable release. This queue is for all packages in Ubuntu, but specific to the security pocket of Ubuntu.

Please remember that security fixes should follow the procedure outlined in the Security Update Procedure.

Notes for Contributors

Before subscribing ubuntu-security-sponsors to a bug, please check the following:

  1. Your patch is in debdiff format (for merges and bug fixes) or a diff.gz file(for new upstream revisions).

  2. The patch follows the security team update procedures. Especially:

    • its targeted against the security pocket of a stable release
    • uses the correct version
    • Check your .changes file to make sure that you have the right revision and distribution

  3. All changes in the patch are intentional
    • Review the patch manually. If there are unexpected changes, consider removing them from the patch, either using filterdiff or manually. If you are uncertain, seek advice from #ubuntu-motu, #ubuntu-security or your Mentor

  4. Your patch applies cleanly
    • Test your patch by downloading and unpacking the target source, and running patch -p1 < ../patchname.debdiff in the package directory. There should be no errors.

  5. The Status and Assignment are correct
    • The Status should be "New" for sync requests
    • The Status should be "Confirmed" when you have uploaded a debdiff
    • The Assignment should be "Unassigned"
  6. The sponsors will use the status and assignment fields in their communications with you and other groups
    • Please check status and assignment before subscribing again a bug which required some actions (either from you or somebody else)

Note for Sponsors

Once you have selected a bug, please use the following guidelines for disposition.

Bugs in officially supported packages (main/restricted)

  • If unset, set the importance (if unsure, leave blank)
  • If not present, add the "patch" tag
  • Unassign the bug and set Status to "Confirmed"
  • Add a comment including the following:
    • That ubuntu-security-sponsors has been unsubscribed.
    • That the package is in main or restricted
    • That ubuntu-security has been subscribed to process the request
  • Subscribe ubuntu-security
  • Unsubscribe ubuntu-security-sponsors

Sync request bugs

  • If unset, set the importance (if unsure, leave blank)
  • If not present, add the "sync" tag
  • If the sync is acceptable
    • Set the Status to "Confirmed"
    • Unassign the bug
    • Add a comment "sync request ACK'd"
    • Subscribe ubuntu-security
    • Unsubscribe ubuntu-security-sponsors
  • If the sync is not acceptable
    • Assign the submitter and set the Status to "Invalid"
    • Add a comment explaining why the sync is not acceptable

Bugs with debdiffs

  • If unset, set the importance (if unsure, leave blank)
  • If the debdiff is good
    • Set the Status to "Confirmed"
    • Unassign the bug
    • Add a comment "sync request ACK'd"
    • Subscribe ubuntu-security
    • Unsubscribe ubuntu-security-sponsors
  • If the debdiff looks sane, but you are unsure about uploading
    • Set the Status to "Confirmed"
    • Unassign the bug
    • Add a security-verification tag
    • Subscribe ubuntu-security
    • Unsubscribe ubuntu-security-sponsors
  • If additional changes to the source are planned (soon)
    • Add comment that you are working on additional changes
    • When complete, upload as usual
  • If the patch needs work
    • Set the Status to "Incomplete"
    • Assign the patch submitter
    • Unsubscribe ubuntu-security-sponsors
    • Add a comment including the following:
      • That ubuntu-security-sponsors has been unsubscribed
      • The specific work that must be done for the patch to be acceptable
      • That the contributor should resubscribe ubuntu-security-sponsors when the changes are complete

Bugs without debdiffs

  • If there is a patch, and no patch tag, add the patch tag
  • Assign "Nobody" and Set status "Confirmed"
  • If unset, set the importance (if unsure, leave blank)
  • Unsubscribe ubuntu-security-sponsors
  • Add a comment including the following:
    • That ubuntu-security-sponsors has been unsubscribed
    • (optional) any notes from reviewing the patch
    • That a debdiff patch should be created prior to resubscribing ubuntu-security-sponsors

N.B.: normal bug triage rules still apply. Inappropriate bugs should be invalidated. Already fixed bugs should be updated as Released with the release version, etc.

Notes for Uploaders

The ubuntu-security is required to upload packages to the security pocket. The team will review:

DRAFT: Syncs

For community-supported packages, the security team can perform a fake sync from the Debian security archive if the version in Ubuntu is the same as the base version in Debian. Eg, if package foo in Ubuntu 8.04 LTS is at version 1.0-2, package foo in Debian Lenny also has version 1.0-2, and the DSA for Debian uses 1.0-2+lenny1, this package is suitable for syncing into Ubuntu using a fake sync. Basically, this is a no change rebuild using the version <Debian DSA version>build0.<ubuntu release version>.1. Eg, for the above package, the new version in Ubuntu is 1.0-2+lenny1build0.8.04.1. To ensure smooth upgrades from one Ubuntu release to another, you must be careful about versioning. Use the fake-security-sync tool from the Ubuntu security-tools bzr branch, which will help automate the process and perform various checks. Before publishing, be sure to:

  • verify the version is correct
  • verify the build went ok
  • sanity check the debdiff in Launchpad

Community Uploads

  • Upload the resulting package. Since you're not the top person listed in the changelog, you will need to use the -k switch when running dpkg-buildpackage.
  • Update the status to "Fix Committed"
  • Add comment that the fix has been uploaded.
  • Once the package is finished building, publish using SecurityTeam/UpdatePublication

  • If the bug has the tag security-verification, upload to ubuntu-security-proposed PPA and get an archive admin to pocket copy it to -proposed after it is finished building

  • remove the security-verification tag
  • add the verification-needed tag
  • Update the status to "Fix Committed"
  • Add comment that the fix has been uploaded.

Verification

The ubuntu-security-sponsors team will use the same process as detailed in StableReleaseUpdates.

Testing

  1. Properly test that the package builds and still works. You can refer to QA Regression Testing for scripts and techniques on testing packages.

  2. Testing might include (but is not limited to) build tests, test suites, Proof of Concepts (PoC), ABI changes, and testing the patched code so that it introduces no regressions.
  3. If possible, use publicly available exploits and test cases to verify that the bug is fixed
  4. In all cases, verify that the package still functions properly