Created attachment 275907 [details] [review]
gpgverifier: Add /etc/ostree/trusted.gpg.d

So, 8 months later...

I'm thinking lately that what would be nicest is to support binding GPG keys to repository configuration.  However, we also need a keyring.  Which is what I was kind of doing with the above patch.

But having a keyring doesn't in general imply the key should be trusted for every repository. 

Also, ostree supports non-root repos, and neither /etc nor /usr work for that.

 - Support a keyring.gpg directory per repository that stores trusted keys.
 - Support /etc/ostree/keyring.gpg.d for /ostree/repo
 - Add a "gpgkeys" attribute to remotes that is an array of key fingerprints to trust just for that repository.

?

An issue here that remains is the ergonomics of key import.  Something like this might be ok:

ostree --repo=repo gpg-import /path/to/key.gpg

To have a one-step command for adding a remote repo with a key:

ostree --repo=repo remote add --gpgkey /path/to/key.gpg myremote http://example.com/repo

All of this sounds great to me, and it is something I'd like to have for gnome-sdk

I can pick this up next week.

Would this eliminate OSTREE_GPG_HOME or keep it for backward-compat?

Also, re:

    - Support /etc/ostree/keyring.gpg.d for /ostree/repo

Should this be /ostree/repo/keyring.gpg.d so it's consistent with non-system repos?  Presumably one would mainly use "ostree gpg-import" instead of direct copying.

I'm starting to work on this seriously now and would like to suggest a few revisions to Colin's proposal.  I'd appreciate feedback.

- Given a "gpg-import" command, a keyring directory seems unnecessary to me.
  I think a single keyring file would be sufficient; the import command would
  just create it or append to it.  gpgv2 by default operates on a keyring named 
  "trustedkeys.gpg", which seems like a good enough name to reuse here.  So I
  propose each repo simply have its own "trustedkeys.gpg" file.

- Here's my suggestion for the "gpg-import" command syntax:

  ostree [--repo=repo] {--keyring=/path/to/keyring.gpg} gpg-import KEY-ID...

  This would by default look for GPG keys in the user's personal keyring if no
  --keyring options are given.  Otherwise an explicit file list is searched as
  given by one or more --keyring options.  Each requested key is appended to
  the repo's trusted keyring (preferably avoiding duplicates).

- Similar semantics for the "remote add" command:

  ostree remote add {--keyring=/path/to/keyring.gpg} {--gpgkey KEY-ID} ...

  If I understand Colin's intention correctly, this would both import each
  KEY-ID into the trusted keyring and also add its fingerprint to a "gpgkeys" 
  attribute in the repo config.

There still remains the issue of backward compatibility and whether or not to  honor existing keys under $OSTREE_GPG_HOME (including its default).

We may not need the `gpgkeys` attribute if we can just rely on being in the keyring = trusted.  I think the reason I mentioned it was I was thinking about the problem of whether or not non-root repositories trust keys /usr/share/ostree/trusted.gpg.d.

On the gpg import, it might be useful if we had something that accepted a key from standard input or a file.  The use case for this is software where you might not have a home directory (e.g. pulp), or if running as root, you don't want to affect root's home directory.

Otherwise those commands look good to me.

I'm in danger of over-thinking this, but do we want to associate GPG keys to the whole repository or to a specific remote?

I'm thinking of a case where a repository hosts multiple operating systems (say, Fedora and CentOS).  Presumably you would set up separate remotes for each OS.  When pulling and verifying a signed commit from, say, the CentOS remote, it seems to me OSTree should exclude GPG keys meant for Fedora.

If that's what we want, I can alter some of what I spec'd out above:

  * The keyring files could be named after their remotes:

      REMOTENAME.trustedkeys.gpg

  * The "gpg-import" command could become a "remote" subcommand

      ostree remote gpg-import REMOTENAME KEY-ID...

    which would act on the REMOTENAME.trustedkeys.gpg keyring.

Is there value in making it this fine-grained?

Oh right, the "different content sets in one repository" model is probably why I was thinking of the `gpgkeys` config.

But `REMOTENAME.trustedkeys.gpg` seems fine to me too.

(In reply to Colin Walters from comment #7)
> On the gpg import, it might be useful if we had something that accepted a
> key from standard input or a file.  The use case for this is software where
> you might not have a home directory (e.g. pulp), or if running as root, you
> don't want to affect root's home directory.

I hadn't considered reading from standard input - that kinda throws a wrench into what I had in mind.  I don't know if it's worth pursuing.

The --keyring=/path/to/keyring.gpg option I think should cover importing from arbitrary keyring files in lieu of a home directory.  You would still have to know the specific key ID(s) to import from that file.

If there's a use case for just slurping up everything from a keyring file then I suppose I could investigate allowing wildcards for key IDs, but I'm not sure if that's what you meant for the cases you mentioned.

The reason I mentioned stdin is it's fairly common to have PGP public keys available as URLs.  For example:

https://access.redhat.com/security/team/key
Links to:
https://www.redhat.com/security/fd431d51.txt

And for Debian:
https://ftp-master.debian.org/keys.html

Now obviously if you know the fingerprint you can download
from a keyserver - but downloading over TLS adds additional
protection.

Being able to do:

curl https://www.redhat.com/security/fd431d51.txt | ostree remote gpg-import redhat --stdin

seems like it'd be more convenient than having to indirect through my personal keyring.

But if it's hard we can leave it for the future.

Got'cha.  That would be useful indeed.

Example I just found while doing something else:

https://github.com/GoogleCloudPlatform/kubernetes/blob/10dab7992dbda585d34b88c8f758535140d351de/examples/cassandra/image/Dockerfile

(I think in this case what they really want is something like gpg --receive-from-keyserver-to-stdout, but it's simpler if the web site hosts the key)

Also what they're doing here is IMO a "better practice" than the very common use of "yum -y" or equivalent in Dockerfile, which will simply auto-import the key; see https://github.com/hughsie/libhif/issues/43

For xdg-app use I would like the keys to be per remote. There will basically be just one repo for all installed apps, which may be from different remotes. I don't want a gpg key leak for remote A be usable to inject an otherwise untrusted app from remote B.

Thanks, the use cases help clarify this.

Pull request at https://github.com/GNOME/ostree/pull/107

Merged for ostree 2015.7.

*** Bug 729216 has been marked as a duplicate of this bug. ***