-
-
Notifications
You must be signed in to change notification settings - Fork 251
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
Rerun gpg recv-keys command multiple times #3544
Rerun gpg recv-keys command multiple times #3544
Conversation
That way, if a specific keyserver is slow and causes a timeout, we simply retry on a different server. Signed-off-by: Adam Farley <[email protected]>
Ok, build's still running, but it's passed the point where we might see a timeout, so at least we know this change doesn't break anything. Seeking reviews and approval. |
Is there an issue that describes the problem in more detail? There is also a change to the keyserver URL; can that choice be explained further? |
Signed-off-by: Adam Farley <[email protected]>
Hi Jie. Yes, the issue is a timeout, mentioned here. Also, I explained the change in keyserver via a comment in the change. This new keyserver is actually something that provides a different keyserver ip address each time you access it. That way, if we access a slow server, or a down server, we just loop back around and use a different server. In theory anyway. For some reason this seems to work just fine on Alpine, mac, and Windows, but fails on all the other Linux flavours. |
For debugging purposes. Signed-off-by: Adam Farley <[email protected]>
Signed-off-by: Adam Farley <[email protected]>
Signed-off-by: Adam Farley <[email protected]>
Only works on some platforms. The web page linked below suggests that the network it depends on has been deprecated, and attempts to ping the url directly have failed. https://stackoverflow.com/questions/66217436/error-gpg-keyserver- receive-failed-no-name/68132500#68132500 So I've replaced the url with an array of 3 alternatives. Let's try iterating over those. - Adam
8a68331
to
b74a8b8
Compare
Signed-off-by: Adam Farley <[email protected]>
Does it make sense to link the PR to the issue via one of the methods described here: https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue In the future, it would be good to reference the issue if it exists in your initial PR comment so everyone can see it. What was your source for your URL choice? When doing some preliminary searches online around GPG keyservers, there isn't too much 'official' looking documentation on active (and safe) keyservers to use... When making a change like that, it would be good to provide justification for it. |
Hi Jie,
I considered doing this, but elected not to do this because I didn't want to automatically close the issue before Stewart had a chance to review the fix (on the off chance it got approved and merged yesterday). Plus, the last fix didn't solve the problem like we thought it would, so auto-close seemed unduly optimistic.
Good point. Will do. :)
This was my source, which isn't even slightly trustworthy, but I didn't think that mattered in this case. My understanding is that keyservers are not trustworthy sources of keys in and of themselves. This is why we specify a fingerprint when we use the gpg command, and we also verify the key upon receipt (see the gpg --verify command a few lines later).
That's fair. I will remember this for future PRs. |
This allows us to hopefully provide some tolerance against the timeout errors, while at the same time using the same keyserver; fixing the problem while not affecting our risk profile. Signed-off-by: Adam Farley <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
That way, if a specific keyserver is slow and causes a timeout, we simply retry after a brief pause.
Fixes #3518