Security uploads should have urgency=high

[developers-reference.git] / developers-reference.sgml

diff --git a/developers-reference.sgml b/developers-reference.sgml
index bfb68797c8d9790985ec2c0bc7ed089d807f366a..dfa6aef60b46a5e0b55e386d7ea5e4106fb760b1 100644 (file)
--- a/developers-reference.sgml
+++ b/developers-reference.sgml
@@ -6,7 +6,7 @@
   <!ENTITY % commondata  SYSTEM "common.ent" > %commondata;
 
   <!-- CVS revision of this document -->
-  <!ENTITY cvs-rev "$Revision: 1.222 $">
+  <!ENTITY cvs-rev "$Revision: 1.225 $">
 
   <!-- if you are translating this document, please notate the CVS
        revision of the original developer's reference in cvs-en-rev -->
@@ -745,7 +745,7 @@ for installing the Debian distribution on a specific architecture
 (<file>disks-i386</file>, <file>disks-m68k</file>, etc.).
 
 
-      <sect1>Sections
+      <sect1 id="archive-sections">Sections
        <p>
 The <em>main</em> section of the Debian archive is what makes up the
 <strong>official &debian-formal; distribution</strong>.  The
@@ -1918,7 +1918,7 @@ will receive a separate email notifying you of that.  Read on below.
 Note also that if you upload via queues, the queue daemon software will
 also send you a notification by email.
 
-    <sect id="override-file">Determining section and priority of a package
+    <sect id="override-file">Specifying the package section, subsection and priority
        <p>
 The <file>debian/control</file> file's <tt>Section</tt> and
 <tt>Priority</tt> fields do not actually specify where the file will
@@ -1947,9 +1947,11 @@ For more information about <em>override files</em>, see <manref
 name="dpkg-scanpackages" section="8"> and
 <url id="&url-bts-devel;#maintincorrect">.
        <p>
-Note also that the term "section" is used for the separation of packages
-according to their licensing, e.g. <em>main</em>, <em>contrib</em> and
-<em>non-free</em>. This is described in another section, <ref id="archive">.
+Note that the <tt>Section</tt> field describes both the section as
+well as the subsection, which are described in <ref
+id="archive-sections">.  If the section is "main", it should be
+omitted.  The list of allowable subsections can be found in <url
+id="&url-debian-policy;ch-archive.html#s-subsections">.
 
 
     <sect id="bug-handling">Handling bugs
@@ -2315,21 +2317,32 @@ 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.
 <p>
+Do <strong>NOT</strong> 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.
+<p>
 Review and test your changes as much as possible.  Check the
 differences from the previous version repeatedly
 (<prgn>interdiff</prgn> from the <package>patchutils</package> package
 and <prgn>debdiff</prgn> from <package>devscripts</package> are useful
 tools for this, see <ref id="debdiff">).
 <p>
-When packaging the fix, keep the following points in mind:
+Be sure to verify the following items:
 
 <list>
-    <item>Make sure you target the right distribution in your
+    <item>Target the right distribution in your
     <file>debian/changelog</file>. For stable this is <tt>stable-security</tt> and for
     testing this is <tt>testing-security</tt>, and for the previous
     stable release, this is <tt>oldstable-security</tt>. Do not target
     <var>distribution</var>-proposed-updates or <tt>stable</tt>!
 
+    <item>The upload should have urgency=high.
+
     <item>Make descriptive, meaningful changelog entries.  Others will
     rely on them to determine whether a particular bug was fixed.
     Always include an external reference, preferably a CVE
@@ -2356,17 +2369,18 @@ When packaging the fix, keep the following points in mind:
     not build those. This point applies to normal package uploads as
     well.
 
-    <item>If the upstream source has been uploaded to
+    <item>Unless the upstream source has been uploaded to
     security.debian.org before (by a previous security update), build
-    the upload without the upstream source (<tt>dpkg-buildpackage
-    -sd</tt>).  Otherwise, build with full source
-    (<tt>dpkg-buildpackage -sa</tt>).
+    the upload with full upstream source (<tt>dpkg-buildpackage
+    -sa</tt>).  If there has been a previous upload to
+    security.debian.org with the same upstream version, you may upload
+    without upstream source (<tt>dpkg-buildpackage -sd</tt>).
 
     <item>Be sure to use the exact same <file>*.orig.tar.gz</file> as used in the
     normal archive, otherwise it is not possible to move the security
     fix into the main archives later.
 
-    <item>Be sure to build the package on a clean
+    <item>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 <ref id="server-machines">)