<!ENTITY % dynamicdata SYSTEM "dynamic.ent" > %dynamicdata;
<!-- CVS revision of this document -->
- <!ENTITY cvs-rev "$Revision: 1.280 $">
+ <!ENTITY cvs-rev "$Revision: 1.291 $">
<!-- if you are translating this document, please notate the CVS
revision of the original developer's reference in cvs-en-rev -->
sponsor can request one at <url id="&url-sponsors;">.
-->
Please read the
-inofficial debian-mentors FAQ at <url id="&url-mentors;"> first.
+unofficial debian-mentors FAQ at <url id="&url-mentors;"> first.
<p>
If you wish to be a mentor and/or sponsor, more information is
available in <ref id="newmaint">.
OpenPGP is an open standard based on <url id="&url-rfc2440;" name="RFC
2440">.
<p>
-You need a type 4 key for use in Debian Development.
+You need a version 4 key for use in Debian Development.
Your key length must be at least 1024
bits; there is no reason to use a smaller key, and doing so would be
-much less secure. Your key must be signed with your own user
-ID; this prevents user ID tampering. <prgn>gpg</prgn> does this
-automatically.
+much less secure.
+<footnote>Version 4 keys are keys conforming to
+the OpenPGP standard as defined in RFC 2440. Version 4 is the key
+type that has always been created when using GnuPG. PGP versions
+since 5.x also could create v4 keys, the other choice having beein
+pgp 2.6.x compatible v3 keys (also called "legacy RSA" by PGP).
+<p>
+Version 4 (primary) keys can either use the RSA or the DSA algorithms,
+so this has nothing to do with GnuPG's question about "which kind
+of key do you want: (1) DSA and Elgamal, (2) DSA (sign only), (5)
+RSA (sign only). If you don't have any special requirements just pick
+the defailt.
+<p>
+The easiest way to tell whether an existing key is a v4 key or a v3
+(or v2) key is to look at the fingerprint:
+Fingerprints of version 4 keys are the SHA-1 hash of some key matieral,
+so they are 40 hex digits, usually grouped in blocks of 4. Fingerprints
+of older key format versions used MD5 and are generally shown in blocks
+of 2 hex digits. For example if your fingerprint looks like
+<tt>5B00 C96D 5D54 AEE1 206B AF84 DE7A AF6E 94C0 9C7F</tt>
+then it's a v4 key.
+<p>
+Another possibility is to pipe the key into <prgn>pgpdump</prgn>,
+which will say something like "Public Key Packet - Ver 4".
+<p>
+Also note that your key must be self-signed (i.e. it has to sign
+all its own user IDs; this prevents user ID tampering). All
+modern OpenPGP software does that automatically, but if you
+have an older key you may have to manually add those signatures.
+</footnote>
<p>
If your public key isn't on public key servers such as &pgp-keyserv;,
please read the documentation available locally in &file-keyservs;.
<item>
Orphan all your packages, as described in <ref id="orphaning">.
<item>
-Send an email about why you are leaving the project to
+Send an gpg-signed email about why you are leaving the project to
&email-debian-private;.
<item>
Notify the Debian key ring maintainers that you are leaving by
all the files.
<p>
There are other additional channels dedicated to specific subjects.
-<em>#debian-bugs</em> is used for coordinating bug squash parties.
+<em>#debian-bugs</em> is used for coordinating bug squashing parties.
<em>#debian-boot</em> is used to coordinate the work on the debian-installer.
<em>#debian-doc</em> is
occasionally used to talk about documentation, like the document you are
the <url name="Open and free technology community (OFTC)"
id="http://www.oftc.net/"> IRC network.
<p>
-To get a cloak on freenode, you send Göran Weinholt <weinholt@debian.org>
+To get a cloak on freenode, you send Jörg Jaspert <joerg@debian.org>
a signed mail where you tell what your nick is.
Put "cloak" somewhere in the Subject: header.
The nick should be registered:
These are the <manref name="sources.list" section="5"> lines for
<em>experimental</em>:
<example>
-deb http://ftp.<var>xy</var>.debian.org/debian/ ../project/experimental main
-deb-src http://ftp.<var>xy</var>.debian.org/debian/ ../project/experimental main
+deb http://ftp.<var>xy</var>.debian.org/debian/ experimental main
+deb-src http://ftp.<var>xy</var>.debian.org/debian/ experimental main
</example>
<p>
If there is a chance that the software could do grave damage to a system,
<p>
Every released Debian distribution has a <em>code name</em>: Debian
1.1 is called `buzz'; Debian 1.2, `rex'; Debian 1.3, `bo'; Debian 2.0,
-`hamm'; Debian 2.1, `slink'; Debian 2.2, `potato'; and Debian 3.0, `woody'. There is also
-a ``pseudo-distribution'', called `sid', which is the current
+`hamm'; Debian 2.1, `slink'; Debian 2.2, `potato'; Debian 3.0, `woody';
+Debian 3.1, "sarge";
+Debian (number needs to be determined), "etch".
+There is also a ``pseudo-distribution'', called `sid', which is the current
`unstable' distribution; since packages are moved from `unstable' to
`testing' as they approach stability, `sid' itself is never released.
As well as the usual contents of a Debian distribution, `sid' contains
<item>
Translations of descriptions or debconf templates
submitted to the Debian Description Translation Project.
+
+ <tag><tt>derivatives</tt>
+ <item>
+Information about changes made to the package in derivative distributions
+(for example Ubuntu).
</taglist>
<sect1 id="pts-commands">The PTS email interface
<p>
You can control your subscription(s) to the PTS by sending
-various commands to <email>pts@qa.debian.org</email>.
+various commands to <email>pts@qa.debian.org</email>.
<taglist>
using the specified email address or the sender address if the second
argument is left out.
+<tag><tt>unsubscribeall [<email>]</tt>
+<item>
+ Removes all subscriptions of the specified email address or the sender
+ address if the second argument is left out.
+
<tag><tt>which [<email>]</tt>
<item>
Lists all subscriptions for the sender or the email address optionally
<item><tt>summary</tt>: automatic summary mails about the state of a package
<item><tt>cvs</tt>: notification of CVS commits
<item><tt>ddtp</tt>: translations of descriptions and debconf templates
+ <item><tt>derivatives</tt>: changes made on the package by derivative distributions
<item><tt>upload-source</tt>: announce of a new source upload that
has been accepted
<item><tt>upload-binary</tt>: announce of a new binary-only upload (porting)
<tag><tt>keyword [<email>] {+|-|=} <list of keywords></tt>
<item>
Accept (+) or refuse (-) mails classified under the given keyword(s).
- Define the list (=) of accepted keywords.
+ Define the list (=) of accepted keywords. This changes the default set
+ of keywords accepted by a user.
+
+<tag><tt>keywordall [<email>] {+|-|=} <list of keywords></tt>
+<item>
+ Accept (+) or refuse (-) mails classified under the given keyword(s).
+ Define the list (=) of accepted keywords. This changes the set of
+ accepted keywords of all the currently active subscriptions of a user.
<tag><tt>keyword <sourcepackage> [<email>] {+|-|=} <list of keywords></tt>
<item>
the bot.
</taglist>
+ <p>
+The <prgn>pts-subscribe</prgn> command-line utility (from the
+<package>devscripts</package> package) can be handy to temporarily
+subscribe to some packages, for example after having made an
+non-maintainer upload.
+
<sect1 id="pts-mail-filtering">Filtering PTS mails
<p>
Once you are subscribed to a package, you will get the mails sent to
tests the <file>postrm</file> and <file>prerm</file> scripts.
<item>
Remove the package, then reinstall it.
+ <item>
+Copy the source package in a different directory and try unpacking it and
+rebuilding it. This tests if the package relies on existing files outside of
+it, or if it relies on permissions being preserved on the files shipped inside
+the .diff.gz file.
</list>
source tar-file used by <prgn>dpkg-source</prgn> when constructing the
<file>.dsc</file> file and diff to be uploaded <em>must</em> be
byte-for-byte identical with the one already in the archive.
+ <p>
+Please notice that, in non-native packages, permissions on files that are not
+present in the .orig.tar.gz will not be preserved, as diff does not store file
+permissions in the patch.
<sect id="distribution">Picking a distribution
<sect1 id="upload-bugfix">When bugs are closed by new uploads
<p>
-As bugs and problems are fixed your packages, it is your
-responsibility as the package maintainer to close the bug. However,
-you should not close the bug until the package which fixes the bug has
+As bugs and problems are fixed in your packages, it is your
+responsibility as the package maintainer to close these bugs. However,
+you should not close a bug until the package which fixes the bug has
been accepted into the Debian archive. Therefore, once you get
notification that your updated package has been installed into the
archive, you can and should close the bug in the BTS.
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> .
+<tt>ftp://security-master.debian.org/pub/SecurityUploadQueue/</tt> .
<p>
Once an upload to the security queue has been accepted, the package
If for some reason you want to completely remove a package (say, if it
is an old compatibility library which is no longer required), you
need to file a bug against <tt>ftp.debian.org</tt> asking that the
-package be removed. Make sure you indicate which distribution the
+package be removed;
+as all bugs, this bug should normally have normal severity.
+Make sure you indicate which distribution the
package should be removed from. Normally, you can only have packages
removed from <em>unstable</em> and <em>experimental</em>. Packages
are not removed from <em>testing</em> directly. Rather, they will be
get this wrong, the archive maintainers will reject your upload (due
to lack of corresponding source code).
<p>
-The ``magic'' for a recompilation-only NMU is triggered by using the
-third-level number on the Debian part of the version. For instance,
-if the latest version you are recompiling against was version
-``2.9-3'', your NMU should carry a version of ``2.9-3.0.1''. If the
-latest version was ``3.4-2.1'', your NMU should have a version number
-of ``3.4-2.1.1''.
+The ``magic'' for a recompilation-only NMU is triggered by using a
+suffix appended to the package version number,
+following the form b<number>.
+For instance, if the latest version you are
+recompiling against was version ``2.9-3'', your NMU should carry a
+version of ``2.9-3+b1''. If the latest version was ``3.4+b1'' (i.e, a
+native package with a previous recompilation NMU), your NMU should have
+a version number of ``3.4+b2''.
+
+<footnote>
+In the past, such NMUs used the third-level number on the Debian part of
+the revision to denote their recompilation-only status; however, this
+syntax was ambiguous with native packages and did not allow proper
+ordering of recompile-only NMUs, source NMUs, and security NMUs on the
+same package, and has therefore been abandoned in favor of this new
+syntax.</footnote>
<p>
Similar to initial porter uploads, the correct way of invoking
<prgn>dpkg-buildpackage</prgn> is <tt>dpkg-buildpackage -B</tt> to only
<p>
Some packages still have issues with building and/or working on some
of the architectures supported by Debian, and cannot be ported at all,
-or not with a reasonable amount of time. An example is a package that
+or not within a reasonable amount of time. An example is a package that
is SVGA-specific (only i386), or uses other hardware-specific features
not supported on all architectures.
<p>
package, it must be included in <file>packages-arch-specific</file>, a
list used by the <prgn>wanna-build</prgn> script.
The current version is available as
-<url id="http://cvs.debian.org/srcdep/Packages-arch-specific?rev=HEAD&cvsroot=dak&content-type=text/vnd.viewcvs-markup">;
+<url id="http://cvs.debian.org/srcdep/Packages-arch-specific?cvsroot=dak">;
please see the top of the file for whom to contact for changes.
</list>
<p>
A porter or any other person trying to build your package might
accidently upload it without noticing it doesn't work.
If in the past some binary packages were uploaded on unsupported architectures,
-request there removal by filing a bug against
+request their removal by filing a bug against
<package>ftp.debian.org</package>
However, aesthetic changes must <em>not</em> be made in a non-maintainer
upload.
<p>
-And please remember the Hippocratic Oath: "Above all, do no harm."
-It is better if a package has an grave bug open, than if a not working
-patch was applied, and the bug is only hidden now but not resolved.
+And please remember the Hippocratic Oath: "Above all, do no harm." It
+is better to leave a package with an open grave bug than applying a
+non-functional patch, or one that hides the bug instead of resolving
+it.
<sect1 id="nmu-guidelines">How to do a NMU
for a package to enter testing is through unstable.
<p>
For the stable distribution, please take extra care. Of course, the release
-managers may also change the rules here. Please verify before upload that
+managers may also change the rules here. Please verify before you upload that
all your changes are OK for inclusion into the next stable release by the
release manager.
<p>
really fixes each problem that was fixed in the non-maintainer release.
<p>
In addition, the normal maintainer should <em>always</em> retain the
-entry in the changelog file documenting the non-maintainer upload.
+entry in the changelog file documenting the non-maintainer upload --
+and of course, also keep the changes.
+If you revert some of the changes,
+please reopen the relevant bug reports.
<sect1 id="nmu-build">Building source NMUs
Those delays may be doubled during a freeze, or testing transitions may be
switched off altogether;
<item>
-It must have fewer release-critical bugs than the version currently available
+It must have the same number or fewer release-critical bugs than the version currently available
in <em>testing</em>;
<item>
It must be available on all architectures on which it has previously
<p>
Now, the more complex part happens: Britney tries to update testing with
the valid candidates; first, each package alone, and then larger and even
-larger sets of packages together. Each try is accepted if unstable is not
+larger sets of packages together. Each try is accepted if testing is not
more uninstallable after the update than before. (Before and after this part,
some hints are processed; but as only release masters can hint, this is
probably not so important for you.)
<sect1 id="helper-scripts">Helper scripts
<p>
The rationale for using helper scripts in <file>debian/rules</file> is
-that lets maintainers use and share common logic among many packages.
+that they let maintainers use and share common logic among many packages.
Take for instance the question of installing menu entries: you need to
-put the file into <file>/usr/lib/menu</file>, and add commands to the
+put the file into <file>/usr/lib/menu</file> (or
+<file>/usr/lib/menu</file> for executable binary menufiles, if this is needed),
+and add commands to the
maintainer scripts to register and unregister the menu entries. Since
this is a very common thing for packages to do, why should each
maintainer rewrite all this on their own, sometimes with bugs? Also,
patches. See the package <package>dbs</package> for more information and
<package>hello-dbs</package> for an example.
<p>
-<prgn>dpatch</prgn> also provides these facilities, but it's intented to be
+<prgn>dpatch</prgn> also provides these facilities, but it's intended to be
even easier to use. See the package <package>dpatch</package> for
documentation and examples (in <file>/usr/share/doc/dpatch</file>).
the package manager (e.g., "this is the client for the foo server")?
<p>
Be careful to avoid spelling and grammar mistakes. Ensure that you
-spell-check it. <prgn>ispell</prgn> has a special <tt>-g</tt> option
-for <file>debian/control</file> files:
+spell-check it. Both <prgn>ispell</prgn> and <prgn>aspell</prgn>
+have special modes for checking <file>debian/control</file> files:
<example>ispell -d american -g debian/control</example>
+<example>aspell -d en -D -c debian/control</example>
<p>
Users usually expect these questions to be answered in the package
description:
<file>debian/control</file> field understood by <prgn>dpkg</prgn> and
<tt>&packages-host;</tt>. If you don't want to bother migrating the
home page from the description to this field, you should probably wait
-until that is available.</p>
+until that is available.
+ Please make sure that this line matches the regular expression
+ <tt>/^ Homepage: [^ ]*$/</tt>,
+ as this allows <file>packages.debian.org</file> to parse it correctly.</p>
</sect1>
</sect>
tracking system.
<p>
It is an old tradition to acknowledge bugs fixed in non-maintainer
-uploads in the first changelog entry of the proper maintainer upload,
-for instance, in a changelog entry like this:
-<example>
- * Maintainer upload, closes: #42345, #44484, #42444.
-</example>
-This will close the NMU bugs tagged "fixed" when the package makes
-it into the archive. The bug for the fact that an NMU was done can be
-closed the same way. Of course, it's also perfectly acceptable to
-close NMU-fixed bugs by other means; see <ref id="bug-answering">.
+uploads in the first changelog entry of the proper maintainer upload.
+Please use the option <tt>-v</tt> to <prgn>dpkg-buildpackage</prgn>
+to close the relevant bug report.
</sect1>
<sect1 id="bpp-changelog-errors">
this problem, though.
</sect>
- <sect id="bpp-debian-security-audit">
- <heading>Best practices for security review and design</heading>
-
-<p>When you are packaging software for other users you should make a
-best effort to ensure that the installation of the software, or its
-use, does not introduce security risks to either the system it is
-installed on or its users.</p>
-
-<p>You should make your best to review the source code of the package and
-detect issues that might introduce security bugs. The programming bugs
-which lead to security bugs typically include: <url
-id="http://en.wikipedia.org/wiki/Buffer_overflow" name="buffer
-overflows">, <url
-id="http://en.wikipedia.org/wiki/Cross_site_scripting" name="format
-string overflows">, <url
-id="http://en.wikipedia.org/wiki/Cross_site_scripting" name="heap
-overflows"> and <url
-id="http://en.wikipedia.org/wiki/Cross_site_scripting" name="integer
-overflows"> (in C/C++ programs), temporary <url
-id="http://en.wikipedia.org/wiki/Symlink_race" name="symlink race
-conditions"> (in scripts), <url
-id="http://en.wikipedia.org/wiki/Directory_traversal" name="directory
-traversal"> and command injection (in servers) and <url
-id="http://en.wikipedia.org/wiki/Cross_site_scripting"
-name="cross-site scripting">, and <url
-id="http://en.wikipedia.org/wiki/Cross_site_scripting" name="SQL
-injection bugs"> (in the case of web-oriented applications).</p>
-
-<p>Some of these issues might not be easy to spot unless you are an
-expert in the programming language the program uses, but some security
-problems are easy to detect and fix. For example, finding temporary
-race conditions in the source code can easily be done by running
-<tt>grep -r "/tmp/" .</tt> in the source code replace
-hardcoded filenames using temporary directories to calls to either
-<prgn>mktemp</prgn> or <prgn>tempfile</prgn> in shell
-scripts, <manref name="File::Temp" section="3perl"> in Perl scripts,
-and <manref name="tmpfile" section="3"> in C/C++. You can also use
-<url id="http://www.debian.org/security/audit/tools" name="specific
-tools"> to assist to the security code review phase.</p>
-
-<p>When packaging software make sure that:
-
-<list>
-
-<item>The software runs with the minimum privileges it needs:
-
-<list>
-<item>The package does install binaries setuid or setgid.
-<prgn>Lintian</prgn> will warn of <url id="
-http://lintian.debian.org/reports/Tsetuid-binary.html" name="setuid">,
-<url id="http://lintian.debian.org/reports/Tsetgid-binary.html"
-name="setgid"> and <url
-id="http://lintian.debian.org/reports/Tsetuid-gid-binary.html"
-name="setuid and setgid"> binaries.
-
-<item>The daemons the package provide run with a
-low privilege user (see <ref id="bpp-lower-privs">)
-
-</list>
-
-<item>Programmed (i.e., <prgn>cron</prgn>) tasks running in the
-system do NOT run as root or, if they do, do not implement complex
-tasks.
-
-</list>
-
-<p>If you have to do any of the above make sure the programs that
-might run with higher privileges have been audited for security
-bugs. If you are unsure, or need help, contact the <url
-id="http://www.debian.org/security/audit/" name="Debian Security Audit
-team">. In the case of setuid/setgid binaries, follow the Debian
-policy section regarding
-<url id="http://www.debian.org/doc/debian-policy/ch-files.html#s10.9"
-name="permissions and owners">
-</p>
-
-<p>For more information, specific to secure programming, make sure you
-read (or point your upstream to) <url
-id="http://www.dwheeler.com/secure-programs/" name="Secure Programming
-for Linux and Unix HOWTO"> and the <url
-id="https://buildsecurityin.us-cert.gov/portal/" name="Build Security
-In"> portal. For more information specific to Debian security you can
-read the <url
-id="http://www.debian.org/doc/manuals/securing-debian-howto/"
-name="Debian Security Manual">
-</p>
-
-<!-- This should be explained here until #291177 gets fixed and this is
- added to poliy -->
-
- <sect1 id="bpp-lower-privs">
- <heading>System users and groups for software daemons
-
-<p>If your software runs a daemon that does not need root privileges,
-you need to create a user for it. There are two kind of Debian users
-that can be used by packages: static uids (assigned by
-<package>base-passwd</package>) and dynamic uids in the range assigned
-to system users.
-
-<p>In the first case, you need to ask for a user or group id to the
-<package>base-passwd</package>, and a proper versioned depends to the
-<package>base-passwd</package> package that provides the user.
-
-<p>In the second case, you need to create the system user through maintainer
-scripts. <url id="http://www.debian.org/doc/debian-policy/ch-files.html#s10.9"
-name="policy"> requires you discuss an appropiate user and group name on
-<em>debian-devel</em> and make sure it is unique and does not overlap
-with other packages.
-
-<p>Running programs with a user with limited privileges makes sure
-that any security issue with the program makes limited damaged to the
-system and follows the principle of <em>least privilege</em> you can
-limit privileges in programs through other mechanisms besides running
-as non-root. Fore more information, read the <url
-id="http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/minimize-privileges.html"
-name="Minimize Privileges"> chapter of the <em>Secure Programming for
-Linux and Unix HOWTO</em> book.
-
- <sect2 id="bpp-create-sysuser">
- <heading>Creating system users and groups
-
-<p>If you want to create system groups on package installation you
-need to create it in either the <em>preinst</em> or in the <em>postinst</em>
-and have the package depend on <tt>adduser (>= 3.11)</tt>.
-
-<p>The following example code creates the user and group the daemon
-will run as when the package is installed or upgraded:
-
-<example>
-[...]
-case "$1" in
- install|upgrade)
-
- # If the package has default file it could be sourced, so that
- # the local admin can overwrite the defaults
- # Notice that the package could handle this defaults through
- # debconf so that the local admin could select a different
- # user name for the system user than the one hardcoded in the
- # package
-
- [ -f "/etc/default/<var>packagename</var>" ] && . /etc/default/<var>packagename</var>
-
-
- # Sane defaults:
-
- [ -z "$SERVER_HOME" ] && SERVER_HOME=<var>server_dir</var>
- [ -z "$SERVER_USER" ] && SERVER_USER=<var>server_user</var>
- [ -z "$SERVER_NAME" ] && SERVER_NAME="<var>Server description</var>"
- [ -z "$SERVER_GROUP" ] && SERVER_GROUP=<var>server_group</var>
-
- # Groups that the user will be added to, if undefined, then none.
- # Some daemons might need additional privileges and those can be
- # granted by adding it to additional groups.
- ADDGROUP=""
-
-
- # create user to avoid running server as root
- # 1. create group if not existing
- if ! getent group | grep -q "^$SERVER_GROUP:" ; then
- echo -n "Adding system group $SERVER_GROUP.."
- addgroup --quiet --system $SERVER_GROUP
- if ! getent group | grep -q "^$SERVER_GROUP:"; then
- echo "..ERROR creating system group. Aborting installation."
- exit 1
- fi
- echo "..done"
- fi
- # 2. create homedir if it does not exist
- test -d $SERVER_HOME || mkdir $SERVER_HOME
- # 3. create user if it does not exist
- if ! getent passwd | grep -q "^$SERVER_USER:"; then
- echo -n "Adding system user $SERVER_USER.."
- adduser --quiet \
- --system \
- --ingroup $SERVER_GROUP \
- --no-create-home \
- --disabled-password \
- $SERVER_USER
- if ! getent passwd | grep -q "^$SERVER_USER:"; then
- echo "..ERROR creating system user. Aborting installation."
- exit 1
- fi
- echo "..done"
- # 4. adjust passwd entry, only do this if the package
- # creates the user
- usermod -c "$SERVER_NAME" \
- -d $SERVER_HOME \
- -g $SERVER_GROUP \
- $SERVER_USER
- else
- # The package might want to check if the user already exists
- # and it is *not* a system user, in this case it could abort
- # the installation (like in this example) or ask the administrator.
- # Using a non-system user as the one in our package could
- # have unexpected consequences.
- # Some packages try to prevent this kind of collision by using
- # a prefix such as 'Debian-'
- for LINE in `grep SYSTEM_UID /etc/adduser.conf | grep -v "^#"`; do
- case $LINE in
- FIRST_SYSTEM_UID*)
- FIRST_SYSTEM_UID=`echo $LINE | cut -f2 -d '='`
- ;;
- LAST_SYSTEM_UID*)
- LAST_SYSTEM_UID=`echo $LINE | cut -f2 -d '='`
- ;;
- *)
- ;;
- esac
- done
- # Abort package installation if the user has not been created by
- # us.
- if [ -n "$FIRST_SYSTEM_UID" ] && [ -n "$LAST_SYSTEM_UID" ]; then
- if USERID=`getent passwd $SERVER_USER | cut -f 3 -d ':'`; then
- if [ -n "$USERID" ]; then
- if [ "$FIRST_SYSTEM_UID" -le "$USERID" ] && \
- [ "$USERID" -le "$LAST_SYSTEM_UID" ]; then
- echo "The user $SERVER_USER already exists as a non system user!" >&2
- echo "Aborting package installation" >&2
- exit 1
- fi
- fi
- fi
- fi
- fi
-
- # 5. adjust file and directory permissions
- # The example below sets the server home as 750 as it
- # contains (hypothetically) sensible information.
- if ! dpkg-statoverride --list $SERVER_HOME >/dev/null
- then
- chown -R $SERVER_USER:adm $SERVER_HOME
- chmod u=rwx,g=rxs,o= $SERVER_HOME
- fi
- # 6. Add the user to the ADDGROUP group
- if test -n $ADDGROUP
- then
- if ! groups $SERVER_USER | grep -q $ADDGROUP; then
- adduser $SERVER_USER $ADDGROUP
- fi
- fi
- ;;
- configure)
-
-[...]
-</example>
-
- <sect2 id="bpp-using-sysuser">
- <heading>Using system users
-
-<p>In order to make use of the system user you have to make sure that the
-init.d script file:
-
-<list>
-<item>Starts the daemon dropping privileges, if the software does not
-do the <manref name="setuid" section="2"> or <manref name="seteuid"
-section="2"> call itself, you can use the <tt>--chuid</tt>
-call of <prgn>start-stop-daemon</prgn>.
-
-<item>Stops the daemon only if the user id matches, you can use the
-<prgn>start-stop-daemon</prgn> <tt>--user</tt> option
-for this.
-
-<item>Does not run if either the user or the group do not exist:
-<example>
- if getent passwd | grep -q "^<var>server_user</var>:"; then
- echo "Server user does not exist. Aborting" >&2
- exit 1
- fi
- if getent group | grep -q "^<var>server_group</var>:" ; then
- echo "Server group does not exist. Aborting" >&2
- exit 1
- fi
-</example>
-
-</list>
-
-<p>File ownerships of files shipped by the package will need to be adjusted:
-
-<list>
-<item>Configuration files should be readable by the system user, if they
-contain sensitive information the system user should not own them unless there
-is a need for it to write to its own configuration files. Typically this means
-that the configuration files are owned by root and by the system group created
-by the package and are mode 0640.
-
-<item>If the The system user generates state files (such as pidfiles) it will
-need to have a directory under <tt>/var/run</tt> owned by itself. It can be
-created by the package maintainers script but, since it can be wiped after a
-system reboot, it should be be recreated by the init.d script since the state
-directory.
-
-<item>If the daemon logs directly to <tt>/var/log</tt> logfiles should be
-writable by the system user but, once rotated, they should not be either owned
-or writable by it to prevent it from overwritting old log entries if a security
-vulnerability in the software were to be used. If the daemon logs to a
-directory under <tt>/var/log/</tt> then the directory should be owned by the
-system user and rotated log files need not be changed ownership.
-
-</list>
-
- <sect2 id="bpp-removing-sysuser">
- <heading>Removing system users
-
-<p>If the package creates the system user it can remove it when it is
-purged in its <em>postrm</em> script. This currently <em>not</em> recommended
-for all situations since it has a few known
-<footnote>
-Some relevant threads discussing these issues include:
-<url
-id="http://lists.debian.org/debian-mentors/2004/10/msg00338.html">,
-<url id="http://lists.debian.org/debian-devel/2004/05/msg01156.html">
-and
-<url id="http://lists.debian.org/debian-devel/2005/10/msg00988.html">.
-</footnote>
-drawbacks. For example, files created by the daemon (or by an admin
-impersonating it) either on the local filesystem or in backup files will be
-orphaned and might be taken over by a new system user in the future if it is
-assigned the same uid. On the other hand, an unused local system user can be
-used to access even if the account has been locked (as some authentication
-systems might not use PAM or shadow authentication).
-
-<p>If you want to remove a system user and there is a possibility of it
-leaving orphaned files, the administrator should be asked for the preferred
-action either when the package is installed or when it is removed (see <ref
-id="debconf">).
-
-<p>The following example code removes the user and groups created
-before only, and only if, the uid is in the range of dynamic assigned system
-uids and the gid is belongs to a system group:
-
-<example>
-case "$1" in
- purge)
-[...]
- # find first and last SYSTEM_UID numbers
- if [ -r /etc/adduser.conf ] ; then
- for LINE in `grep SYSTEM_UID /etc/adduser.conf | grep -v "^#"`; do
- case $LINE in
- FIRST_SYSTEM_UID*)
- FIRST_SYSTEM_UID=`echo $LINE | cut -f2 -d '='`
- ;;
- LAST_SYSTEM_UID*)
- LAST_SYSTEM_UID=`echo $LINE | cut -f2 -d '='`
- ;;
- FIRST_SYSTEM_GID*)
- FIRST_SYSTEM_GID=`echo $LINE | cut -f2 -d '='`
- ;;
- LAST_SYSTEM_GID*)
- LAST_SYSTEM_GID=`echo $LINE | cut -f2 -d '='`
- ;;
- *)
- ;;
- esac
- done
- fi
- # Sane defaults
- [ -z "$FIRST_SYSTEM_UID" ] && FIRST_SYSTEM_UID=100
- [ -z "$LAST_SYSTEM_UID" ] && LAST_SYSTEM_UID=999
- [ -z "$FIRST_SYSTEM_GID" ] && FIRST_SYSTEM_GID=100
- [ -z "$LAST_SYSTEM_GID" ] && LAST_SYSTEM_GID=999
-
- # Remove system account if it is a system user
- CREATEDUSER="<var>server_user</var>"
- if [ -n "$FIRST_SYSTEM_UID" ] && [ -n "$LAST_SYSTEM_UID" ]; then
- if USERID=`getent passwd $CREATEDUSER | cut -f 3 -d ':'`; then
- if [ -n "$USERID" ]; then
- if [ "$FIRST_SYSTEM_UID" -le "$USERID" ] && \
- [ "$USERID" -le "$LAST_SYSTEM_UID" ]; then
- echo -n "Removing $CREATEDUSER system user.."
- deluser --quiet $CREATEDUSER || true
- echo "..done"
- fi
- fi
- fi
- fi
- # Remove system group if it is a system group
- CREATEDGROUP=<var>server_group</var>
- if [ -n "$FIRST_SYSTEM_GID" ] && [ -n "$LAST_SYSTEM_GID" ]; then
- if GROUPGID=`getent group $CREATEDGROUP | cut -f 3 -d ':'`; then
- if [ -n "$GROUPGID" ]; then
- if [ "$FIRST_SYSTEM_GID" -le "$GROUPID" ] && \
- [ "$GROUPID" -le "$LAST_SYSTEM_GID" ]; then
- echo -n "Removing $CREATEDGROUP group.."
- delgroup --only-if-empty $CREATEDGROUP || true
- echo "..done"
- fi
- fi
- fi
- fi
-[...]
-</example>
-
-<p>Other possibilities, are making sure the account is locked (has an invalid
-password and <em>/bin/false</em> as a shell) and/or changing the GECOS field
-pointing out that the account is no longer used.
-
-<!-- There is currently no consensus as to how any of the above should be
- done in a way that would make it easy for administrators to locate
- unused (but not removed) accounts -->
-
-</sect1>
-
-</sect>
<sect id="bpp-config-mgmt">
<heading>Configuration management with <package>debconf</package></heading>
<p>
These guidelines include some writing style and typography
recommendations, general considerations about debconf usage as well as
-more specific recommendations for some parts of the distribution (for
-instance, the installation system).
+more specific recommendations for some parts of the distribution (the
+installation system for instance).
<sect1>Do not abuse debconf
<p>
<sect2>Description: short and extended description
<p>
-Templates descriptions have two parts: short and extended. The short
+Template descriptions have two parts: short and extended. The short
description is in the "Description:" line of the template.
<p>
The short description should be kept short (50 characters or so) so
<p>
Policy specifies that documentation should be shipped in HTML format.
We also recommend shipping documentation in PDF and plain text format if
-convenient and quality output is possible. However, it is generally
+convenient and if output of reasonable quality is possible. However, it is generally
not appropriate to ship plain text versions of documentation whose source
format is HTML.</p>
<p>
There are two kinds of original source tarballs: Pristine source
and repackaged upstream source.
</p>
- <sect2 id="pristine source">
+ <sect2 id="pristinesource">
<heading>Pristine source</heading>
<p>
The defining characteristic of a pristine source tarball is that the
distributed by the upstream author.
<footnote>
We cannot prevent upstream authors from changing the tarball
-they distribute without also upping the version number, so
+they distribute without also incrementing the version number, so
there can be no guarantee that a pristine tarball is identical
to what upstream <em>currently</em> distributing at any point in
time. All that can be expected is that it is identical to
</enumlist>
</p>
</sect2>
- <sect2 id="repackaged origtargz">
+ <sect2 id="repackagedorigtargz">
<heading>Repackaged upstream source</heading>
<p>
You <strong>should</strong> upload packages with a pristine source
<p>
You may also be interested in contacting the persons who are
subscribed to a given source package via <ref id="pkg-tracking-system">.
-You can do so by using the <tt><package-name>@&pts-host;</tt>
+You can do so by using the <tt><package>@&pts-host;</tt>
email address.
<!-- FIXME: moo@packages.d.o is easily confused with moo@packages.qa.d.o -->
It is also allowed to post a query to &email-debian-devel;, asking if anyone
is aware of the whereabouts of the missing maintainer.
<p>
-Once you have gathered all of this, you can contact &email-debian-qa;.
+Once you have gathered all of this, you can contact &email-mia;.
People on this alias will use the information you provided in order to
decide how to proceed. For example, they might orphan one or all of the
packages of the maintainer. If a packages has been NMUed, they might prefer
avoid the chaos resulting in having several versions of the same document in
bug reports.
<p>
-The best solution is to fill a regular bug containing the translation against
+The best solution is to file a regular bug containing the translation against
the package. Make sure to use the 'PATCH' tag, and to not use a severity higher
than 'wishlist', since the lack of translation never prevented a program from
running.
<package>debhelper</package>.
<p>
The consensus is that <package>debmake</package> is now deprecated in
-favor of <package>debhelper</package>. However, it's not a bug to use
-<package>debmake</package>.
+favor of <package>debhelper</package>. It is a bug to use
+<package>debmake</package> in new packages. New packages using
+<package>debmake</package> will be rejected from the archive.
</sect1>
<sect1 id="dh-make">
~ianmdlvl / developers-reference.git / blobdiff