From 14f5c5a7d104199df70ed7ca5e59f2a073276534 Mon Sep 17 00:00:00 2001 From: mdz Date: Mon, 20 Oct 2003 01:09:41 +0000 Subject: [PATCH] - More explicit instructions about what is appropriate for a security upload git-svn-id: svn://anonscm.debian.org/ddp/manuals/trunk/developers-reference@2458 313b444b-1b9f-4f58-a734-7bb04f332e8d --- debian/changelog | 2 ++ developers-reference.sgml | 26 ++++++++++++++++++-------- 2 files changed, 20 insertions(+), 8 deletions(-) diff --git a/debian/changelog b/debian/changelog index ea0551f..d81243f 100644 --- a/debian/changelog +++ b/debian/changelog @@ -12,6 +12,8 @@ developers-reference (3.3.4) WORKING VERSION; urgency=low - Don't upload security updates directly to stable - Always include an external reference in security changelog entries - Be careful not to re-use a version number in security uploads + - More explicit instructions about what is appropriate for a security + upload -- Adam Di Carlo Mon, 16 Jun 2003 04:22:22 -0400 diff --git a/developers-reference.sgml b/developers-reference.sgml index bfb6879..ad13458 100644 --- a/developers-reference.sgml +++ b/developers-reference.sgml @@ -6,7 +6,7 @@ %commondata; - + @@ -2315,16 +2315,25 @@ indeed succeeds on the unpatched package and fails on the fixed package. Test other, normal actions as well, as sometimes a security fix can break seemingly unrelated features in subtle ways.

+Do NOT include any changes in your package which are +not directly related to fixing the vulnerability. These will only +need to be reverted, and this wastes time. If there are other bugs in +your package that you would like to fix, make an upload to +proposed-updates in the usual way, after the security advisory is +issued. The security update mechanism is not a means for introducing +changes to your package which would otherwise be rejected from the +stable release, so please do not attempt to do this. +

Review and test your changes as much as possible. Check the differences from the previous version repeatedly (interdiff from the patchutils package and debdiff from devscripts are useful tools for this, see ).

-When packaging the fix, keep the following points in mind: +Be sure to verify the following items: - Make sure you target the right distribution in your + Target the right distribution in your debian/changelog. For stable this is stable-security and for testing this is testing-security, and for the previous stable release, this is oldstable-security. Do not target @@ -2356,17 +2365,18 @@ When packaging the fix, keep the following points in mind: not build those. This point applies to normal package uploads as well. - If the upstream source has been uploaded to + Unless the upstream source has been uploaded to security.debian.org before (by a previous security update), build - the upload without the upstream source (dpkg-buildpackage - -sd). Otherwise, build with full source - (dpkg-buildpackage -sa). + the upload with full upstream source (dpkg-buildpackage + -sa). If there has been a previous upload to + security.debian.org with the same upstream version, you may upload + without upstream source (dpkg-buildpackage -sd). Be sure to use the exact same *.orig.tar.gz as used in the normal archive, otherwise it is not possible to move the security fix into the main archives later. - Be sure to build the package on a clean + Build the package on a clean system which only has packages installed from the distribution you are building for. If you do not have such a system yourself, you can use a debian.org machine (see ) -- 2.30.2