File README.SuSE of Package gpg

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/