Differences between revisions 14 and 15
Revision 14 as of 2012-01-04 02:55:21
Size: 3918
Comment: mention some version issues and would-break.sh
Revision 15 as of 2013-05-29 10:25:37
Size: 3888
Editor: ?HenriSalo
Comment: Mailing list vendor-sec is no longer used. Please see http://oss-security.openwall.org/wiki/mailing-lists/vendor-sec
Deletions are marked like this. Additions are marked like this.
Line 22: Line 22:
There are two major things to test -- first, that the fix you've applied completely addresses the vulnerability (i.e. the exploit no longer works), and that you haven't introduced regressions. Non-hostile sample exploits may already be available (via vendor-sec or elsewhere), or in some cases (XSS attacks, e.g.) the attack is easy to reproduce. There are two major things to test -- first, that the fix you've applied completely addresses the vulnerability (i.e. the exploit no longer works), and that you haven't introduced regressions. Non-hostile sample exploits may already be available, or in some cases (XSS attacks, e.g.) the attack is easy to reproduce.

This is about the details of security update package preparation. See DebianSecurity/AdvisoryCreation/DebDev for the business of actually fixing the code.

Preparing fixed packages

Patch the package. Use whatever patching scheme the package you're working on already used. If the maintainer didn't apply any patches apart from the debian/ subdir, just use the native package diff without adding any patch support to the build. If it used dpatch, cdbs, quilt, etc., stick with that.

Depending on how far from the upstream release the Debian release is, you may have to either rework the security fix, broaden it to cover more cases, or come up with an alternate approach. In most cases, the upstream fix (assuming there is one) will apply more or less cleanly.

Create a new package version based on the original version-release, appending ".1+release1 for the first security patch in that distribution, .1+release2 for the second, and so forth -- for example, from 1.23-4 when making a fix to etch, use 1.23-4.1+etch1. If a previous NMU had used 1.23-4.1, increment the NMU to .2, and so forth.

This criteria for versioning is not always followed in stable fixes. In some cases, the developer just use "1+release1" with out the dot or even "release1". Please keep the criteria used (incrementing the last figure) if its not the first upload.

Make sure the version you chose has never been used before. Even if the version was at some point in sid but gone now, you must not use it. Pay especial attention to this when the version is +nmuX.

The first upload (and only the first upload) of any given fixed package to the security build system should include the upstream source (e.g. dpkg-buildpackage -sa or pdebuild --debbuildopts -sa). Use (r)madison or elmo to find out whether the source is already in the security build archive. As of the time of writing (647708) rmadison doesn't cover oldstable, make sure you check somewhere else if the package exists there and needs to be fixed.

Do your build in the distro you intend to fix (stable pbuilder or similar); be wary of introducing unintended dependency changes. You can easily check if a given set of packages would cause a breakage with 'would-break'. You can get it from git.debian.org (and its man page). Don't mix .changes files of different architectures, it won't work.

Testing fixed packages

There are two major things to test -- first, that the fix you've applied completely addresses the vulnerability (i.e. the exploit no longer works), and that you haven't introduced regressions. Non-hostile sample exploits may already be available, or in some cases (XSS attacks, e.g.) the attack is easy to reproduce.

no-dsa as a stable proposed update

If the issue doesn't worth a DSA Advisory (please, check this with the security-team) you should prepare an upload for stable-proposed-updates. You should send an email to debian-release@lists.d.o with the debdiff and ask for upload permissions. Read more about uploads to the stable and oldstable distributions at Developer's Reference, 5.5.1.

If the tracker doesn't reflect this situation (that the fix will be via spu), you should add in data/CVE/list something like the following lines:

CVE-2010-XXXX [Insufficient stripping of CR/LF allows arbitrary IRC command execution]
        - libpoe-component-irc-perl 6.32+dfsg-1
        [lenny] - libpoe-component-irc-perl <no-dsa> (#581194)

and in data/spu-candidates.txt

libpoe-component-irc-perl (CVE if known)
#581194
note about situation