1 files changed, 0 insertions, 167 deletions

diff --git a/debian/README.compromised-keys b/debian/README.compromised-keys
deleted file mode 100644
index 7a9cb7657..000000000
--- a/debian/README.compromised-keys
+++ /dev/null
@@ -1,167 +0,0 @@
-The following instructions relate to CVE-2008-0166. They were prepared by
-Matt Zimmerman, assisted by Colin Watson.
-
-== What Happened ==
-
-A weakness has been discovered in the random number generator used by OpenSSL
-on Debian and Ubuntu systems.  As a result of this weakness, certain encryption
-keys are much more common than they should be, such that an attacker could
-guess the key through a brute-force attack given minimal knowledge of the
-system.  This particularly affects the use of encryption keys in OpenSSH,
-OpenVPN and SSL certificates.
-
-This vulnerability only affects operating systems which (like Ubuntu) are based
-on Debian.  However, other systems can be indirectly affected if weak keys are
-imported into them.
-
-We consider this an extremely serious vulnerability, and urge all users to act
-immediately to secure their systems.
-
-== Who is affected ==
-
-Systems which are running any of the following releases:
-
- * Debian 4.0 (etch)
- * Ubuntu 7.04 (Feisty)
- * Ubuntu 7.10 (Gutsy)
- * Ubuntu 8.04 LTS (Hardy)
- * Ubuntu "Intrepid Ibex" (development): libssl <= 0.9.8g-8
-
-and have openssh-server installed or have been used to create an OpenSSH key or
-X.509 (SSL) certificate.
-
-All OpenSSH and X.509 keys generated on such systems must be considered
-untrustworthy, regardless of the system on which they are used, even after the
-update has been applied.
-
-This includes the automatically generated host keys used by OpenSSH, which are
-the basis for its server spoofing and man-in-the-middle protection.
-
-The specific package versions affected are:
-
- * Debian 4.0: libssl <= 0.9.8c-4etch3
- * Ubuntu 7.04: libssl <= 0.9.8c-4ubuntu0.2
- * Ubuntu 7.10: libssl <= 0.9.8e-5ubuntu3.1
- * Ubuntu 8.04: libssl <= 0.9.8g-4ubuntu3
-
-== What to do if you are affected ==
-
-OpenSSH:
-
-1. Install the security updates
-
-   Once the update is applied, weak user keys will be automatically rejected
-   where possible (though they cannot be detected in all cases).  If you are
-   using such keys for user authentication, they will immediately stop working
-   and will need to be replaced (see step 3).
-   
-   OpenSSH host keys can be automatically regenerated when the OpenSSH security
-   update is applied.  The update will prompt for confirmation before taking
-   this step.
-   
-2. Update OpenSSH known_hosts files
-
-   The regeneration of host keys will cause a warning to be displayed when
-   connecting to the system using SSH until the host key is updated in the
-   known_hosts file.  The warning will look like this:
-
-   @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
-   @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
-   @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
-   IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
-   Someone could be eavesdropping on you right now (man-in-the-middle attack)!
-   It is also possible that the RSA host key has just been changed.
-
-   In this case, the host key has simply been changed, and you should update
-   the relevant known_hosts file as indicated in the error message.
-
-3. Check all OpenSSH user keys
-
-   The safest course of action is to regenerate all OpenSSH user keys,
-   except where it can be established to a high degree of certainty that the
-   key was generated on an unaffected system.
-
-   Check whether your key is affected by running the ssh-vulnkey tool, included
-   in the security update.  By default, ssh-vulnkey will check the standard
-   location for user keys (~/.ssh/id_rsa, ~/.ssh/id_dsa and ~/.ssh/identity),
-   your authorized_keys file (~/.ssh/authorized_keys and
-   ~/.ssh/authorized_keys2), and the system's host keys
-   (/etc/ssh/ssh_host_dsa_key and /etc/ssh/ssh_host_rsa_key).
-
-   To check all your own keys, assuming they are in the standard
-   locations (~/.ssh/id_rsa, ~/.ssh/id_dsa, or ~/.ssh/identity):
-
-     ssh-vulnkey
-
-   To check all keys on your system:
-
-     sudo ssh-vulnkey -a
-
-   To check a key in a non-standard location:
-
-     ssh-vulnkey /path/to/key
-
-   If ssh-vulnkey says "Unknown (no blacklist information)", then it has no
-   information about whether that key is affected.  If in doubt, destroy the
-   key and generate a new one.
-
-4. Regenerate any affected user keys
-
-   OpenSSH keys used for user authentication must be manually regenerated,
-   including those which may have since been transferred to a different system
-   after being generated.
-
-   New keys can be generated using ssh-keygen, e.g.:
-
-   $ ssh-keygen 
-   Generating public/private rsa key pair.
-   Enter file in which to save the key (/home/user/.ssh/id_rsa): 
-   Enter passphrase (empty for no passphrase): 
-   Enter same passphrase again: 
-   Your identification has been saved in /home/user/.ssh/id_rsa.
-   Your public key has been saved in /home/user/.ssh/id_rsa.pub.
-   The key fingerprint is:
-   00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 user@host
-
-5. Update authorized_keys files (if necessary)
-
-   Once the user keys have been regenerated, the relevant public keys must
-   be propagated to any authorized_keys files on remote systems.  Be sure to
-   delete the affected key.
-
-OpenSSL:
-
-1. Install the security update
-
-2. Create new certificates to replace any server or client certificates in use
-   on the system
-
-3. If certificates have been generated for use on other systems, they must be
-   found and replaced as well.
-
-== Removing openssh-blacklist ==
-
-For the moment, the openssh-server package depends on openssh-blacklist, in
-order that the blacklist is deployed to the maximum possible number of
-systems to reduce the potential spread of worms exploiting this
-vulnerability. We acknowledge that this may be inconvenient for some small
-systems, but nevertheless feel that this was the best course of action.
-
-If you absolutely need to remove the blacklist from your system, then you
-can run the following commands to substitute a fake package for
-openssh-blacklist:
-
-  sudo apt-get install equivs
-  equivs-control openssh-blacklist.ctl
-  sed -i 's/^Package:.*/Package: openssh-blacklist/' openssh-blacklist.ctl
-  sed -i 's/^# Version:.*/Version: 9:1.0/' openssh-blacklist.ctl
-  equivs-build openssh-blacklist.ctl
-  sudo dpkg -i openssh-blacklist_1.0_all.deb
-
-Be warned: this circumvents a security measure for the sake of disk space.
-You should only do this if you have no other option, and if you are certain
-that no compromised keys will ever be generated on or copied onto this
-system.
-
-Once a sufficient amount of time and number of releases have passed, the
-openssh-blacklist package will be phased out.