File README.SuSE of Package gpg1
README for the GnuPG package from SuSE -------------------------------------- The gpg binary is installed setuid root by default. This allows GnuPG to use mlock() to prevent the pages that contain your secret key to be swapped out to disk. SUSE has moved the allocation of the secure memory to an earlier stage in GnuPG, so that it happens before option processing. After this, gpg drops all privileges, so this setup is safe. Version info ------------ Since version 1.2.2-rc1, GnuPG is accompanied by a convert-from-106 script that facilitates the transition from the old (GnuPG-1.0.6 and earlier) trustdb and keyring format into the new one (GnuPG-1.0.7/1.2.x). It's installed at /usr/bin/gpg-convert-from-106. Probably you've heard about a weakness in the OpenPGP format. This spec. does specify how to store the secret key in an encrypted and passphrase (mantra) protected way. If somebody has write access to your secret keyfile and modifies it in a subtle way, your gpg won't detect this and the next time you send a signed mail, the attacker may gain valuable information about your secret key, allowing him to find it. So, don't store your secret keyring in a non-trusted environment just relying on the passphrase protection! However, when this attack is carried out, the signature made with the modified key is invalid. Version 1.0.5 of gpg and higher does detect this and will not silently send out such mails. Read the file NEWS to find out about other changes. There has been some parser vulnerability in gpg-1.2.x in the external gpgkeys_hkp module. It has been fixed in our 1.2.x updates and in 1.2.3. The ElGamal _signature_ keys (type 20, capital letter G) are subject to a cryptographic attack and the private key can be computed with low effort. Thus all ElGamal keys used for signatures should be considered compromised and should be revoked. Note that this does _not_ affect encryption only Elgamal keys (type 16, lowercase g). Normally, GnuPG would not generate keys of type 20, unless you specifically requested it to do so. This ability has been removed in our 1.2.x updates and in 1.2.4. Translations ------------ Checking the translation files (.po files), a number of mistakes has been found and corrected. However, probably not all mistakes have been found, so it may well be that some translations are unclear or wrong. In the worst case, parameter formatting (%) is wrong and cause the gpg program to segfault. Therefore, we recommend running gpg with LC_ALL=en_US (or LANG=en_US) to avoid those problems. If you don't want to change your locale environment for gpg, you may as well delete the offending translations from /usr/share/locale/XX/LC_MESSAGES/gnupg.mo (XX = locale/language). Your SuSE team http://www.suse.com/feedback/
