> On Nov 30, 2016, at 7:42 AM, Alexander Kanavin
> <[email protected]> wrote:
>
>>
>> (aside)
>> For starters, RPM5 uses keyutils(8), which has some hope of refactoring
>> _ALL__ pubkey
>> management out of _ALL_ RPM tool chains by writing a helper that is invoked
>> by the
>> keyutils async callback.
>
> Maybe it's possible to provide empty keyring functions to substitute for
> their absence in rpm5 - that way we can avoid having #ifdefs all over the
> place. I'd like to use #ifdefs sparingly, they make the code harder to read
> and maintain.
>
Let try to bring ourselves into mental alignment, and try
to architect some DNF refactoring that will eliminate
some porting issues:
No developer likes #ifdef’s.
Do you know keyutils? See
man 7 keyutils
Keyutils is a perfectly sane interface for keyring management that potentially
removes the need to duplicate pubkey management throughout RPM tool chains.
The goal would be to eliminate pubkey management in RPM tool chains to
the greatest extent possible, replacing pubkey management with keyutils
system calls.
Instead of having to do dialogues like
Should I import blahblah (y/N)?
where necessary (and often inconveniently) in RPM tool chains, a request-key(8)
invocation
would be performed by the kernel to return a cached pubkey.
(aside)
Arguably, there is as little reason to have a dialogue about pubkey importation
as there is to have a EULA dialogue while installing, but “trust” has many
definitions, and the dialogues are a useful means to notify end-users.
The existing multiple external pubkey sources like /etc/pki/rpm-gpg (rpm.org)
and
RPMTAG_PUBKEYS in *.rpm packages (rpm5.org, used to be in rpm.org) as well
as alternatives like SKS key-servers (rpm5.org) and other keyring sources
like ~/.gnupg can be unified through a single keyutils keyring implementation.
The existing keyring* API at rpm.org can be ported to use keyutils quite easily
for (legacy) API compatibility. RPM5 (when compiled with -lkeyutils) already
has some simple conventions for saving/retrieving pubkeys (though I haven’t
bothered yet with non-repudiable signatures/pubkeys/privkeys, not hard).
The development path would be to first enhance the rpmkey* API to handle
kernel keyrings, and then to refactor current pub key handling within both
rpm.org
and rpm5.org to use a common approach to key management.
Note that RPM5 has internal generate/sign/verify functions, and so would also
use keyutils for private as well as public keys.
Does the above start to describe the deeper issues associated with the keyring*
API porting?
I’m suggesting replacing the existing code in DNF with a better implementation
throughout.
73 de Jeff
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List [email protected]
