Differences between revisions 77 and 78
Revision 77 as of 2015-02-24 12:54:22
Size: 8359
Comment: Harmonize titles
Revision 78 as of 2015-03-11 10:32:01
Size: 9545
Editor: ?MikeGabriel
Comment:
Deletions are marked like this. Additions are marked like this.
Line 83: Line 83:
== Prepare regression updates for squeeze-lts ==

If an upload to squeeze-lts introduces a regression, this regression needs to be fixed as soon as possible.

=== Steps for a regression update ===

 1. Fix the package.
 1. Do a test build and test installation. Verify the regression issue and also the original issue are really resolved now.
 1. Upload the fixed package to squeeze-lts.
 1. Use {{{gen-DLA}}} script to add a DLA entry to {{{data/DLA/list}}} and to provide you with an announcement email template:{{{
$ bin/gen-DLA --save $SOURCEPACKAGENAME regression
}}}
 1. Commit the updated {{{data/DLA/list}}} to the secure-testing SVN repository.
 1. Wait for the uploaded package to arrive in the squeeze-lts repository.
 1. In the base folder of the secure-testing SVN repository, you can find an auto-generated LTS announcement template file with name DLA-$DLA-{2,3,4...}. Use this file as the template for your regression fix announcement. Don't commit this file to SVN(!). Copy+paste the announcement template to your email application, complete/edit it manually and finally send the regression fix DLA email to debian-lts-announcements@lists.debian.org.

Translation(s): English - Русский

Contributing to Debian Long Term Support

If you want to get involved in the LTS team and help keep Debian packages secure for 5 years, have a look at this page. We're assuming that you are familiar with the repository layout described in LTS/Using and that you are subscribed to the mailing list: http://lists.debian.org/debian-lts/

You can help in many ways:

Test updated packages and report regressions

As a simple user, you can test packages that have been updated (or that are in the process of being updated). If you find a regression (i.e. something that used to work and that no longer works), then please report it to debian-lts@lists.debian.org and put the person who prepared the update in copy (in case they are not subscribed to the list).

Many LTS contributors are looking for testers of their updated packages. They send call for tests on the mailing list, so please subscribe to it and test the packages they provide when you can, and report back whether they worked for you.

Prepare security updates for squeeze-lts

Claim the issue in dla-needed.txt

In order to prevent duplication of effort, make sure the issue is listed in data/dla-needed.txt and add your name to it.

$ svn co svn+ssh://svn.debian.org/svn/secure-testing
$ cd secure-testing
$ editor data/dla-needed.txt
$ svn commit -m "Claim foo in dla-needed.txt"

Write access to the secure-testing repository

Debian Developers automatically have commit access to the secure-testing repository. Otherwise you need to be a member of the secure-testing alioth project, please request membership trough the Alioth project page or through the debian-lts mailinglist.

Build the update

Backport the fix to the version in squeeze or squeeze-lts (in case there's already been an earlier update). You need to set the target distribution in debian/changelog to "squeeze-lts". The versioning follows the conventions already used in security.debian.org. Historically codenames have been used as version numbers, but this was changed some time ago as version numbers are more deterministic.

  • If a package already e.g. had a +squeeze1 update, use +squeeze2 for the next update.
  • If a package hasn't seen an update, use +deb6u1 for the next update.
  • for the rare cases where new upstream versions are introduced, make sure to use a lower version than in wheezy. The safe bet is ~deb6u1. Just don't use +squeezeX as this will cause problems!

Now build the package and run your tests. You can generate a debdiff and post it to debian-lts@lists.debian.org for review. You can also make a test package available for users to test.

Now test the fixed package. If you're satisfied, upload to ftp-master. Once uploaded the package will be auto-built for amd64 or i386 (if it's an arch:any package).

Note: If you use dput-ng, you need to apply the patch from 745806. After that "dput CHANGES file" is sufficient.

Claim an DLA ID in DLA/list

Run bin/gen-DLA in the top directory of the SVN repository. It automatically generates an entry in data/DLA/list to ensure that no IDs are used twice. The following command would add an entry for src:hello fixing CVE-2014-0666 and creates an advisory template for you:

$ bin/gen-DLA --save hello CVE-2014-0666

After that commit your changed version of data/DLA/list

Announce the update

Now that the update has been released, send a mail to the debian-lts-announce mailing list. The mail needs to be signed by a PGP key in the debian.org or debian-maintainers keyring. Both PGP/MIME and inline signatures should be fine (unless you are using Enigmail, which breaks PGP/MIME).

