Turn rpmVerifyFile() into indexed rpmfilesVerify() method but
drop the unnecessary double return code which also "fixes" the
oddball argument order where return value is not last, add
thin wrapper for rpmfi iteration. Mark rpmVerifyFile() deprecated
due to the strange calling conventions and unused arguments.
Leaving the code in verify.c to make it clearer what changed, looks
a bit out of place but doesn't matter as it doesn't need access
to rpmfi(les) internals.
Verification functionality as such is supposed to be unchanged by this.
rpmfiDecideFate() and rpmfiConfigConflict() should've never been
public in the first place, they're only meaningful to the transaction
internals really. rpmfiMD5() hasn't been adequate for the task
since 2008 or so, enough is enough.
This patch adds file signatures and file signature length to rpmfiles.
These new members are set in rpmfilesPopulate, and they can be accessed
with rpmfiFSignature.
Changelog:
- simplified logic in rpmfilesPopulate
- removed empty line
Signed-off-by: Lubos Kardos <lkardos@redhat.com>
- rpmfiles API is mostly a copy-paste of rpmfi with index argument
added
- clarify rpmfi.h docs to speak about "file info set iterator",
rpmfiles.h is the "file info set" thing now
- All the public rpmfiFoo() accessors have an indexed rpmfilesFoo()
counterpart, make the rpmfiles-versions public too.
- The noteworty exceptions are rpmfiDecideFate() and rpmfiConfigConflict()
which shouldn't have been public in the first place, and are to be
removed from the API in the next API break. So we're not adding
new rpmfiles-counterparts for functions that are to be removed
from the (public) API. Actually document the issue by deprecating
both rpmfi-functions.
- The iterator types need to be in rpmfiles.h as the iterator
constructor is there (otherwise there'd be a cyclic include
between rpmfiles.h and rpmfi.h, which wont do...)
- Preparation for making the indexed rpmfiles API public, API users
are not affected as rpmfiles.h is included from rpmfi.h now. rpmfi.h
is for the iterator part only.
- Especially rpmfiOFN() and its underlying buffer is more than a bit
dubious, but can't really help it as people are going to expect
it behaving identically to rpmfiFN(). And they can't share the
same buffer as somebody is going to be tempted to do eg
if (strcmp(rpmfiFN(fi), rpmfiOFN(fi)))
/* file has been relocated */
- Based on ffesti's original work on the subject
- Similar as commit 541234b02e for rpmds,
but speed is less of an issue with the complex rpmfi's than single
rpmds'es where private pool construct+teardown can be very expensive.
With rpmfi's the bigger gain from shared pools is memory savings,
permit taking advantage of this outside librpm internals.
- Introduce rpmFileActionFlags enumeration for carrying additional
flags associated with a rpmFileAction. For now the only flag
is "unowned", more are to follow later.
- Add new rpmFsmOp type which is a combination of rpmFileAction
and rpmFileActionFlags + macros to get the action and flags halfs.
- Creating new types instead of just sticking them at the upper half of
rpmFileAction to allow indicating the type of data to be expected
in the API. For now this stuff is solely for the benefit of plugins so
hiding them in the non-public rpmplugins.h header until the
situation clears up and stabilizes: rpmFileAction is a funky mix of
what should be separate enumerations (eg state and action) + flags,
but to avoid having to change all that at once...
- In the package/transaction related things the strpool is more of
an internal implementation detail than an end-goal in itself, move
string pool related interfaces of rpmts, rpmfi and rpmds to
internal-only APIs for now. The kind interfaces we'll want to eventually
export a) dont exist yet and b) are likely to be something very different.
- The string pool itself remains exported however, its a handy data
structure for all sorts of things and both librpm and librpmbuild
heavily use it already.
- RPMFILE_EXCLUDE only exists during spec parse, and doesn't "leak"
into headers only because the file is, well, excluded to start with.
Unexport the internal-only bit and explicitly strip out any excess
bits from data going to header. The current 16/16 split is artificial
of course, RPMTAG_FILEATTRS is 32bit so there's plenty of room
for growing new file attributes, with internal-only adjustments
required.
- Eliminate RPMFILE_UNPATCHED while at it, this is a leftover
from Suse patch rpms which are no longer used anywhere.
- Shuts up couple of "not in enum" complaints from gcc, and actually
"no state" is a perfectly valid state for one case: non-installed
packages (so remove the "not valid" comment from formats.c)
- OTOH, this created a new complaint for not handled case in a switch.
Oh well, fix it up too...
- 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.
- 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.
- rpmte has all the necessary bits at hand, rpmfi does not
- avoids silly ping-pong through transaction set to get to the ts element
- avoids recalculating number of relocations
- avoids accessing rpmte struct outside rpmte.c
- the information is already available through rpmfiFDigest() but that
requires valid iteration index to be active, whereas the digest algo
is per info set, not per file
- Transaction elements are install/erase type, not file info sets,
rename to rpmteTypeString(). It's only "useful" for fsm internal
debugging messages, hide it there.
- permit fine grained control over what's loaded into fi for what operations,
non-trivial memory savings are possible
- future possibilities - these reflect closely to rpm verify control
bits, all we need is RPMFI_DISK or similar operation to pull the
information from disk instead of header and then verify can simply
compare two rpmfi's
- it only ever returns NULLs because there are no security contexts in
headers (and having them in headers make no sense as the context varies
based on whatever selinux policy happens to be active on the target
system)
- new rpmfiFCaps() API to retrieve the info from rpmfi set
- fsm internals quite similar to selinux handling
- plenty of #ifdef's, another possibility would be adding cap_foo dummies to
system.h like for selinux
- Internally file sizes are still stored as 32bit, going to 64bit wouldn't
make much sense (would only waste memory for nothing) as long as we're
bound by cpio's 32bit per-file limit. Being "64bit ready" for filesizes
doesn't hurt anything though...
Panu Matilainen