[Rpm-maint] Rally: minor API requests
pmatilai at redhat.com
Tue Nov 13 08:09:24 UTC 2007
On Sat, 3 Nov 2007, Maxim Udushlivy wrote:
Hi, and sorry for the late reply...
> 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.
Suggestions (and patches) always welcome, there are a number of
shortcomings in the RPM API as it is...
> 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.
Sounds entirely reasonable to me, there are a number of users (smartpm,
apt-rpm ...) that would benefit. Whatever the implementation, it needs to
abstract out any backend DB details (as rpm supports BDB and SQLite
backends for the DB)
> 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
> 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?
There are a number of issues (API and other things) with rpm's public key
handling that need addressing sooner or later .. concrete API suggestions
> 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]:
I assume the rpmts_HdrFromFdno junk is what you're referring to as
"strange" in the above?
- Panu -
More information about the Rpm-maint