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

Use experimental keyserver hkps://keys.openpgp.org #73

Open
wants to merge 2 commits into
base: v7.x.x
Choose a base branch
from

Conversation

leandro-lucarella-sociomantic
Copy link
Contributor

The SKS keyserver network is vulnerable to spam attacks, and these attacks started to happen. Downloading a spammed key will break GnuPG installation "in hard to debug ways". To mitigate this problem, switch to using a new experimental keyserver that is not part of the SKS network. This server has its own limitations, but it seems to be the way to go in the future.

For more information about the SKS network attack:
https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f

Fixes #72.

@iain-buclaw-sociomantic
Copy link

iain-buclaw-sociomantic commented Jul 3, 2019

I have no fundamental problems or concerns with this, considering the point we're starting from is a keyserver that's been taken offline.

@leandro-lucarella-sociomantic
Copy link
Contributor Author

Adding a commit to fix the build. I don't understand why this is now necessary, as all versions should be pinned, this build should be reproducible.

@leandro-lucarella-sociomantic leandro-lucarella-sociomantic force-pushed the keyserver branch 3 times, most recently from fde5ccd to 8480bce Compare July 3, 2019 15:37
@leandro-lucarella-sociomantic
Copy link
Contributor Author

Dammit! The build fails because the downloaded keys don't have ID information. This is a known issue with the new keyserver and GPG should be eventually fixed to support this but only a higher entity could know when...

https://keys.openpgp.org/about/faq#older-gnupg

@leandro-lucarella-sociomantic
Copy link
Contributor Author

For now I'm more inclined to leave this PR for future reference and only address it if the SKS network starts to be a real problem...

The alternative solution would be to just download the keys and host them somewhere as plain text files instead of using a keyserver.

The SKS keyserver network is vulnerable to spam attacks, and these
attacks started to happen. Downloading a spammed key will break GnuPG
installation "in hard to debug ways". To mitigate this problem, switch
to using a new experimental keyserver that is not part of the SKS
network. This server has its own limitations, but it seems to be the way
to go in the future.

For more information about the SKS network attack:
https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f

Fixes sociomantic-tsunami#72.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Use new experimental SKS server
2 participants