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

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:

    • targeted against the security pocket of a stable release
    • uses the correct version
    • mentions a CVE, and preferably a LP bug #.
    • 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-hardened 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)
  7. Please comment on the testing performed.

  8. If all of the above is in order, please subscribe ubuntu-security-sponsors

Notes for Sponsors

Once you have selected a bug, please use the following guidelines for disposition. This process is very similar to the existing MOTU/Sponsorship/SponsorsQueue process, and differs mainly in that ubuntu-security-sponsors remain subscribed to the bug in most situations.

Bug lists for ubuntu-security-sponsors:

All bugs

  • If it is a security bug:
    • If unset, set the importance (if unsure, leave blank)
    • Subscribe ubuntu-security
  • If it is not a security bug:
    • Unsubscribe ubuntu-security
    • Add a comment explaining why this is not a security bug, and any steps needed to get the bug processed by another team

Sync request bugs

Fake sync requests can be performed when a Debian security update has the same base version as the Ubuntu version (ie, no merge is required). See below for details.

  • 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"
  • 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 the debdiff is good
    • Set the Status to "Confirmed"
    • Unassign the bug
    • Add a comment "ACK'd"
  • If the debdiff looks sane, but you are unsure about uploading
    • Set the Status to "Confirmed"
    • Unassign the bug
    • Add a comment "ACK'd"
    • Add a security-verification tag
  • 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"
    • Add the tag "patch-needswork"
    • Assign the patch submitter
    • Unsubscribe ubuntu-security-sponsors (unless you are processing other releases within the same bug)
    • 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 and set the status to 'NEW' 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"
  • 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 team is required to upload packages to the security pocket. The team will process uploads for bugs in these lists:

Once it has been published, please update the Ubuntu CVE Tracker with details on what was fixed (and set any bugs related to the upload to "Fix Released" if the changelog did not include a bug reference number).


For community-supported packages, it's possible to perfrom 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.

  • If the bug is ACK'd and has a sync tag, use the fake-security-sync tool from the Ubuntu security-tools git repo. This will guide you through the process of creating the new package and uploading to the Security PPA. Before uploading, verify the version is correct. Once uploaded:


If the package is officially supported, it must be reviewed and tested by a member of ubuntu-security.

If the package is community supported and the bug is ACK'd:

  • Create a source package using the supplied debdiff
  • 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 package is community supported, the bug is ACK'd and has the tag security-verification:

  • Create a source package using the supplied debdiff
  • Upload to ubuntu-security-proposed PPA
  • Update the status to 'In Progress'
  • Add comment that the fix has been uploaded to the ubuntu-security-proposed PPA
  • When the package finishes building in the ubuntu-security-proposed PPA, get an archive admin to pocket copy it to -proposed (being careful to adjust the overrides as needed)
  • Remove the security-verification tag
  • Add the verification-needed tag
  • Update the status to "Fix Committed"
  • Add comment that the fix has been pocket copied to -proposed: "Pocket copied <source package> to proposed. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Thank you in advance!"

  • Subscribe ubuntu-sru to the bug

  • Subscribe sru-verification to the bug

  • Add a comment letting ubuntu-sru know to copy to the security pocket as well: "To ubuntu-sru: if this passes the verification process, please also pocket copy to security. Thanks!"


For packages that were built in the ubuntu-security-proposed ppa and went to -proposed for more testing, the ubuntu-sru team will follow the process as detailed in StableReleaseUpdates. Once marked as verification-done, they can by copied to the -security and -updates pockets.

Bug lists:

CategoryProcess CategorySecurityTeam

SecurityTeam/SponsorsQueue (last edited 2022-01-05 12:22:11 by rodrigo-zaiden)