- There are some situations where switching keyrings might be wanted,
especially as long as we dont export a way to pass keyring as
an argument to package reading/verification functions. Since thereäs
no technical reason to disallow it, might as well allow it...
- Loading the pubkeys from database numerous often unwanted side-effects,
if signature checking is disabled then there's no point loading
the keys either.
- Commit cad147070e did this for
rpmReadPackageFile() specifically but we really want it honored
for all operations including headerCheck() and friends, handle
it centrally in loadKeys() for simplicity.
- The pubkey headers have been rpm v3 all the way until now, whoops :)
Pull the actual key part of the header into immutable region and
stomp a sha1 digest on the result, allowing a (much) better
verification on loading. This part inspired by stumbling on a
related discussion on rpm5.org mailing list so credits where...
- Since we only insert either literally constant data or data retrieved
from the actual key into the immutable part of the header, the
calculated digest is constant for a given key regardless of where
and when it was imported. This gives some added verification and/or
cross-checking possibilities (eg was the imported key exactly the
same as what shipped etc)
- Create the header in makePubkeyHeader() as the name suggests,
return the newly created header to caller on success.
- Move the installtime & -tid addition to the "install" part,
makePubkeyHeader() only does the part that is specific to pubkey
headers, again as the name suggests.
- No functional changes
- Pubkey buildtime has until now been the time of import, which equals
install time/tid. Which is of course the time when that header
does get created, but it seems rather redundant to have the same
thing recorded in three places. Having the key creation time
easily (easier than un-hexifying the version string, duh)
available seems like a potentially useful thing. Buildtime is
"wrong" for this, but ... so is everything.
- With this change, the "meat" of the pubkey headers is now constant
and repeatable regardless of where and when a key gets imported,
so we could stomp a digest on it and it'd be unique for that
particular key everywhere.
- The userid has only been available in a mildly obfuscated format
through summary, but this seems like a useful thing to have in
a directly usable format without requiring callers to parse out
the gpg() wrapping around it.
- Yes its a wonky mapping, but so is everything else wrt
gpg-pubkeys, and adding a tag just for this also seems silly.
Using vendor tag could be another possibility, dunno.
- 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.
- Not all of these are at the end of local scope and in many cases
the iterator pointer is reused, but the logic in all these is
straightforward enough (no jumps etc) that there's no much
chance of mistakenly using already freed iterator.
- We'll probably want to make some changes to the plugin type system
before considered "ready", the current plugin slots are limited
to 32 and Meego folks apparently want to use a largish number
of slots. So we might want something like separate plugin type
(collection, security... etc) and then have 32 slots per each type.
Making this private for now to avoid having to potentially break
the API shortly after introduction.
- The actual indexes are rpmDbiTags, and the tag passed to
rpmtsInitIterator() and rpmdbInitIterator() always refers to a
database index, not arbitrary header tag. The tag passed to
rpmdbSetIteratorRE() however /does/ refer to a header tag. This rather
important distinction can actually be expressed in the API.
- As the indexes are generated from header tags of the same value,
most of these need to use the TagVal types instead of actual enums
to avoid mismatches - the value is what counts, not it being an enum.
- Several places still have variables misleadingly named "rpmtag" when
they refer to dbi tags, but leaving them for now to avoid excessive
changes at once.
- Transaction elements can only be of one type (hence the enum),
but the transaction set iteration permits selecting more than
one. Add a new typedef dummy for this purpose only.
- 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.
This replaces the old matchpathcon interfaces with the new selabel
interfaces for relabeling files, storing an selabel handle in the
transaction set.
With this change, also comes an added distinction between --nocontexts
being specified and a failure to read the load file contexts.
Previously, there was no distinction, and both cases used the
RPMTRANS_FLAG_NOCONTEXTS flag.
However, with the new policy plugin, it is necessary to make such a
distinction. This is because matchpathcon_init (now selabel interfaces)
can fail at the beginning of the transaction, but succeed later after
new policy is installed. Because of this, we may need to enable/disable
RPMTRANS_FLAG_NOCONTEXTS multiple times. However, because this flag
could also mean --nocontexts, we cannot do that. By storing the selabel
handle in the rpmts, we can easily keep track if the handle has been
successfully created, rather than overloading RPMTRANS_FLAG_NOCONTEXTS
with two meanings.
This moves most of the plugin logic to a new rpmplugins file with a
struct and functions for managing plugins, allowing for plugins to carry
state. This also adds init and cleanup hooks for plugins to initialize
and cleanup their state, and a new 'open te' hook allowing plugins to
read and save information from transaction elements.
This also generalizes the plugin architecture a bit so it isn't so
specific to collections.
- it never was anything more than a cached value of is_selinux_enabled()
and caching this fairly expensive result is no longer needed as
scriptlet execution wrt selinux contexts is now conditionalized on
RPMTRANS_FLAG_NOCONTEXTS instead
- On the principle of "no news is good news", if we already have the
keys to be imported, then everything is ok. The former behavior is
just confusing as witnessed in RhBug:462979
- the only meaningful way to create transaction elements is by adding things
to a transaction through rpmtsAddFooElement(), there's no need to
expose these and restrict our ability to change the API when needed
- BDB docs state that db->verify() doesn't perform any locking even
when used within an environment, and should only be used on files
that are not being modified by another thread of control. Grabbing
the transaction lock while verifying mostly ensures nobodys writing
to the db behind our back.
- Although it doesn't really happen in practise, rpm's API permits several
transactions with possibly differing roots within process lifetime.
Previously the lock path was calculated just once globally so we could
easily be locking in a completely wrong place (eg locking in a previously
accessed chroot when system rpmdb should be transaction-locked)
- Move transaction lock path handling into rpmts.c, export new low
level rpmlockAcquire() function to actually grab a lock
- Rename rpmtsFreeLock() to rpmlockFree() and return NULL in the
general rpm style
- for rpmdbRemove() these have been completely unused, and for rpmdbAdd()
the higher levels have had more than one chance of verifying the
header if checking is enabled in the transaction set
- get the debug messages out of API, this is what should've been in commit
dbdbe8010c - just wtf have I been thinking?
- also tolerate NULL passed to rpmtsLink() and rpmtsUnlink()
- Any problem found in transaction processing is caused, or at least
triggered by, some transaction element. Having the problems in
elements lets API users easily determine which package caused which
problem instead of having to parse problem strings in vain.
- No problem set stored in transaction set itself now, rpmtsProblems() API p
reserved by making it collect problems from our transaction elements
into a new set. The problem set fiddling in rpmtsRun() wrt %pretrans
and all is a bit crazy - always was, now its just more visible...
- Make rpmtsCheck() pass the associated transaction elements into
the lower level functions. rpmdsProblem() removed from API, it's
not particularly useful outside rpmtsCheck() internals.
- rpmts struct is now opaque within depends.c except for solve callback
- This breaks --badreloc, need to figure out something saner for the
problem filtering
Panu Matilainen