path: root/english/security/faq.wml

#use wml::debian::template title="Debian security FAQ"
#include "$(ENGLISHDIR)/security/faq.inc"
# $Id$

<maketoc>

<toc-add-entry name=buthow>I received a DSA via debian-security-announce, how can I upgrade the vulnerable packages?</toc-add-entry>

<p>A: As the DSA mail says, you should upgrade the packages affected by the
  announced vulnerability. You can do this by just upgrading (after
  updating the list of available packages with <tt>apt-get update</tt>)
  every package in your system with <tt>apt-get upgrade</tt> or by
  upgrading just a particular package, with <tt>apt-get install
  <i>package</i></tt>.</p>

<p>The announcement mail mentions the source package in which the vulnerability
   was present. Therefore, you should update all the binary packages from
   that source package. To check the binary packages to update, visit
   <tt>https://packages.debian.org/src:<i>source-package-name</i></tt> and
   click on <i>[show ... binary packages]</i> for the distribution you
   are updating.</p>

<p>It may also be necessary to restart a service or a running process. The
   command <a href="https://manpages.debian.org/checkrestart"><tt>checkrestart</tt></a>
   included in the package
   <a href="https://packages.debian.org/debian-goodies">debian-goodies</a>
   might help to find which ones.</p>


<toc-add-entry name=signature>The signature on your advisories does not verify correctly!</toc-add-entry>
<p>A: This is most likely a problem on your end. The
   <a href="https://lists.debian.org/debian-security-announce/">\
   debian-security-announce</a>
   list has a filter that only allows messages with a correct signature
   from one of the security team members to be posted.</p>

<p>Most likely some piece of mail software on your end slightly changes
   the message that breaks the signature. Make sure your software does
   not do any MIME encoding or decoding, or tab/space conversions.</p>

<p>Known culprits are fetchmail (with the mimedecode option enabled),
   formail (from procmail 3.14 only) and evolution.</p>

