Originally introduced in commit f5203aea8b
in 2004, pgpPubkeyFingerprint() has been returning the 64 bits long
Key ID from the tail of 160 bits long fingerprint, not the actual
fingerprint.
Add a new public API for retrieving the Key ID specifically, adjust
the handful of internal users to use it and make pgpPubkeyFingerprint()
return the actual fingerprint. It's an API break sure but there are
unlikely to be any callers outside rpm and we're breaking the API + ABI
left and right in this release so doesn't matter...
The sole user within rpm was removed over six years ago, never seen
a single user outside rpm, and even then it's just a wrapper around
rpmBase64Decode() and pgpPubkeyFingerprint() with a bizarre
return code. Bye bye...
Change the way individual digests within bundles are stored and accessed:
Previously the digest algo number was used directly as the index into
the bundle. Which works, but limits you to a single digest per algo,
and the array is likely to be rather sparse. To address both issues, use
an arbitrary integer ID to address the digests and always add new
digests in the first available slot. And yes the implementation is
a bit simplistic and taking some shortcuts, but so was the previous one.
Abstracting out the actual algorithm allows using eg rpm tag values
as the identifier, and also makes it possible to do multiple digests
of the same type on overlapping ranges. This is entirely backwards
compatible however if you simply use algorithm number also as the id,
so callers *need* to be updated.
pgpPrtParamSubkeys() parses gpg packets to get gpg subkeys parameters.
rpmGetSubkeys() uses pgpPrtParamSubkeys() and it creates rpmPubkey
objects that can be insterted into rpm keyring.
- pgpPrtParams() returns a pointer to an allocated pgpDigParams
on success, eliminating the need for callers to worry about
freeing "target buffer" on failure and bypassing the now rather
useless pgpDig middleman. Also allows specifying the expected
packet type so if we expect a key we'll error out if we get a signature
instead.
- pgpPrtPkts() is basically just a wrapper to pgpPrtParams()
- Further pre-requisites for separating key and signature management.
- Yes, pgpPrtParams() is a stupid name for this. However all the saner
ones are already taken for other purposes (for which the names are
just as bad/misleading, sigh)
- pgpVerifySig() is now just a dumb wrapper around pgpVerifySignature()
which does the real work.
- Update the sole caller to use the new interface instead, deprecate
the old dig interface.
- First steps towards getting rig of pgpDig which always was a
strange creature and now is nothing but a nuisance and obfuscation.
Yes keys and signatures walk hand in hand much of the time, but
they come from different sources and want to be handled as
separate data really.
- pgpLen() only works for new format packets, and even for those
its unsafe and cannot be fixed without breaking the API. Start
by taking it behind the barn for further, err, operations. Rpm has
no users outside rpmpgp.c now and anybody else using it will be
better off not doing so.
- While its use would seem kinda obvious here, in rpm context this
information often comes from header tags which are plain integers
and would require conversion/casting to the enum. What matters is
the integral value, not it being actual enum.
- Enums are fine for defining the bitfield flags, but the bitfield
itself is not an enumeration. Add a separate typedef on "rpmFlags"
type (presenting a bitfield of flags) for all of these. Compilers
hardly care, but the typedefs give a nice visual clue for
us humans using these flags far away from ho^H^H definitions.
- The equivalent used to be possible in 4.4.x era as the value tables
were all exported, but this way we need to export far less
and the implementation details stay internal.
- new pgpVerifySig() call to perform the lowlevel verify, use for
verifying DSA/RSA signatures
- librpm is now free of NSS specifics (apart from what still leaks through
including rpmio/digest.h), remove linkage
- in various places we need to calculate different digests of the same
data, having them stored in a single container makes managing easier
- can hold as many digest types as we support
- remembers how much input data it has handled
- build-time generated rpmints.h causes issues with distcheck and is
not really worth the trouble
- we have all sorts of legacy junk to deal with, sticking them all into
rpmints.h would be just wrong...
- use rpm_tag_t for signature tag types too
- size_t, not rpm_count_t in signature generation
- add couple of explicit casts to rpmpgp.h to avoid spurious noise from
inlined functions
Till Maas