Mailinglist Archive: opensuse-buildservice (182 mails)

< Previous Next >
Re: [opensuse-buildservice] Verification of OpenPGP keys for OBS repositories (and packages)
  • From: Adrian Schröter <adrian@xxxxxxx>
  • Date: Wed, 17 Feb 2010 17:48:34 +0100
  • Message-id: <201002171748.35127.adrian@xxxxxxx>
Am Mittwoch, 17. Februar 2010 17:28:49 schrieb Stefan Tittel:
Dear List,

repository metadata and packages on OBS are OpenPGP signed. That is a good
thing in general to prevent malicious packages getting installed in case of
server compromisation or a man-in-the-middle attack.

However, signatures are only as good as the signing key can be trusted. At
moment after adding a buildservice repository, YaST prompts to accept the
corresponding key. How can I verify that this key is genuine?

Currently only by checking who owns the project, think about to trust them or
and check if they have signed the public key with their own private gpg keys.

Yes, that is not nice and not practicable. There is a project

to improve that. Base work has been done, however currently it stalls due to
lack of man power. If someone want to continue on that it would be greatly

Just blindly accepting the presented key will make the entire use of OpenPGP
signatures worthless. If an attacker manages to compromise the server or
manages to be the man-in-the-middle, he can just easily put his own key on
server (and I don't have much choice but to accept it blindly).

For instance, today the key of the KDE4 community repository appears to have
changed. How can I verify that this change is genuine and not the result of

Only via checking the people owning KDE:Community. If they publish at a trusted
the new finger prints and you trust this place and these people you should be

I can think of two possible solutions for this issue:

1) Sign the OBS repository keys with a trusted master key. This master key
could become trusted either by being included in the openSUSE distribution or
by being offered from a seperate SSL-secured web server. The advantage would
be that the user does not have to check fingerprints of repository keys after
the master key has been successfully imported. The disadvantage would be that
it wouldn't really work for user repositories on OBS, since the level of
trustworthiness can't possibly be determined for each and every OBS user.

While we can do this (actually it should be the case already, if not it is a
this has zero value here.

Everybody can create an OBS account and build all kind of packages, good or
The server can not check if they contain attack code.
All what we can verify is that the binary packages are indeed built by the
submitted sources.

2) Set up a seperate SSL-secured web server, where key fingerprints are
for verification purposes. After YaST prompts me to accept a new key, I would
then go to this website and check if the key fingerprint matches. The
advantage would be that it would be quite easy to implement and that the user
can decide which teams/persons he wants to trust. The disadvantage would be
that most users would still just blindly import the keys, because they are
lazy. :)

This is more or less (a bit more sophisticated) suggest in the Concept I pasted
in the beginning.

if someone has some time to work on that it would be great and we can help to
some degree.

Some code is already existing.

Personally I prefer 2) for reasons of simplicity and flexibility.

Both approaches could also be fit for managing the genuiness of not just
repository keys (as outlined above) but also package signing keys (with the
exception that package signing keys need to be provided first, since they are
not available in the repositories themselves).

What I fail to understand: Is package signing only useful when installing
packages by hand? Because the repository metadata contains checksums for
package (and these checksums are hopefully checked during software
installation), so trusted repository metadata should be enough to prevent the
installation of malicious packages. If I am right, the possibility to verify
package signing keys would be a nice service for people installing packages
hand, but not necessary for people installing packages from repositories.

yes, signed repo data should be enough. But you might want to pick an rpm
and check if this is valid as well (ignoring the repo data). So it is signed as



Adrian Schroeter
SUSE Linux Products GmbH
email: adrian@xxxxxxx

To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-buildservice+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups