Cleanup trailing whitespaces

git-svn-id: svn+ssh://svn.debian.org/svn/secure-testing@37895 e39458fd-73e7-0310-bf30-c45bca0a0e42

1 files changed, 30 insertions, 30 deletions

diff --git a/doc/security-team.d.o/security_tracker b/doc/security-team.d.o/security_tracker
index f27983d0d4..804e066f01 100644
--- a/doc/security-team.d.o/security_tracker
+++ b/doc/security-team.d.o/security_tracker
@@ -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 @@ Gentle Introduction
 --------------------
 
 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 @@ depending on how many new issues have been assigned by MITRE.
 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 @@ Before marking a package NFU, the following should be done:
       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 @@ example:
             - 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 @@ about the issue, and if not, file one and then note it in the list
 
 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 @@ output of debsecan and on the PTS pages, which is useful for the small
 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 @@ you're also fixing the issue in the process, which is of course the
 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 @@ descriptive so that it is clear what remains to be done. For example:
             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 @@ Severity levels
 
 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 @@ assess these levels.
              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 @@ Checking in your changes
 ------------------------
 
 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