remove a lot of files which are not translations but only copies of the english version

1 files changed, 0 insertions, 389 deletions

diff --git a/greek/security/faq.wml b/greek/security/faq.wml
deleted file mode 100644
index 23aaef3fa6b..00000000000
--- a/greek/security/faq.wml
+++ /dev/null
@@ -1,389 +0,0 @@
-#use wml::debian::template title="Debian security FAQ"
-#include "$(ENGLISHDIR)/security/faq.inc"
-#use wml::debian::translation-check translation="1fe91e1ee0d4350b235e726f3f93da47d0639b19" maintainer="galaxico"
-
-<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> and
-  <tt>non-free</tt>?</toc-add-entry>
-<p>A: The short answer is: it's not. Contrib and non-free 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 PGP/GPG 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 tries to support a stable distribution for
-   about one year after the next stable distribution has been
-   released, except when another stable distribution is released
-   within this year.  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.
-
-<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>
-