[Rpm-maint] Rally: minor API requests
udushlivy at mail.ru
Sat Nov 3 10:46:22 UTC 2007
During the development of the Rally (an RPM front end for advanced
desktop users, http://crow-designer.sf.net) I have found several moments
where RPM may be improved. This message is about two API additions. I
could try to provide patches if these additions are acceptable.
The first is very small and is about the way to check RPM database
modification time. This is crucial for a GUI application as in order to
run smoothly it must have a full list of installed RPM's with a minimal
delay after start. Rally uses a fast internal cache which should be
updated only if some RPM's were installed or erased since the last run.
Currently I do the same as the Smart package manager: use
stat(2)/st_mtime on "/var/lib/rpm/Packages" file, but a specialized
function would make RPM API a bit more complete. As an alternative that
function may return the number of transactions committed to the database.
The second issue is related to the digital signature checking. A
command-line RPM interface offer users the possibility to install public
keys into the database and reuse them later during installation of the
packages. When a package is being installed, its signature's fingerprint
is used to retrieve a stored public key from the database for the
process of verification. Absolutely logical and convenient - but not for
GUI front ends that work with "createrepo" repositories. Such
applications would want to maintain their own public key directories for
(a) security reasons and (b) improved usability.
Rally v0.1 uses two functions (readLead and rpmReadSignature) not
found in public headers and three internal fields of the rpmts structure
(pkpkt, pkpktlen and pksignid) in order to simulate the missing API's:
the function to extract a fingerprint from a local RPM file and the
function to supply a *particular* public key for a subsequent invocation
of the rpmReadPackageFile function.
So, where are security and usability problems with the current API?
Each "createrepo" repository may refer to its own set of public keys.
When all keys from all repositories are installed into one database it
becomes impossible to verify a package from a particular repository
against a limited set of public keys from exactly that repository.
Frankly, I cannot imagine a situation of how current behavior may be
exploited but... it is better to act in advance, isn't it?
The usability of the GUI front ends may be improved also because it
would not be necessary to confuse users with strange questions like this:
warning: rpmts_HdrFromFdno: Header V3 DSA signature: NOKEY, key ID 4f2a6fd2
Importing GPG key 0x4F2A6FD2 "Fedora Project <fedora at redhat.com>" from
Is this ok [y/N]:
More information about the Rpm-maint