Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

noninteractive gpg #43

Open
cgwalters opened this issue Apr 15, 2015 · 4 comments
Open

noninteractive gpg #43

cgwalters opened this issue Apr 15, 2015 · 4 comments

Comments

@cgwalters
Copy link
Collaborator

RPM and GPG. Always a fun topic!

For the case of upgrading inside an existing system, e.g. you're doing yum update inside a Fedora system with fedora-release installed which references the GPG key by file:/// URIs that were already retrieved in a trusted way (ideally), things are fine.

Where things start to break down is when one is operating on a root outside of the running system, which happens with things like installers (Anaconda) and containers (rpm-ostree container).

Notes

  • It's common for 3rd party repository files to reference GPG keys by http(s):// URL
  • At least yum will auto-download and then either prompt, or auto-import if -y is provided (and it's very common to use -y in deployment scripts, Dockerfiles, etc.)
  • In Fedora at least, the LiveCD kickstart imports the gpg keys for the main repos, so users don't see the prompt on the first update

Also specifically, I think using yum -y with gpgkey=http://blah.com/ is completely broken - anyone on the internets can MITM the key and the packages.

libhif noninteractivity vs GPG

Now libhif has a policy of noninteractivity (AFAICS). Which...flips around some of the tradeoffs. We actually currently don't even import gpgkey URL references at all if gpgcheck=1 but gpgcheck_md=0 (which is the default for Fedora/CentOS at least).

Fixes

  1. Add a new gpg_fingerprint to repository files. That way we can auto-download them even over un-authenticated http without (too much) fear (doing HTTP as root still sucks).

  2. For the use case of constructing fresh install roots, I would like to support retrieving keys from locations relative to the .repo file. Something like: gpgkey=file://./RPM-GPG-KEY-CentOS-7

  3. Make more well defined which keyring is used for installroots (do we use the real /etc/rpm/pki-gpg even if doing an installroot?)

cgwalters added a commit to cgwalters/sig-atomic-buildscripts that referenced this issue Apr 15, 2015
…seful

I'd expect at least CentOS to have `https://` (i.e. TLS protected)
versions of the keys available.  However if we do that it triggers
other bugs in libhif (which we'll fix), but for now let's just do
this.

See rpm-software-management/libdnf#43
@cgwalters
Copy link
Collaborator Author

Worth noting the way mock handles this now is: https://lists.fedoraproject.org/pipermail/devel/2015-October/215841.html

@copumpkin
Copy link

The /etc/rpm/pki-gpg thing has been getting in my way too, since my host system doesn't have that folder (I'm using libhif for rpm-ostree).

@copumpkin
Copy link

Err, for /etc/pki/rpm-gpg 😄

@Conan-Kudo
Copy link
Member

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants