Simplifies the code a lot. Also check that that there's room for the
mpi len before calling pgpMpiLen().
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
- Almost nothing works if crypto fails to initialize for whatever reason,
check and propagate rpmInitCrypto() failure from rpmReadConfigFiles().
- Logging the error left for individual crypto backends to let them
identify themselves: beecrypt requires no initialization whatsoever
so it cannot fail at all, but NSS can fail in a number of entertaining
ways due to missing dlopen()'ed bits and pieces, this should help
avoiding wild-goose chases in such cases (RhBug:909627, RhBug:909618...)
- DSA2 signatures are not fixed-length so we need to calculate the
number of bits and bytes (quite literally) from the data we get.
Unfortunately it seems DSA2 in NSS 3.14 is slightly buggy (mixup
wrt bytes and bits in DSA2 keysize in its verification internals),
preventing this from actually working with that version.
- Prior to this, rpm would report "unverifiable signature" on DSA2,
with NSS 3.14 it'll now report signature as BAD, once NSS is fixed
it should "just work".
- SHA224-support was added around NSS 3.13, dont break compilation
with older versions just for this rarely used hash.
- HASH_AlgSHA224 is an enum so test for SHA224_LENGTH define instead
- VFY_VerifyDigest() has been deprecated since NSS >= 3.12 and for
a good reason too: with VFY_VerifyDigest() caller needs to painfully
enumerate every possible supported enc + hash combination, only for
NSS to revert the process. Use the saner VFY_VerifyDigestDirect()
interface instead and test for its presence in configure.
- This means we now require NSS >= 3.12 but as that's already 4.5 years
old and included in ancient beasts like RHEL-4, this doesn't seem
exactly unreasonable requirement. And then there's always beecrypt...
- NSS >= 3.14 introduces support for DSA2 and marks DSA_SUBPRIME_LEN
as deprecated. Use explicit DSA1_SUBPRIME_LEN (we only support DSA1
for now) instead where available, add compatibility define for
older versions.
- Also directly include <blapit.h> where its defined - blabit.h gets
included via cryptohi.h but being explicit about it avoids having
to redefine it again "just in case".
- Older NSS versions operate on global context, which can cause
all sorts of trouble when an API user tries to use NSS for their
own purposes: eg they might want to use NSS databases which is not
possible once we've initialized NSS with NSS_NoDB_Init(). Further
background on the subject at https://wiki.mozilla.org/NSS_Library_Init
- Use private private NSS context when possible (NSS >= 3.12.5) to
avoid such clashes, but keep support for older versions for now.
- Not everybody needs/wants the certified monster that NSS is
(along with all its quirks), this leaves room for alternative
compile-time selectable crypto backends. Besides that, we get
a clean functionality separation for the PGP parser and the
cryptography parts.
- The whole crypto abstraction works inspired + somewhat based on
Michael Schroeder's similar patch in Suse, kudos.
- TODO: port beecrypt support from Suse to the new interface.
Panu Matilainen