Update security instructions to specify that uploads should not be made

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

diff --git a/developers-reference.sgml b/developers-reference.sgml
index 79a60492c16be7e96d672822c15bbfe7108037ea..b90515e765084b49616f19312f59eb4fc395fba8 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.125 $">
+  <!entity cvs-rev "$Revision: 1.126 $">
   <!-- if you are translating this document, please notate the CVS
        revision of the developers reference here -->
   <!--
@@ -2599,6 +2599,7 @@ maintainers with security problems or fix them themselves, sending
 security advisories, and maintaining security.debian.org.
 
 <!-- information about the security database goes here once it's ready -->
+<!-- (mdz) -->
 
         <sect2 id="bug-security-you">What to do when you learn of a
         security problem
@@ -2744,10 +2745,12 @@ When packaging the fix, keep the following points in mind:
     new version to unstable first.
 
     <item>Do not make source-only uploads if your package has any
-    binary-all packages. The buildd infrastructure will not build
-    those. This point applies to normal package uploads as well.
+    binary-all packages (do not use the <tt>-S</tt> option to
+    <prgn>dpkg-buildpackage</prgn>).  The buildd infrastructure will
+    not build those. This point applies to normal package uploads as
+    well.
 
-    <item>Always upload with full source (use the <tt>-sa</tt> option
+    <item>Always build with full source (use the <tt>-sa</tt> option
     for <prgn>dpkg-buildpackage</prgn>).
 
     <item>Be sure to use the exact same .orig.tar.gz as used in the
@@ -2759,28 +2762,34 @@ When packaging the fix, keep the following points in mind:
     are building for. If you do not have such a system yourself, you
     can use a debian.org machine (see <ref id="server-machines">)
     or setup a chroot (see <ref id="pbuilder"> and
-    <ref if="debootstrap">).
+    <ref id="debootstrap">).
 </list>
 
       <sect2 id="bug-security-upload">Uploading the fixed package
-      <p>
-Once you have created and tested the new package, it needs to be
-uploaded so it can be installed in the archives. For security uploads,
-the place to upload to is
+<p>
+<em>DO NOT</em> upload a package to the security upload queue without
+prior authorization from the security team.  If the package does not
+exactly meet the team's requirements, it will cause many problems and
+delays in dealing with the unwanted upload.
+<p>
+Once you have created and tested the new package, and it has been
+approved by the security team, it needs to be uploaded so that it can
+be installed in the archives. For security uploads, the place to
+upload to is
 <tt>ftp://security.debian.org/pub/SecurityUploadQueue/</tt> .
 
 <p>
-Once an upload to the security queue has been accepted the package
+Once an upload to the security queue has been accepted, the package
 will automatically be rebuilt for all architectures and stored for
 verification by the security team.
 
 <p>
-Uploads waiting for acceptance or verification are only accessible by
-the security team. This is necessary since there might be fixes for
-security problems that can not be disclosed yet.
+Uploads which are waiting for acceptance or verification are only
+accessible by the security team. This is necessary since there might
+be fixes for security problems that cannot be disclosed yet.
 
 <p>
-If a member of the security team accepts a package it will be
+If a member of the security team accepts a package, it will be
 installed on security.debian.org as well as the proper
 <em>distribution</em>-proposed-updates on ftp-master or in the non-US
 archive.