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

gpgkey cannot be retrieved #263

Closed
shitalm opened this issue Feb 8, 2017 · 3 comments
Closed

gpgkey cannot be retrieved #263

shitalm opened this issue Feb 8, 2017 · 3 comments

Comments

@shitalm
Copy link

shitalm commented Feb 8, 2017

Not able to build from the Dockerfile. Running this on OS X and Docker for Mac

gpg: requesting key BF357DD4 from hkp server ha.pool.sks-keyservers.net
gpgkeys: key B42F6819007F00F88E364FD4036A9C25BF357DD4 can't be retrieved
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0

But when I retrieve the same key on host (my mac) then it succeeds.

gpg --keyserver ha.pool.sks-keyservers.net --recv-keys B42F6819007F00F88E364FD4036A9C25BF357DD4
gpg: directory `/Users/shital/.gnupg' created
gpg: new configuration file `/Users/shital/.gnupg/gpg.conf' created
gpg: WARNING: options in `/Users/shital/.gnupg/gpg.conf' are not yet active during this run
gpg: keyring `/Users/shital/.gnupg/secring.gpg' created
gpg: keyring `/Users/shital/.gnupg/pubring.gpg' created
gpg: requesting key BF357DD4 from hkp server ha.pool.sks-keyservers.net
gpg: /Users/shital/.gnupg/trustdb.gpg: trustdb created
gpg: key BF357DD4: public key "Tianon Gravi <[email protected]>" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)

I can also successfully build on a centos server.

+ gpg --keyserver ha.pool.sks-keyservers.net --recv-keys B42F6819007F00F88E364FD4036A9C25BF357DD4
gpg: keyring `/tmp/tmp.sQeD1cISKM/secring.gpg' created
gpg: keyring `/tmp/tmp.sQeD1cISKM/pubring.gpg' created
gpg: requesting key BF357DD4 from hkp server ha.pool.sks-keyservers.net
gpg: /tmp/tmp.sQeD1cISKM/trustdb.gpg: trustdb created
gpg: key BF357DD4: public key "Tianon Gravi <[email protected]>" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)

Looks like an issue with docker on mac.

@yosifkit
Copy link
Member

yosifkit commented Feb 8, 2017

Sometimes it is the network connection of the VM, sometimes it is the route to the ha.pool, or even members of the pool being down. Have you tried restarting the docker daemon or docker VM?

@shitalm
Copy link
Author

shitalm commented Feb 9, 2017

Multiple times. Same behavior. Also when its failing inside Mac on docker, it's working on docker host at the same time.

@tianon
Copy link
Member

tianon commented Dec 26, 2017

GPG keyservers being flaky is a problem we see all too often -- closing since there's not really anything actionable here. As a workaround, I'd recommend either pulling the pre-built images as-is (and perhaps building upon them via FROM mysql:XXX in a derivative Dockerfile) or adjusting the keyserver to one which your own local environment has an easier time fetching from (such as hkp://keyserver.ubuntu.com:80 or similar).

@tianon tianon closed this as completed Dec 26, 2017
mkavulich added a commit to NCAR/container-dtc-nwp that referenced this issue Aug 17, 2021
…org (#50)

The keyserver pool.sks-keyservers.net, which I had been using to verify the download of the "gosu" tool in the base images, is no longer active. So when trying to build the base image, this step fails. This is summarized in this issue:
 - docker-library/mysql#263

This is mentioned in several places across the internet, including  https://www.reddit.com/r/crypto/comments/o7oh4w/skskeyserversnet_pool_dns_records_disabled/ . Even though this keyserver has been deprecated for a while, there's a lot of old stale documentation pointing to it, including that which I originally based by entrypoint script on.

The fix is simply to point to an active, more reliable keyserver,  hkps://keys.openpgp.org. This will fix the build issue, although it apparently remains to be seen what the future holds for key signing in this way. 

Still unsure if this is related to #46 or not....but hopefully when this is fixed we will see more reliable behavior?
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