The OpenPGP time fields are unsigned four-octet numbers, storing
it as the uint32_t it actually is makes using the value that
little bit saner.
Way too many places to update as we still have no API for this, sigh.
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...
Previously provides contained only ID of main gpg key. Now they
contains ID of main key and also IDs of subkeys. You can list all
keys of some gpg package with:
rpm --provides -q gpg-pubkey-...
pgpPrtParamSubkeys() parses gpg packets to get gpg subkeys parameters.
rpmGetSubkeys() uses pgpPrtParamSubkeys() and it creates rpmPubkey
objects that can be insterted into rpm keyring.
- Turns out "destroying the object and release any resources used by the
lock" does not include *unlocking* the lock. How silly of me to think
it would...
- Keys are basically immutable and generally owned by the keyring
which doesn't currently doesn't expose anything about the keys
it owns... so there isn't perhaps that much need for locking,
except for keeping reference counts sane. Under that assumption
the keys are not locked from within keyring lookup and signature
verification, as it'd seem the keyring locking is sufficient
to keep our keys around during them. Just as well there might
be holes in this theory but gotta start someplace...
- While we're mostly interested in very limited thread-safety
where objects need to be kept private to the owning thread, being
able to share the keyring (from transaction set) seems desireable,
so lets try at least...
- Try to keep things as simple as possible: grab locks at the outer
level functions, dont bother optimizing for write-lock avoidance
in corner cases etc.
- Having a helper function to decrement an integer seems a bit much,
but mostly this is preparing for thread protection where the
unlink-helpers would just get in the way.
- Having a helper function to decrement an integer seems a bit much,
but mostly this is preparing for thread protection where the
unlink-helpers would just get in the way.
- Base64 is present in headers and all, it's only reasonable that
our API users have access to this functionality without having
to link to other libraries. Even if we didn't want to carry the
implementation forever in our codebase, we should provide a wrapping
for this (much like the other crypto stuff) for the reason stated above.
- A bigger issue is that our dirty little (badly hidden) secret was using
non-namespaced function names, clashing with at least beecrypt. And we
couldn't have made these internal-only symbols even on platforms that
support it, because they are used all over the place outside rpmio.
So... rename the b64 functions to rpmLikeNamingStyle and make 'em public.
No functional changes, just trivial renaming despite touching numerous
places.
- At least within rpm itself, callers aren't particularly interested
in the actual key that matches a given signature, they just want
simple good/bad/nokey answers. This makes life simple for them
and avoids exposing further rpmPubkey internals through APIs.
- Document the broken rpmKeyringLookup() behavior / side-effect,
the new helper uses the values from our stored pgp parameters though.
- Shouldn't make any difference functionality-wise, but we'll need
the helper function shortly.
- Yet more pre-requisites for separating key and signature management.
In addition this gains us more thorough initial sanity checking and
will allow reusing the parameters instead of having to parse
the same packets over and over again on every single verification
against this key. Unfortunately rpmKeyringLookup() is so braindead
it prevents us from doing this right now, we'll need a better
interface to take advantage of the stored pgp key parameters.
- Besides eliminating a couple of direct struct accesses,
pgpDigParamsCmp() does a much more thorough job of comparing
the parameters than we ever did here (ie less chance for returning
ok for for a wrong key, although because the interface is as
braindead as it is, it doesn't make a whole lot of difference)
- These are internal helpers only, all refcount users need to use
fooFree() or similar for correct operation. Add fwd declarations
where necessary to avoid moving code around unnecessarily.
- We could add these back later as aliases to fooFree() but for now,
just get them out of the way.
- keep keyring sorted by keyid, use bsearch for key lookups
- check for key in keyring before adding it to avoid dupes
- actually check that pubkey parameters match the signature on keyring
lookup like was done in rpmtsFindPubkey()
- in librpmio to avoid dependencies on higher level stuff
- for now it's just an in-memory structure that needs to be populated
by someone simply by feeding in GPG public keys
Panu Matilainen