Mailinglist Archive: opensuse-buildservice (266 mails)

< Previous Next >
Re: [opensuse-buildservice] obs-service-gpg-offline
  • From: Adrian Schröter <adrian@xxxxxxx>
  • Date: Tue, 08 Jan 2013 13:27:24 +0100
  • Message-id: <1614909.zLkihK3mMN@scherben>
Am Dienstag, 8. Januar 2013, 11:18:34 schrieb Michal Vyskocil:
On Tue, Jan 08, 2013 at 10:11:04AM +0100, Adrian Schröter wrote:
Am Montag, 7. Januar 2013, 17:22:06 schrieb Stanislav Brabec:
I wrote a simple service, which can automatically check PGP signatures
of files using gpg-offline .keyring file:
https://build.opensuse.org/package/show?package=obs-service-gpg-offline&project=home%3Asbrabec

It could be an alternative to %prep checks during the build process
using %gpg-offline macro.

This is a simple version and does not take any arguments. It checks
online for updates, but it does not fail if the signature is not found
in the public servers. Only failure of checks against embedded keyring
will fail. It would need further discussion, what to return if:

- Key server did not respond.
- The key is not found upstream.
- The key was revoked.

Hm, what does a key on a gpg server tell us anyway for the trust of it?
Everybody can upload it and this person does not have necessarly a
connection
to the upstream project.

Hi Adrian,

atm we expect the .keyring will be manually validated in a Factory
review phase by review team. Our assumption is that keyrings won't
change too often and if so, then some big red button in webui for
reviewers will be needed.


IMHO we should collect validated gpg keys, where we know they are from
upstream
and put them either into some generic collection (for large projects like
kernel, KDE,
apache ...)

Initially we wanted to have one package collecting all keyrings. This
approach complicates the package submission. Of course, that in some
cases, the keyring should be packaged in a separate package.

sounds good.


We should also support to put the gpg key beside the sources. In this way
we see
if the key changes on a version update.

Sorry for my incompetence, but I live under assumption, that
BuildService is the tool tracks the file changes, so the best place
where to have .keyring file is together with other sources.

Yes, that was also my proposal here.

However, in addition to that it makes sense to me to have also a pool
somewhere. Esp.
for projects which have a larger amount of package sources. It makes it easier
that
for example all packages from KDE:Distro:Factory project are using the same key.

(Dunno if there are really signed tar balls meanwhile in KDE project, just an
example)


Doesn't it also make sense to extend the verify_source service for this
task instead
of adding another one?

But to close with something positive, thanks a lot for spending some work
here.
IMHO the lacking validation of our sources is one of biggest problem trust
wise :)

To me it seems that the biggest issue in current implementation is how
we can ensure the .keyring validity if package can put and submit what
he wants to.

So what about to create some dedicated (open)SUSE GPG key and put all
verified GPG ids into it's web of trust? Then all we need is to verify
if package is signed by this key and if so, then it's a trusted keyring.

sounds good.

Just one last remark, we will disallow the submission of dot files. So, maybe
the file should be name _keyring instead.

Thanks for a feedback - hope we will be able to finish it soon

Regards
Michal Vyskocil
--
Adrian Schroeter
SUSE Linux Products GmbH
email: adrian@xxxxxxx

--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-buildservice+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups