Mailinglist Archive: opensuse-buildservice (182 mails)

< Previous Next >
Re: [opensuse-buildservice] Verification of OpenPGP keys for OBS repositories (and packages)
  • From: Stefan Tittel <stefan@xxxxxxxxxx>
  • Date: Fri, 19 Feb 2010 17:06:04 +0100
  • Message-id: <201002191706.08265.stefan@xxxxxxxxxx>
On Wednesday 17 February 2010 17:48:34 Adrian Schröter wrote:

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

I really like this concept, but it is probably too elaborate to be implemented
in the foreseeable future.

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 an attack?
Only via checking the people owning KDE:Community. If they publish at a
trusted place the new finger prints and you trust this place and these
people you should be fine.

That involves tracking down who is responsible for this repository and if and
where the fingerprint of the new key is published and making sure that the
publishing location is genuine.

I think we agree that this is not very practical.

I can think of two possible solutions for this issue:

1) Sign the OBS repository keys with a trusted master key. [...]
While we can do this (actually it should be the case already, if not it is
a bug) this has zero value here.

Everybody can create an OBS account and build all kind of packages, good or
evil. 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.

I think we have a different understanding of "master key" here. I was thinking
about some authority manually verifying and signing the keys of at least the
semi-official repositories, so the user can opt to trust that authority
instead of verifying the keys of semi-official repositories by himself.

2) Set up a seperate SSL-secured web server, where key fingerprints are
listed for verification purposes. [...]
This is more or less (a bit more sophisticated) suggest in the Concept I
pasted in the beginning.

That's a bit of an understatement. :)

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.

How much? More like 10% of what is needed or more like 80% of what is needed?

Personally I would prefer a "do it simple and usuable first, do the
sophisticated stuff later" approach. I totally agree that trust is an
individual measure being build from a variety of components. However, I also
believe that having the most basic components convered soon is better than not
having anything soon, but a very flexible system in the distant future (or not
at all).

Having an SSL-enabled web server listing repositories, fingerprints, the
persons responsible for a repository and some information about these persons
is easy per se. The big question is: How do people authenticate for updating
their fingerprints?

The most convenient way would be to use build service login data for updating
the fingerprints. Of course this is pretty insecure if build service login
data get compromised; build service login data would be a common point of
failure. Also (and this is my main complaint) this approch would not identify
a build service user as the person he claims to be, but just as the person who
has access to the build service account in question.

A more secure solution could involve establishing identity by OpenPGP keys or
X.509 certificates that have been signed by an accepted CA. X.509 client
certificates seem more fit here, because they could be used directly for
authentication against the web server. Of course this identity would also need
to be established in the build service account, because a) we need a link
between web server access and build service access and b) we need to make sure
that the actual build service user has a confirmed identity.

All that's left now is a way to handle fingerprint updating permissions for
repositories which belong to multiple users. And a way to make the web server
tell which roles a person has within the openSUSE project (if any), because,
for instance, a KDE repository maintained by one of the openSUSE KDE
maintainers makes it a lot more trustworthy.

All of a sudden my "simple proposal" has gotten a lot more complexity to it
than I would wish for, at least in the properly safe variant. Especially the
need to aquire a CA-assured X.509 certificate would probably be too much
effort for many build service users. Also implementing the necessary logic for
the web server and changes to build service authentication infrastructure
would mean more than a negligible amount of work.

So maybe as a really simple solution we should concentrate on just the semi-
official repositories? We could do that either by using a special master key
as described earlier or with a fingerprint webserver, where key changes would
be propagated by OpenPGP (or S/MIME) signed mails on a mailing list and then
updated manually by a small group of persons having write access to the web
server. From an engineering perspective manual updating is lame, but really:
How often do we have key changes in the semi-official repositories?

Maybe I am aiming too low here, but unless somebody declares himself able and
willing to dedicate a lot of work into this, just concentrating on the semi-
official repositories and doing manual updates in case of key changes seems
like something that a) would still improve upon the current situation quite a
lot and b) is not a lot of work.

Also I'd welcome to hear the thoughts of people thinking about all of this for
a longer time than I am. I just started to think about it myself two days ago,
so probably I am missing things. :)

OpenPGP encrypted mail strongly preferred (key ID: 952559A9)
< Previous Next >