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 <[EMAIL PROTECTED]>" 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 -
_______________________________________________
Rpm-maint mailing list
[email protected]
https://lists.rpm.org/mailman/listinfo/rpm-maint