<toc-add-entry name="handling">How is security handled in Debian?</toc-add-entry>
<p>A: Once the security team receives a notification of an incident,
   one or more members review it and consider its impact on the stable
   release of Debian (i.e. if it's vulnerable or not).
   If our system is vulnerable, we work on a fix for the
   problem.  The package maintainer is contacted as well, if they didn't
   contact the security team already.  Finally, the fix is tested and
   new packages are prepared, which are then compiled on all stable
   architectures and uploaded afterwards.  After all of that is done,
   an advisory is published.</p>

<toc-add-entry name=oldversion>Why are you fiddling with an old version of that package?</toc-add-entry>

<p>The most important guideline when making a new package that fixes a
   security problem is to make as few changes as possible.  Our users and
   developers are relying 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 in case of libraries: make sure you never change the
   Application Program Interface (API) or Application Binary Interface (ABI),
   no matter how small the change is.</p>

<p>This means that moving to a new upstream version is not a good solution,
   instead the relevant changes should be backported.  Generally upstream
   maintainers are willing to help if needed, if not the Debian security team
   might be able to help.</p>

<p>In some cases it is not possible to backport a security fix, for example
   when large amounts of source code need to be modified or rewritten.  If that
   happens it might be necessary to move to a new upstream version, but this
   has to be coordinated with the security team beforehand.</p>

<toc-add-entry name=version>The version number for a package indicates that I am still running
   a vulnerable version!</toc-add-entry>
<p>A: Instead of upgrading to a new release we backport security fixes to
   the version that was shipped in the stable release. The reason we do
   this is to make sure that a release changes as little as possible
   so things will not change or break unexpectedly as a result of a
   security fix. You can check if you are running a secure version of
   a package by looking at the package changelog, or comparing its
   exact version number with the version indicated in the Debian
   Security Advisory.</p>

<toc-add-entry name=archismissing>I received an advisory, but the build for one
  processor architecture seems to be missing.</toc-add-entry>
<p>A: Generally the Security Team releases an advisory with builds of the updated
   packages for all architectures that Debian supports. However, some architectures
   are slower than others and it may happen that builds for most architectures
   are ready while some are still missing. These smaller archs represent a small
   fraction of our user base. Depending on the urgency of the issue
   we may decide to release the advisory forthwith. The missing builds will be
   installed as soon as they come available, but no further notice of this will
   be given. Of course we will never release an advisory where the i386 or amd64
   builds are not present.</p>

<toc-add-entry name=unstable>How is security handled for <tt>unstable</tt>?</toc-add-entry>
<p>A: Security for unstable is primarily handled by package maintainers, not
   by the Debian Security Team. Although the security team may upload
   high-urgency security-only fixes when maintainers are noticed to be
   inactive, support for stable will always have priority.
   If you want to have a secure (and stable) server you are strongly encouraged
   to stay with stable.</p>

<toc-add-entry name=testing>How is security handled for <tt>testing</tt>?</toc-add-entry>
<p>A: Security for testing benefits from the security efforts of the entire
   project for unstable. However, there is a minimum two-day migration delay,
   and sometimes security fixes can be held up by transitions. The Security
   Team helps to move along those transitions holding back important
   security uploads, but this is not always possible and delays may occur.
   Especially in the months after a new stable release, when many new versions
   are uploaded to unstable, security fixes for testing may lag behind.
   If you want to have a secure (and stable) server you are strongly
   encouraged to stay with stable.</p>

<toc-add-entry name=contrib>How is security handled for <tt>contrib</tt>,
  <tt>non-free</tt> and <tt>non-free-firmware</tt>?</toc-add-entry>
<p>A: The short answer is: it's not. Contrib, non-free and non-free-firmware aren't official
   parts of the Debian Distribution and are not released, and thus not
   supported by the security team. Some non-free packages are distributed
   without source or without a license allowing the distribution of modified
   versions. In those cases no security fixes can be made at all.  If it
   is possible to fix the problem, and the package maintainer or someone else
   provides correct updated packages, then the security team will generally
   process them and release an advisory.</p>

<toc-add-entry name=sidversionisold>The advisory says unstable is fixed in
  version 1.2.3-1, but unstable has 1.2.5-1, what's up?</toc-add-entry>
<p>A: We try to list the first version in unstable that fixed the problem.
   Sometimes the maintainer has uploaded even newer versions in the meantime.
   Compare the version in unstable with the version we indicate. If it's the
   same or higher, you should be safe from this vulnerability. If you want to
   be sure, you can check the package changelog with <tt>apt-get changelog
   package-name</tt> and search for the entry announcing the fix.</p>

<toc-add-entry name=mirror>Why are there no official mirrors for security.debian.org?</toc-add-entry>
<p>A: Actually, there are. There are several official mirrors, implemented
   through DNS aliases. The purpose of security.debian.org is to make security
   updates available as quickly and easily as possible.</p>

<p>Encouraging the use of unofficial mirrors would add extra complexity
   that is usually not needed and that can cause frustration if these
   mirrors are not kept up to date.</p>

<toc-add-entry name=missing>I've seen DSA 100 and DSA 102, now where is DSA 101?</toc-add-entry>
<p>A: Several vendors (mostly of GNU/Linux, but also of BSD
   derivatives) coordinate security advisories for some incidents and
   agree to a particular timeline so that all vendors are able to
   release an advisory at the same time.  This was decided in order to
   not discriminate some vendors that need more time (e.g. when the
   vendor has to pass packages through lengthy QA tests or has to
   support several architectures or binary distributions).  Our own
   security team also prepares advisories in advance.  Every now and
   then, other security issues have to be dealt with before the parked
   advisory could be released, and hence temporarily leaving out one or
   more advisories by number.
</p>

<toc-add-entry name=contact>How can I reach the security team?</toc-add-entry>

<p>A: Security information can be sent to security@debian.org or
   team@security.debian.org, both of which are read by the members of
   the security team.
</p>

<p>If desired, email can be encrypted with the Debian Security
   Contact key (key ID <a
   href="https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x0d59d2b15144766a14d241c66baf400b05c3e651">\
   0x0D59D2B15144766A14D241C66BAF400B05C3E651</a>). For the OpenPGP keys of individual team members, please
   refer to the <a href="https://keyring.debian.org/">keyring.debian.org</a>
   keyserver.</p>

<toc-add-entry name=discover>I guess I found a security problem, what should I do?</toc-add-entry>

<p>A: If you learn about a security problem, either in one of your own
   packages or in someone else's please always contact the security team.  If
   the Debian security team confirms the vulnerability and other vendors are
   likely to be vulnerable as well, they usually contact other vendors as
   well.  If the vulnerability is not yet public they will try to coordinate
   security advisories with the other vendors, so all major distributions are
   in sync.</p>

<p>If the vulnerability is already publicly known, be sure to file a bug
   report in the Debian BTS, and tag it <q>security</q>.</p>

<p>If you are a Debian maintainer, <a href="#care">see below</a>.</p>

<toc-add-entry name=care>What am I supposed to do with a security problem in one of
   my packages?</toc-add-entry>

<p>A: If you learn of a security problem, either in your package or
   someone else's please always contact the security team via email at
   team@security.debian.org. They keep track
   of outstanding security problems, can help maintainers with
   security problems or fix problems on their own, are responsible for
   sending out security advisories and maintaining
   security.debian.org.</p>

<p>The <a href="$(DOC)/developers-reference/pkgs.html#bug-security">\
   Developer's Reference</a> has complete instructions on what to do.</p>

<p>It's particularly important that you don't upload to any other
   distribution other than unstable without prior agreement by the
   security team, because bypassing them will cause confusion and more
   work.</p>

<toc-add-entry name=enofile>I tried to download a package listed in one of the security
   advisories, but I got a `file not found' error.</toc-add-entry>

<p>A: Whenever a newer bugfix supersedes an older package on
   security.debian.org, chances are high that the old package will be
   removed by the time the new one gets installed.  Hence, you'll get
   this `file not found' error.  We don't want to distribute packages
   with known security bugs longer than absolutely necessary.</p>

<p>Please use the packages from the latest security advisories, which are
   distributed through the <a
   href="https://lists.debian.org/debian-security-announce/">\
   debian-security-announce</a> mailing list. It's best to simply run
   <code>apt-get update</code> before upgrading the package.</p>

<toc-add-entry name=upload>I've got a bugfix, can I upload to security.debian.org directly?</toc-add-entry>

<p>A: No, you can't.  The archive at security.debian.org is maintained
   by the security team, who have to approve all packages.  You should
   instead send patches or proper source packages to the security team
   via team@security.debian.org.  They will be
   reviewed by the  security team and eventually uploaded, either with
   or without modifications.</p>

<p>The <a href="$(DOC)/developers-reference/pkgs.html#bug-security">\
   Developer's Reference</a> has complete instructions on what to do.</p>

<toc-add-entry name=ppu>I've got a bugfix, can I upload to proposed-updates instead?</toc-add-entry>

<p>A: Technically speaking, you can.  However, you should not do this,
   since this interferes badly with the work of the security team.
   Packages from security.debian.org will be copied into the
   proposed-updates directory automatically.  If a package with the
   same or a higher version number is already installed into the
   archive, the security update will be rejected by the archive
   system.  That way, the stable distribution will end up without a
   security update for this package instead, unless the <q>wrong</q>
   packages in the proposed-updates directory were rejected.  Please contact the
   security team instead and include all details of the vulnerability
   and attach the source files (i.e. diff.gz and dsc files) to your mail.</p>

<p>The <a href="$(DOC)/developers-reference/pkgs.html#bug-security">\
   Developer's Reference</a> has complete instructions on what to do.</p>

<toc-add-entry name=SecurityUploadQueue>I'm pretty sure my packages are fine,
   how can I upload them?</toc-add-entry>

<p>A: If you are very sure that your packages don't break anything, that the
   version is sane (i.e. greater than the version in stable and less than the
   version in testing/unstable), that you didn't change the behaviour of the
   package, despite the corresponding security problem, that you compiled it
   for the correct distribution (that is <code>oldstable-security</code> or
   <code>stable-security</code>), that the package contains the original
   source if the package is new on security.debian.org, that you can confirm
   the patch against the most recent version is clean and only touches the
   corresponding security problem (check with <code>interdiff -z</code> and
   both <code>.diff.gz</code> files), that you have proofread the patch at
   least thrice, and that <code>debdiff</code> doesn't display any changes,
   you may upload the files into the incoming directory
   <code>ftp://ftp.security.upload.debian.org/pub/SecurityUploadQueue</code> on the
   security.debian.org directly.  Please send a notification with all details
   and links to team@security.debian.org as well.</p>

<toc-add-entry name=help>How can I help with security?</toc-add-entry>
<p>A: Please review each problem before reporting it to
   security@debian.org.  If you are able to provide patches, that
   would speed up the process.  Do not simply forward bugtraq mails,
   because we already receive them &mdash; but do provide us with
   additional information about things reported on bugtraq.</p>

<p>A good way to get started with security work is helping
   out on the Debian Security Tracker (<a
   href="https://security-tracker.debian.org/tracker/data/report">instructions</a>).</p>

<toc-add-entry name=proposed-updates>What is the scope of proposed-updates?</toc-add-entry>
<p>A: This directory contains packages which are proposed to enter the
   next revision of Debian stable.  Whenever packages are uploaded by
   a maintainer for the stable distribution, they end up in the
   proposed-updates directory.  Since stable is meant to be stable, no
   automatic updates are made.  The security team will upload fixed
   packages mentioned in their advisories to stable, however they will
   be placed in proposed-updates first.  Every couple of months the
   Stable Release Manager checks the list of packages in
   proposed-updates and discusses whether a package is suited for
   stable or not.  This is compiled into another revision of stable
   (e.g. 2.2r3 or 2.2r4).  Packages that don't fit will probably be
   rejected and dropped from proposed-updates as well.
</p>

<p>Note that the packages uploaded by maintainers (not by the security team)
   in the proposed-updates/ directory are not supported by the security
   team.</p>

<toc-add-entry name=composing>How is the security team composed?</toc-add-entry>
<p>A: The Debian security team consists of
   <a href="../intro/organization#security">several officers and secretaries</a>.
   The security team itself appoints people to join the team.</p>

<toc-add-entry name=lifespan>How long will security updates be provided?</toc-add-entry>
<p>A: The security team will support a stable distribution for
   three years after its release. It is not possible to support three
   distributions; supporting two simultaneously is already difficult
   enough.
</p>

<toc-add-entry name=check>How can I check the integrity of packages?</toc-add-entry>
<p>A: This process involve checking the Release file signature against
   the <a href="https://ftp-master.debian.org/keys.html">\
   public key</a> used for the archive.  The Release file contains the
   checksums of Packages and Sources files, which contain
   checksums of binary and source packages.  Detailed instruction on how
   to check packages integrity can be found in the <a
   href="$(HOME)/doc/manuals/securing-debian-howto/ch7#s-deb-pack-sign">\
   Debian Securing Manual</a>.</p>

<toc-add-entry name=break>What to do if a random package breaks after a security update?</toc-add-entry>
<p>A: First of all, you should figure out why the package breaks and
   how it is connected to the security update, then contact the
   security team if it is serious or the stable release manager if it
   is less serious.  We're talking about random packages that break
   after a security update of a different package.  If you can't
   figure out what's going wrong but have a correction, talk to the
   security team as well.  You may be redirected to the stable release
   manager though.</p>

<toc-add-entry name=cvewhat>What is a CVE identifier?</toc-add-entry>
<p>A: The Common Vulnerabilities and Exposures project assignes
   unique names, called CVE identifiers, to specific security
   vulnerabilities, to make it easier to uniquely refer to a specific
   issue. More information can be found at <a
   href="https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures">\
   Wikipedia</a>.</p>

<toc-add-entry name=cvedsa>Does Debian issue a DSA for every CVE id?</toc-add-entry>
<p>A: The Debian security team keeps track of every issued CVE identifier,
   connect it to the relevant Debian package and assess its impact in a
   Debian context - the fact that something is assigned a CVE id does not
   necessarily imply that the issue is a serious threat to a Debian system.
   This information is tracked in the
   <a href="https://security-tracker.debian.org">Debian Security Tracker</a>
   and for the issues that are considered serious a Debian Security Advisory
   will be issued.</p>

<p>Low-impact issues not qualifying for a DSA can be fixed in the next
   release of Debian, in a point release of the current stable or oldstable
   distributions, or are included in a DSA when that is being issued for a
   more serious vulnerability.</p>

<toc-add-entry name=cveget>Can Debian assign CVE identifiers?</toc-add-entry>
<p>A: Debian is a CVE Numbering Authority and can assign ids, but per
   CVE policy only to yet-undisclosed issues. If you have an undisclosed
   security vulnerability for software in Debian and would like to get an
   identifier for it, contact the Debian Security Team. For cases where the
   vulnerability is already public, we advise to follow the procedure
   detailed in the <a
   href="https://github.com/RedHatProductSecurity/CVE-HOWTO">\
   CVE OpenSource Request HOWTO</a>.</p>

<toc-add-entry name=disclosure-policy>Does Debian have a vulnerability disclosure policy?</toc-add-entry>
<p>A: Debian has published a <a href="disclosure-policy">vulnerability
   disclosure policy</a> as part of its participation in the CVE
   program.

<toc-add-entry name=cve-severity-assessment>Our vulnerability management tool
   has shown that the following issues are open (list of CVEs with random CVSS
   scores). When are those going to be fixed?</toc-add-entry>
<p>A: Debian does not provide CVSS scores and doesn't use CVSS scores from
   external sources when triaging security issues.</p>
<p>You can check the state of every single CVE ID in the Debian Security Tracker by accessing
   it by <a href="https://security-tracker.debian.org/tracker/CVE-ID">ID</a>.</p>
<p>The "Notes" section will contain additional information, e.g. that a security issue doesn't
   warrant a Debian security update, but might get fixed in a subsequent point release.</p>
<p>A list of packages for which a Security update is planned can be found at the
<a href="https://salsa.debian.org/security-tracker-team/security-tracker/raw/master/data/dsa-needed.txt">\
   dsa-needed list</a>.</p>
<p>If you find an error in triage data, you're very welcome to report it. The Debian Security Team will
   however not generally react to requests asking for more specific information, you should instead contact
   the vendor of your vulnerability management tool, after all they are the ones who alerted you about a
   security issue and not Debian.</p>

<h1>Deprecated Debian security FAQ</h1>

<toc-add-entry name=localremote>What does <q>local (remote)</q> mean?</toc-add-entry>
<p><b>The field <i>Problem type</i> in DSA mails is not used since April 2014.</b><br/>
   A: Some advisories cover vulnerabilities that cannot be identified
   with the classic scheme of local and remote exploitability.  Some
   vulnerabilities cannot be exploited from remote, i.e. don't
   correspond to a daemon listening to a network port.  If they can be
   exploited by special files that could be provided via the network
   while the vulnerable service is not permanently connected with the
   network, we write <q>local (remote)</q> in such cases.</p>

<p>Such vulnerabilities are somewhat between local and remote
   vulnerabilities and often cover archives that could be provided
   through the network, e.g. as mail attachment or from a download
   page.</p>