<!entity % commondata SYSTEM "common.ent" > %commondata;
<!-- CVS revision of this document -->
- <!entity cvs-rev "$Revision: 1.120 $">
+ <!entity cvs-rev "$Revision: 1.127 $">
<!-- if you are translating this document, please notate the CVS
revision of the developers reference here -->
<!--
administrator at &email-listmaster;. More information on available
mailing lists can be found in <ref id="mailing-lists">.
&email-debian-devel-announce; is another list which is mandatory
-for anyone who wish to follow Debian's development.
+for anyone who wishes to follow Debian's development.
<p>
You should subscribe and lurk (that is, read without posting) for a
bit before doing any coding, and you should post about your intentions
<sect id="mailing-lists">Mailing lists
<p>
-The mailing list server is at <tt>&lists-host;</tt>. Mail
+The mailing list server is at <tt>&lists-host;</tt>.
+ <p>
+Online archives of mailing lists are available at <url
+id="&url-lists-archives;">.
+
+ <sect1 id="core-devel-mailing-lists">Core development mailing lists
+ <p>
+The core Debian mailing lists that developers should use are:
+<list>
+ <item>&email-debian-devel-announce;, used to announce important things to
+ developers.
+ All developers are expected to be subscribed to this list.
+ </item>
+ <item>&email-debian-devel;, used to discuss various development related
+ technical issues.
+ </item>
+ <item>&email-debian-policy;, where the Debian Policy is discussed and
+ voted on.
+ </item>
+ <item>&email-debian-project;, used to discuss various non-technical
+ issues related to the project.
+ </item>
+</list>
+ <p>
+There are
+other mailing lists available for a variety of special topics; see
+<url id="&url-debian-lists-subscribe;"> for a list.
+
+ <sect1 id="mailing-lists-subunsub">Subscribing and unsubscribing
+ <p>
+To subscribe to or unsubscribe from any of the Debian mailing lists, email
<tt>debian-<var>foo</var>-REQUEST@&lists-host;</tt>, where
<tt>debian-<var>foo</var></tt> is the name of the list, with the word
<tt>subscribe</tt> in the <em>Subject</em> to subscribe to the list or
-<tt>unsubscribe</tt> to unsubscribe. More detailed instructions on
-how to subscribe and unsubscribe to the mailing lists can be found at
-<url id="&url-debian-lists-subscribe;">, <url id="&url-debian-lists;">
-or locally in &file-mail-lists; if you have the
-<package>doc-debian</package> package installed.
+<tt>unsubscribe</tt> to unsubscribe.
+ <p>
+If you prefer to use a web page to subscribe to multiple mailing lists,
+there's one at <url id="&url-debian-lists-subscribe;">.
+ <p>
+You can download the current list of mailing lists and basic usage
+instructions from <url id="&url-debian-lists-txt;">
+or install the <package>doc-debian</package> package and have it
+locally in &file-mail-lists;.
+
+ <sect1 id="mailing-lists-rules">Basic rules for use
<p>
When replying to messages on the mailing list, please do not send a
carbon copy (<tt>CC</tt>) to the original poster unless they explicitly
request to be copied. Anyone who posts to a mailing list should read
it to see the responses.
<p>
-The following are the core Debian mailing lists: &email-debian-devel;,
-&email-debian-policy;, &email-debian-user;, &email-debian-private;,
-&email-debian-announce;, and &email-debian-devel-announce;. All
-developers are expected to be subscribed to at least
-&email-debian-devel-announce;. There are
-other mailing lists available for a variety of special topics; see
-<url id="&url-debian-lists-subscribe;"> for a list. Cross-posting
-(sending the same message to multiple lists) is discouraged.
+Cross-posting (sending the same message to multiple lists) is discouraged.
+As ever on the net, please trim down the quoting of articles you're
+replying to. In general, please adhere to the usual conventions for
+posting messages. Please read the <url name="code of conduct"
+id="&url-debian-lists;"> for more information.
+
+ <sect1 id="mailing-lists-special">Special lists
<p>
&email-debian-private; is a special mailing list for private
discussions amongst Debian developers. It is meant to be used for
for Debian related correspondence such as contacting upstream authors
about licenses, bugs, etc. or discussing the project with others where it
might be useful to have the discussion archived somewhere.
- <p>
-As ever on the net, please trim down the quoting of articles you're
-replying to. In general, please adhere to the usual conventions for
-posting messages.
- <p>
-Online archives of mailing lists are available at <url
-id="&url-lists-archives;">.
<sect id="irc-channels">IRC channels
<p>
that newer push mirroring techniques ensure that mirrors are as
up-to-date as they can be.
<p>
-The main web page listing the available public FTP (and, usually,
-HTTP) servers can be found at <url id="&url-debian-mirrors;">. More
+The main web page listing the available public FTP/HTTP
+servers can be found at <url id="&url-debian-mirrors;">. More
information concerning Debian mirrors can be found at <url
id="&url-debian-mirroring;">. This useful page includes information
and tools which can be helpful if you are interested in setting up
to make sure everything in this distribution is working properly, it is
sometimes literally unstable.
<p>
-The testing distribution is generated automatically by taking
+<ref id="testing"> is generated automatically by taking
packages from unstable if they satisfy certain criteria. Those
criteria should ensure a good quality for packages within testing.
-<ref id="testing-scripts"> are launched each day after the
+The update to testing is launched each day after the
new packages have been installed.
<p>
After a period of development, once the release manager deems fit, the
<em>testing</em> distribution is frozen, meaning that the policies
-which control how packages move from <em>unstable</em> to testing are
+which control how packages move from <em>unstable</em> to <em>testing</em> are
tightened. Packages which are too buggy are removed. No changes are
allowed into <em>testing</em> except for bug fixes. After some time
has elapsed, depending on progress, the <em>testing</em> distribution
easily upload a package in one of the delayed directories:
<example>DELAY=5 dupload --to delayed <changes-file></example>
- <sect id="testing-scripts">
- <heading>The testing scripts</heading>
+ <sect id="testing">
+ <heading>The "testing" distribution</heading>
<p>
-The testing scripts are run each day after the installation of the
+The scripts that update the <em>testing</em> distribution are run each day
+after the installation of the
updated packages. They generate the <file>Packages</file> files for
the <em>testing</em> distribution, but they do so in an intelligent manner
trying to avoid any inconsistency and trying to use only
id="&url-testing-maint;">. Alternatively, it is possible to use
the <prgn>grep-excuses</prgn> program part of the
<package>devscripts</package> package. It can be easily put in a crontab
-to keep someone informed of the progression of his packages in testing.
+to keep someone informed of the progression of his packages in <em>testing</em>.
<p>
The <file>update_excuses</file> file does not always give the precise reason
why the package is refused, one may have to find it on their own by looking
id="&url-testing-faq;" name="testing FAQ"> gives some more information
about the usual problems which may be causing such troubles.
<p>
-Sometimes, some packages never enter testing because the set of
+Sometimes, some packages never enter <em>testing</em> because the set of
inter-relationship is too complicated and can not be sorted out
by the scripts. In that case, the release manager must be
contacted, and he will force the inclusion of the packages.
libdbd-mysql-perl | 1.2219-1 | unstable | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
</example>
<p>
-In this example, you can see that the version in unstable differs from
-the version in testing and that there has been a binary-only NMU of the
+In this example, you can see that the version in <em>unstable</em> differs from
+the version in <em>testing</em> and that there has been a binary-only NMU of the
package for the alpha architecture. Each time the package has been
recompiled on most of the architectures.
<item>
In the future, you may receive regular summary mails to keep you
informed of the package's status (bug statistics, porting overview,
-progression in testing, ...).
+progression in <em>testing</em>, ...).
</taglist>
<p>
You can also decide to receive some more information:
for the problem. As with any source NMU, the guidelines found in <ref
id="nmu-guidelines"> need to be followed.
<p>
-Bug fixes to unstable by non-maintainers are also acceptable, but only
-as a last resort or with permission. The following protocol should
-be respected to do an NMU:
+Uploading bug fixes to unstable by non-maintainers should only be done
+by following this protocol:
<p>
<list>
<item>
-Make sure that the package's bug is in the Debian Bug Tracking System
-(BTS). If not, submit a bug.
+Make sure that the package's bugs that the NMU is meant to address are all
+filed in the Debian Bug Tracking System (BTS).
+If they are not, submit them immediately.
<item>
Wait a few days the response from the maintainer. If you don't get
any response, you may want to help him by sending the patch that fixes
Follow what happens, you're responsible for any bug that you introduced
with your NMU. You should probably use <ref id="pkg-tracking-system"> (PTS)
to stay informed of the state of the package after your NMU.
- </list>
+</list>
+ <p>
+At times, the release manager or an organized group of developers can
+announce a certain period of time in which the NMU rules are relaxed.
+This usually involves shortening the period during which one is to wait
+before uploading the fixes, and shortening the DELAYED period. It is
+important to notice that even in these so-called "bug squashing party"
+times, the NMUer has to file bugs and contact the developer first,
+and act later.
<sect1 id="nmu-guidelines">How to do a source NMU
<p>
read <ref id="upload-bugfix">.
</enumlist>
+ <sect1 id="bug-security">Handling security-related bugs
+ <p>
+Due to their sensitive nature, security-related bugs must be handled
+carefully. The Debian Security Team exists to coordinate this
+activity, keeping track of outstanding security problems, helping
+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
+ <p>
+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;.
+Useful information includes, for example:
+
+<list compact>
+ <item>What versions of the package are known to be affected by the
+ bug.
+
+ <item>The nature of the exposure (root compromise, user compromise,
+ remote/local attack)
+
+ <item>The nature of the fix, if any is available (patches are
+ especially helpful)
+</list>
+
+ <sect2 id="bug-security-confidentiality">Confidentiality
+ <p>
+Unlike most other activities within Debian, information about security
+issues must sometimes be kept private for a time. Whether this is the
+case depends on the nature of the problem and corresponding fix, and
+whether it is already a matter of public knowledge.
+<p>
+There are a few ways a developer can learn of a security problem:
+
+<list compact>
+ <item>he notices it on a public forum (mailing list, website, etc.)
+ <item>someone files a bug report
+ <item>someone informs him via private email
+</list>
+
+ In the first two cases, the information is public and it is important
+ to have a fix as soon as possible. In the last case, however, it
+ might not be public information. In that case there are a few
+ possible options for dealing with the problem:
+
+<list>
+ <item>if it is a trivial problem (like insecure temporary files)
+ there is no need to keep the problem a secret and a fix should be
+ made and released.
+
+ <item>if the problem is severe (remotely exploitable, possibility to
+ gain root privileges) it is preferable to share the information with
+ other vendors and coordinate a release. The security team keeps
+ contacts with the various organizations and individuals and can take
+ care of that.
+</list>
+
+<p>
+ In all cases if the person who reports the problem asks to not
+ disclose the information that should be respected, with the obvious
+ exception of informing the security team (make sure you tell the
+ security team that the information can not be disclosed).
+
+<p>
+Please note that if secrecy is needed you can also not upload a fix to
+unstable (or anywhere else), since the changelog and diff information
+for unstable is public.
+
+<p>
+There are two reasons for releasing information even though secrecy is
+requested: the problem has been known for too long, or the information
+has become public.
+
+ <sect2 id="bug-security-advisories">Security Advisories
+ <p>
+Security advisories are only issued for the current, released stable
+distribution, not for testing or unstable. When released, advisories
+are sent to the &email-debian-security-announce;
+mailing list and posted on <url
+id="&url-debian-security-advisories;" name="the security web page">.
+Security advisories are written and posted by the security
+team. However they certainly do not mind if a maintainer can supply
+some of the information for them, or write part of the
+text. Information that should be in an advisory includes:
+
+<list compact>
+ <item>A description of the problem and its scope, including:
+ <list>
+ <item>The type of problem (privilege escalation, denial of
+ service, etc.)
+ <item>How it can be exploited
+ <item>Whether it is remotely or locally exploitable
+ <item>How the problem was fixed
+ </list>
+ <item>Version numbers of affected packages
+ <item>Version numbers of fixed packages
+ <item>Information on where to obtain the updated packages
+</list>
+
+ <sect2 id="bug-security-building">Preparing packages to
+ address security issues
+ <p>
+One way that you can assist the security team in their duties is to
+provide fixed packages suitable for a security advisory for the stable
+Debian release.
+ <p>
+ When an update is made to the stable release, care must be taken to
+ avoid changing system behaviour or introducing new bugs. In order to
+ do this, make as few changes as possible to fix the bug. Users and
+ administrators rely on the exact behaviour of a release once it is
+ made, so any change we make can possibly break someone's system.
+ This is especially true of libraries: make sure you never change the
+ API or ABI, no matter how small the change.
+<p>
+This means that moving to a new upstream version is not a good
+solution. Instead, the relevant changes should be backported to the
+version present in the current stable Debian release. Generally,
+upstream maintainers are willing to help if needed. If not, the
+Debian security team may be able to help.
+<p>
+In some cases, it is not possible to backport a security fix, for
+example when large amounts of sourcecode need to be modified or
+rewritten. If this happens, it may be necessary to move to a new
+upstream version. However, you must always coordinate that with the
+security team beforehand.
+<p>
+Related to this is another important guideline: always test your
+changes. If you have an exploit available, try it and see if it
+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.
+
+When packaging the fix, keep the following points in mind:
+
+<list>
+ <item>Make sure you target the right distribution in your
+ debian/changelog. For stable this is stable-security and for
+ testing this is testing-security. Do not target
+ <em>distribution</em>-proposed-updates!
+
+ <item>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 <tt>dpkg
+ --compare-versions</tt>. For testing, this means there must be
+ a greater 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.
+
+ <item>Do not make source-only uploads if your package has any
+ 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 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
+ normal archive, otherwise it is not possible to move the security
+ fix into the main archives later.
+
+ <item>Be sure, when compiling a package, to compile 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">)
+ or setup a chroot (see <ref id="pbuilder"> and
+ <ref id="debootstrap">).
+</list>
+
+ <sect2 id="bug-security-upload">Uploading the fixed package
+<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
+will automatically be rebuilt for all architectures and stored for
+verification by the security team.
+
+<p>
+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
+installed on security.debian.org as well as the proper
+<em>distribution</em>-proposed-updates on ftp-master or in the non-US
+archive.
<sect1 id="upload-bugfix">When bugs are closed by new uploads
<p>
~ianmdlvl / developers-reference.git / blobdiff