From: hertzog Date: Thu, 29 Aug 2002 15:36:06 +0000 (+0000) Subject: * Applied patch from Matt Zimmerman for handling security related bugs. X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=developers-reference.git;a=commitdiff_plain;h=8e61d80da8ddea01cc9381b35c986c11aba067b4 * Applied patch from Matt Zimmerman for handling security related bugs. git-svn-id: svn://anonscm.debian.org/ddp/manuals/trunk/developers-reference@1798 313b444b-1b9f-4f58-a734-7bb04f332e8d --- diff --git a/common.ent b/common.ent index f99823a..3cd4ae4 100644 --- a/common.ent +++ b/common.ent @@ -75,6 +75,7 @@ + @@ -127,6 +128,7 @@ debian-release@&lists-host;"> debian-email@&lists-host;"> debian-vote@&lists-host;"> +debian-security-announce@&lists-host;"> new-maintainer@debian.org"> keyring-maint@debian.org"> @@ -135,6 +137,7 @@ override-change@debian.org"> wnpp@debian.org"> control@bugs.debian.org"> +team@security.debian.org"> /usr/share/doc/debian/mailing-lists.txt"> diff --git a/debian/changelog b/debian/changelog index 6e40c8a..e999190 100644 --- a/debian/changelog +++ b/debian/changelog @@ -7,6 +7,7 @@ developers-reference (3.1) unstable; urgency=low - Applied patch from Matej Vela, dpkg-buildpackage does no more require -sa for version -0.1. closes: #150861 - Applied the reformulations proposed by David Kimdon. closes: #150572 + - Applied the patch of Matt Zimmerman. Thanks Matt ! closes: #145287 * Josip Rodin: - removed obsolete, needless dupload variables - applied linguistic fixes from David Kimdon, closes: #150572 diff --git a/developers-reference.sgml b/developers-reference.sgml index 8014ad6..79a6049 100644 --- a/developers-reference.sgml +++ b/developers-reference.sgml @@ -6,7 +6,7 @@ %commondata; - + + + What to do when you learn of a + security problem +

+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: + + + What versions of the package are known to be affected by the + bug. + + The nature of the exposure (root compromise, user compromise, + remote/local attack) + + The nature of the fix, if any is available (patches are + especially helpful) + + + Confidentiality +

+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. +

+There are a few ways a developer can learn of a security problem: + + + he notices it on a public forum (mailing list, website, etc.) + someone files a bug report + someone informs him via private email + + + 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: + + + 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. + + 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. + + +

+ 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). + +

+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. + +

+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. + + Security Advisories +

+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 . +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: + + + A description of the problem and its scope, including: + + The type of problem (privilege escalation, denial of + service, etc.) + How it can be exploited + Whether it is remotely or locally exploitable + How the problem was fixed + + Version numbers of affected packages + Version numbers of fixed packages + Information on where to obtain the updated packages + + + Preparing packages to + address security issues +

+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. +

+ 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. +

+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. +

+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. +

+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: + + + 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 + distribution-proposed-updates! + + 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. 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. + + 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. + + Always upload with full source (use the -sa option + for dpkg-buildpackage). + + 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. + + 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 ) + or setup a chroot (see and + ). + + + Uploading the fixed package +

+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 +ftp://security.debian.org/pub/SecurityUploadQueue/ . + +

+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. + +

+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. + +

+If a member of the security team accepts a package it will be +installed on security.debian.org as well as the proper +distribution-proposed-updates on ftp-master or in the non-US +archive. When bugs are closed by new uploads