The advisory template has been created by bin/gen-DLA (see before) and generally looks like this:

Subject: [DLA $DLA-1] $SOURCEPACKAGENAME security update

Package        : $SOURCEPACKAGENAME
Version        : $squeeze_VERSION
CVE ID         : CVE-2014-0001 CVE-2014-0002
Debian Bug     : 12345

DLA text goes here
[...]

If you use mutt, a simple way to send it is to use mutt -H DLA-123.

Prepare regression updates for squeeze-lts

If an upload to squeeze-lts introduces a regression, this regression needs to be fixed as soon as possible.

Steps for a regression update

  1. Fix the package.
  2. Do a test build and test installation. Verify the regression issue and also the original issue are really resolved now.
  3. Upload the fixed package to squeeze-lts.
  4. Use gen-DLA script to add a DLA entry to data/DLA/list and to provide you with an announcement email template:

    $ bin/gen-DLA  --save $SOURCEPACKAGENAME regression
  5. Commit the updated data/DLA/list to the secure-testing SVN repository.

  6. Wait for the uploaded package to arrive in the squeeze-lts repository.
  7. In the base folder of the secure-testing SVN repository, you can find an auto-generated LTS announcement template file with name DLA-$DLA-{2,3,4...}. Use this file as the template for your regression fix announcement. Don't commit this file to SVN(!). Copy+paste the announcement template to your email application, complete/edit it manually and finally send the regression fix DLA email to debian-lts-announcements@lists.debian.org.

Triage new security issues

The security team and the LTS team cooperate to process the flow of new security issues that are reported. Since each security issue is assigned a CVE number, we often call this "CVE triage".

If you want to help with this, you must first get familiar with the security tracker. It's the infrastructure we use to track how security issues are affecting Debian packages. Please read carefully this page: http://security-team.debian.org/security_tracker.html

You will need write access to the secure-testing repository.

CVE triaging in the LTS release

Now let's go into detail for the work concerning LTS in particular. We start from the page listing all issues in the LTS release. Currently it's this one: https://security-tracker.debian.org/tracker/status/release/oldstable (NOTE: will break once squeeze is no longer oldstable...)

For each CVE/package listed on this page, there are only 2 desirable outcomes:

  • the package is added to dla-needed.txt so that someone else will have to prepare an updated package and close the security issue(s)
  • the CVE is ignored for some reason:
    • we tag it "no-dsa" because it's a minor security issue and not worth an update
    • we tag it "not-affected" because the version in the LTS release is not affected (usually because the vulnerable code is not present in the version)
    • we tag it "end-of-life" because the package is not supported in the LTS release (the list of unsupported package for Squeeze is currently available here: http://anonscm.debian.org/cgit/collab-maint/debian-security-support.git/tree/security-support-ended.deb6)

    • we tag it as fixed in a specific version (assuming that the version in the LTS release is higher or equal, it will be automatically assumed to be fixed too)
    • the severity is set to "unimportant" (that should be seldom used and is generally done by the security team anyway)

Guidelines for CVE triaging

Now the tricky part. How do you decide whether an issue should be added to dla-needed.txt or if it should be tagged in some other way? There's no perfect answer, you should use your best judgment after having carefully analyzed the issue, the risks involved, etc.

That said the security team is taking similar decisions all the time and we usually follow their decisions. If the security team has added a vulnerable package to "data/dsa-needed.txt", you can usually safely add it to "data/dla-needed.txt". If the security team has tagged the issue "no-dsa" with "Minor issue" description, you can safely do the same. Note that when the reason is "Maintainer will update via stable-proposed-updates" blindly following is not always the best idea...

Contact the maintainer

Whenever you take a decision for a new issue (that is real and affecting the LTS release), you should inform the corresponding package maintainers to offer him a chance to help us. We use the bin/contact-maintainers script in the secure-testing repo to this end.

When we add a package to dla-needed.txt, you can use it this way for example:

$ bin/contact-maintainers --lts sudo CVE-2014-9680 CVE-2014-0106

We we tag issues as "no-dsa", and don't plan to take care of the updates by ourselves, then we use it in this way:

$ bin/contact-maintainers --lts --no-dsa sudo CVE-2014-9680 CVE-2014-0106

Note that the list of CVE is optional and that this script assumes that you use mutt to send mails. If not, you should consider using the --mailer option to use something else (see bin/contact-maintainer --help for details). You must customize the mail sent (at least to drop the list of uploaders and possibly to adjust the recipients list).


CategoryLts