[Rpm-maint] Rally: minor API requests

[Maxim Udushlivy]

Greetings,

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.

(1)
    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.

(2)
    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 
/etc/pki/rpm-gpg/RPM-GPG-KEY-fedora
Is this ok [y/N]:
===================

Thank you,
Maxim Udushlivy