X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=pkgs.dbk;h=e9b058a3e2486f6fa535671aedb3705c08bfad3c;hb=bf6cd05f412306b608fe64f00cb382e956a92184;hp=2fb760965e038b2cdeb3ef18b0821d700c78ea96;hpb=430f868ef5cabbf6539d3051966de888d14277be;p=developers-reference.git
diff --git a/pkgs.dbk b/pkgs.dbk
index 2fb7609..e9b058a 100644
--- a/pkgs.dbk
+++ b/pkgs.dbk
@@ -401,29 +401,28 @@ the Debian package .
Delayed uploads
+
-Delayed uploads are done for the moment via the delayed queue at gluck
-. The upload-directory is
-gluck:~tfheen/DELAYED/[012345678]-day. 0-day is uploaded
-multiple times per day to &ftp-master-host;.
-
-
-With a fairly recent dput, this section
+It is sometimes useful to upload a package immediately, but to want this
+package to arrive in the archive only a few days later. For example,
+when preparing a Non-maintainer Upload,
+you might want to give the maintainer a few days to react.
-
-[tfheen_delayed]
-method = scp
-fqdn = gluck.debian.org
-incoming = ~tfheen
-
+
-in ~/.dput.cf should work fine for uploading to the
-DELAYED queue.
+An upload to the delayed directory keeps the package in
+
+the deferred uploads queue".
+When the specified waiting time is over, the package is moved into
+the regular incoming directory for processing.
+This is done through automatic uploading to
+&ftp-master-host; in upload-directory
+DELAYED/[012345678]-day. 0-day is uploaded
+multiple times per day to &ftp-master-host;.
-Note: Since this upload queue goes to
-&ftp-master-host;, the prescription found in applies here as well.
+With dput, you can use the --delayed DELAY
+parameter to put the package into one of the queues.
@@ -828,15 +827,13 @@ outstanding security problems, helping maintainers with security problems or
fixing them themselves, sending security advisories, and maintaining
security.debian.org.
-
-
When you become aware of a security-related bug in a Debian package, whether or
not you are the maintainer, collect pertinent information about the problem,
and promptly contact the security team at
&email-security-team; as soon as possible. DO NOT UPLOAD any packages for stable;
- the security team will do that. Useful information includes, for example:
+role="strong">DO NOT UPLOAD any packages for stable
+without contacting the team. Useful information includes, for example:
@@ -871,6 +868,29 @@ linkend="bug-security-advisories"/> )
+As the maintainer of the package, you have the responsibility to
+maintain it, even in the stable release. You are in the best position
+to evaluate patches and test updated packages, so please see the sections
+below on how to prepare packages for the Security Team to handle.
+
+
+The Security Tracker
+
+The security team maintains a central database, the
+Debian Security Tracker.
+This contains all public information that is known about security issues:
+which packages and versions are affected or fixed, and thus whether stable,
+testing and/or unstable are vulnerable. Information that is still confidential
+is not added to the tracker.
+
+
+You can search it for a specific issue, but also on package name. Look
+for your package to see which issues are still open. If you can, please provide
+more information about those issues, or help to address them in your package.
+Instructions are on the tracker web pages.
+
+
+
Confidentiality
@@ -940,6 +960,10 @@ There are two reasons for releasing information even though secrecy is
requested: the problem has been known for a while, or the problem or exploit
has become public.
+
+The Security Team has a PGP-key to enable encrypted communication about
+sensitive issues. See the Security Team FAQ for details.
+
@@ -1076,7 +1100,8 @@ Be sure to verify the following items:
-Target the right distribution in your debian/changelog.
+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
@@ -1086,67 +1111,58 @@ stable release, this is oldstable-security. Do not target
-The upload should have urgency=high.
+The upload should have urgency=high.
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 identifier, so that it can be cross-referenced.
-Include the same information in the changelog for unstable,
-so that it is clear
-that the same bug was fixed, as this is very helpful when verifying that the
-bug is fixed in the next stable release. If a CVE identifier has not yet been
-assigned, the security team will request one so that it can be included in the
-package and in the advisory.
+determine whether a particular bug was fixed. Add closes:
+statements for any Debian bugs filed.
+Always include an external reference, preferably a CVE
+identifier, so that it can be cross-referenced. However, if a CVE
+identifier has not yet been assigned, do not wait for it but continue the
+process. The identifier can be cross-referenced later.
-Make sure the version number is proper. It must be greater than the current
-package, but less than package versions in later distributions. If in doubt,
-test it with dpkg --compare-versions. Be careful not to
-re-use a version number that you have already used for a previous upload. For
-testing, there must be a higher version in
-unstable. If there is none yet (for example, if
-testing and unstable have the same
-version) you must upload a new version to unstable first.
-
-
-
-
-Do not make source-only uploads if your package has any binary-all packages (do
-not use the -S option to
-dpkg-buildpackage). The buildd
-infrastructure will not build those. This point applies to normal package
-uploads as well.
+Make sure the version number is proper.
+It must be greater than the current package, but less than package versions in
+later distributions. If in doubt, test it with dpkg
+--compare-versions. Be careful not to re-use a version number that
+you have already used for a previous upload, or one that conflicts with a
+binNMU. The convention is to append
++codename1, e.g.
+1:2.4.3-4+etch1, of course increasing 1 for any subsequent
+uploads.
Unless the upstream source has been uploaded to security.debian.org
- before (by a previous security update), build 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).
+ before (by a previous security update), build 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
+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.
-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 ) or
-setup a chroot (see and ).
+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
+ ) or setup a chroot (see
+ and ).
@@ -1179,7 +1195,7 @@ archives. For security uploads, the place to upload to is
Once an upload to the security queue has been accepted, the package will
-automatically be rebuilt for all architectures and stored for verification by
+automatically be built for all architectures and stored for verification by
the security team.