diff options
author | Thomas Lange <lange@debian.org> | 2023-10-06 12:45:37 +0200 |
---|---|---|
committer | Thomas Lange <lange@debian.org> | 2023-10-06 12:45:37 +0200 |
commit | 9f5b551837a8d4c6a8c9346cf4c44755b863a813 (patch) | |
tree | 0856db540a5d047169c7b6513e04d38306bff237 /greek/security | |
parent | 794834c196b3285bb39846e22bfab051860258ab (diff) |
remove a lot of files which are not translations but only copies of the english version
Diffstat (limited to 'greek/security')
-rw-r--r-- | greek/security/faq.wml | 389 |
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 — 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> - |