[Secure-testing-commits] r37895 - doc/security-team.d.o
Salvatore Bonaccorso
carnil at moszumanska.debian.org
Wed Nov 25 16:29:08 UTC 2015
Author: carnil
Date: 2015-11-25 16:29:07 +0000 (Wed, 25 Nov 2015)
New Revision: 37895
Modified:
doc/security-team.d.o/security_tracker
Log:
Cleanup trailing whitespaces
Modified: doc/security-team.d.o/security_tracker
===================================================================
--- doc/security-team.d.o/security_tracker 2015-11-25 16:29:05 UTC (rev 37894)
+++ doc/security-team.d.o/security_tracker 2015-11-25 16:29:07 UTC (rev 37895)
@@ -1,12 +1,12 @@
[TOC]
-# Debian Security Tracker
+# Debian Security Tracker
About
-----
Everything in the [Debian Security Tracker](https://security-tracker.debian.org/) is publicly available, as in
-"[Debian doesn't hide problems](https://www.debian.org/social_contract)" available.
+"[Debian doesn't hide problems](https://www.debian.org/social_contract)" available.
The best thing about our tracking *system* is that it is very basic.
There is no horrible overhead of web-based ticket/issue trackers, it's
@@ -20,7 +20,7 @@
--------------------
The following will give you a basic walkthrough of how the files are
-structured, and how we do our work while tracking issues.
+structured, and how we do our work while tracking issues.
The best way to understand is to check out our repository from
Subversion so you have the files on your computer and can follow along
@@ -97,17 +97,17 @@
Processing `TODO` entries means checking if the problem affects Debian and
if so which packages, as well as evaluate their severity. This information
is based on *research* and not just in the CVE description in order to
-prevent integrating false positives or incorrect data in the security
-tracker. For example, if the CVE id says that something is
-vulnerable prior to version X, you need to check if that is
-the case as well as for the information given on
-distribution specific issues. Always make sure you understand the
+prevent integrating false positives or incorrect data in the security
+tracker. For example, if the CVE id says that something is
+vulnerable prior to version X, you need to check if that is
+the case as well as for the information given on
+distribution specific issues. Always make sure you understand the
issue and are able to verify that the information is correct.
-Thus, a proper research should include reading the code, finding
+Thus, a proper research should include reading the code, finding
fixes/commits in the upstream repository, or even writing
-patches yourself if you have the time and skills to do that. If you
-can't assure that, please add a `TODO` entry reflecting what is
+patches yourself if you have the time and skills to do that. If you
+can't assure that, please add a `TODO` entry reflecting what is
missing from your research. Check the section [`NOTE` and `TODO`
entries](#note-and-todo-entries) for more details.
@@ -144,16 +144,16 @@
if the product has an ITP or RFP (see [ITP/RFP packages](#issues-in-itp-andor-rfp-packages) below)
- Search the [ftp-master removal list](https://ftp-master.debian.org/removals-full.txt)
or the [Package Tracking System](https://packages.qa.debian.org/) to see if the
- package was present in the past but was removed (see [Removed
+ package was present in the past but was removed (see [Removed
packages](#removed-packages) below)
If there is any doubt, add a `NOTE` with your findings and/or ask others to
double check using `TODO` (see [`NOTE` and `TODO` entries](#note-and-todo-entries) below).
-There is a tool that helps with sorting out all the NOT-FOR-US issues:
-`bin/check-new-issues -h`. For the search functions in
-check-new-issues to work, you need to have unstable in your
-sources.list and have done `apt-get update` and `apt-file update`.
+There is a tool that helps with sorting out all the NOT-FOR-US issues:
+`bin/check-new-issues -h`. For the search functions in
+check-new-issues to work, you need to have unstable in your
+sources.list and have done `apt-get update` and `apt-file update`.
Having libterm-readline-gnu-perl installed helps, too. If you are not
running unstable, you can search at [https://packages.debian.org](https://packages.debian.org) or
set up an [unstable chroot](https://www.debian.org/doc/manuals/reference/ch09#_chroot_system).
@@ -173,8 +173,8 @@
- gallery 1.5-2 (medium)
Even if the CVE description mentions it is fixed as of a particular
-version, double-check the Debian package yourself (because sometimes
-the CVE descriptions or information from databases like Secunia is
+version, double-check the Debian package yourself (because sometimes
+the CVE descriptions or information from databases like Secunia is
incorrect).
If it hasn't been fixed, we determine if there has been a bug filed
@@ -187,16 +187,16 @@
Bug numbers can be added as in the example above. To avoid duplicate bugs,
`bug filed` can be added instead of `bug #123456` when the bug report has
-been sent but the bug number is not yet known (however, it is more
-desirable to file the bug, wait for the BTS to assign a number, then update
+been sent but the bug number is not yet known (however, it is more
+desirable to file the bug, wait for the BTS to assign a number, then update
the entry in the CVE list so that complete information is always available
in the tracker). The bug number is important because it makes it clear
-that the maintainer has been contacted about the problem, and that they are
+that the maintainer has been contacted about the problem, and that they are
aware of their responsibility to work swiftly toward a fix.
Since CVEs often drop in bulk, submission of multiple CVEs in a single bug
-report is permissible and encouraged. However, some maintainers have
-indicated a preference for only one issue per bug report. The following
+report is permissible and encouraged. However, some maintainers have
+indicated a preference for only one issue per bug report. The following
is a list of packages for which each CVE should be reported separately:
- php5
@@ -230,7 +230,7 @@
set of proactive maintainers paying attention to these information
sources. Getting the maintainer involved hopefully prompts faster
fixes. This also allows enables tracking of multiple packages, some
-of which may already be fixed.
+of which may already be fixed.
`<undetermined>` can also be used when there simply is not enough
information disclosed in the existing known references about the
@@ -254,13 +254,13 @@
ideal way to help/contribute).
### Packages in Experimental only
-There are some packages that only exists in experimental. In that
+There are some packages that only exists in experimental. In that
case, place the distribution tag `experimental`. For example:
CVE-2013-1067 (Apport 2.12.5 and earlier uses weak permissions for core dump files ...)
[experimental] - apport 2.12.6-1 (bug #727661)
-If the package is in unstable *and* in experimental, focus on unstable (we are
+If the package is in unstable *and* in experimental, focus on unstable (we are
not tracking fixes in experimental). A note about the situation in experimental
is appreciated though. For example:
@@ -354,7 +354,7 @@
TODO: check, whether fastjar from the gcc source packages is affected
If you are not sure about some decision (e.g., which package is affected) or
-triaging (e.g., bug severity) you can leave a TODO note for reviewing,
+triaging (e.g., bug severity) you can leave a TODO note for reviewing,
explaining which aspect have to be reviewed. For example:
CVE-2013-7295 (Tor before 0.2.4.20, when OpenSSL 1.x is used in ...)
@@ -380,7 +380,7 @@
These levels are mostly used to prioritize the order in which security
problems are resolved. Anyway, we have a rough overview on how you should
-assess these levels.
+assess these levels.
**unimportant**: This problem does not affect the Debian binary package, e.g.,
a vulnerable source file, which is not built, a vulnerable file
@@ -407,7 +407,7 @@
like to fix or at least implement a workaround. This could
be because the vulnerable code is very broadly used, because
an exploit is in the wild or because the attack vector is
- very wide.
+ very wide.
Should be put into that category anything that permits an attacker
to execute arbitrary code on the vulnerable system (with or
without root privileges) and high-impact denial-of-service bugs
@@ -543,7 +543,7 @@
------------------------
After thoroughly researching each issue (as described above) and editing
-the relevant files, commit your changes. Peer review is (hopefully) done via the
+the relevant files, commit your changes. Peer review is (hopefully) done via the
mailing list and IRC notifications (see [Automatic issue updates](#automatic-issue-updates) above).
However, changes to the tracker website itself (e.g., the files in lib/*
and bin/tracker_service.py) should be vetted and approved before being
More information about the Secure-testing-commits
mailing list