[Rpm-maint] Rally: minor API requests

[Panu Matilainen]

On Sat, 3 Nov 2007, Maxim Udushlivy wrote:

> Greetings,

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...

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

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)

> (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?

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 
welcome.

>   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]:

I assume the rpmts_HdrFromFdno junk is what you're referring to as 
"strange" in the above?

 	- Panu -