Answers: <p>Another option, if you trust your repo or package source is to disable gpg key checking. This is especially viable if you are connecting to a repo over SSL as you can verify you are pulling the correct source and there has been no MITM attack, though you lose verification of the integrity of each individual package (in the case the repo was hacked and a rogue package inserted or package is tampered with). To do this set in your repo file:</p>
  
  <p>gpgcheck=0</p>
  
Answers: CC BY-SA 3.0
Answers: 2018-04-26T16:33:31.117Z
Answers: 2018-04-26T16:33:31.117Z
Answers: James Shewey
Answers: <p>Download the key once:</p>
  
  <pre><code>gpg --keyserver pgpkeys.mit.edu --recv-key A0E98066
  gpg --export A0E98066 &gt; openresty-agentzh-A0E98066.gpg
  </code></pre>
  
  <p>Then later you can import the key without having to access the keyserver:</p>
  
  <pre><code>gpg --import openresty-agentzh-A0E98066.gpg
  </code></pre>
  
Answers: CC BY-SA 3.0
Answers: 2018-04-26T17:54:50.377Z
Answers: Will the key not be updated so now and then? If true, how could this be automated?
Answers: 030
Answers: CC BY-SA 3.0
Answers: 2018-04-26T18:08:51.637Z
Answers: @030 Typically, the signatures you want to test are for releases that are already out, and the key will not change. Checking the signature is a stronger guarantee than verifying only the checksum. It is true that a key could have been revoked and you will loose the protection against it. If detecting such scenario is important, I would recommend to query the key server normally and live with the occasional breakages. You could automate the first step, too, by  regularly checking whether your exported key is still up to date and otherwise raising an alert, but I think that would be overkill.
Answers: Philipp Claßen
Answers: CC BY-SA 3.0
Answers: 2018-04-26T12:48:03.930Z
Answers: 2018-04-26T13:00:19.223Z
Answers: 2018-04-26T13:00:19.223Z
Answers: Philipp Claßen
Body: <p>If you want to verify a signature of a downloaded file with gpg, you first have to import the key. Unfortunately, this operation is extremely slow and flaky in practice.</p>
  
  <p>For example, here I tried it out:</p>
  
  <pre><code>$ gpg --keyserver pgpkeys.mit.edu --recv-key A0E98066
  gpg: keyserver receive failed: No data
  
  $ gpg --keyserver pgpkeys.mit.edu --recv-key A0E98066
  gpg: key B550E09EA0E98066: public key "Yichun Zhang (agentzh) &lt;agentzh@gmail.com&gt;" imported
  gpg: marginals needed: 3  completes needed: 1  trust model: pgp
  gpg: depth: 0  valid:  14  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 14u
  gpg: next trustdb check due at 2019-01-13
  gpg: Total number processed: 1
  gpg:               imported: 1
  </code></pre>
  
  <p>The first run failed. When I repeated, it took very long but eventually succeeded. Especially, in a CI environment, it breaks a lot, that is why I am looking for alternatives.</p>
  
  <p>Question:</p>
  
  <ul>
  <li>How do you avoid the dependence to the remote keyserver?</li>
  <li>Is there an easy way to export the key as a file and use it later to import it in the CI environment without making a request to the keyserver?</li>
  </ul>
  
Tags: <continuous-integration>
Title: How to avoid the flakyness that comes with "gpg --recv-key"?
UserDisplayName: Philipp Claßen
ThreadText: # How to avoid the flakyness that comes with "gpg --recv-key"?
  
  (Asked by: username_0 on 2018-04-26)
  
  If you want to verify a signature of a downloaded file with gpg, you first have to import the key. Unfortunately, this operation is extremely slow and flaky in practice.
  
  For example, here I tried it out:
  
  ```
  $ gpg --keyserver pgpkeys.mit.edu --recv-key A0E98066
  gpg: keyserver receive failed: No data
  
  $ gpg --keyserver pgpkeys.mit.edu --recv-key A0E98066
  gpg: key B550E09EA0E98066: public key "Yichun Zhang (agentzh) <agentzh@gmail.com>" imported
  gpg: marginals needed: 3  completes needed: 1  trust model: pgp
  gpg: depth: 0  valid:  14  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 14u
  gpg: next trustdb check due at 2019-01-13
  gpg: Total number processed: 1
  gpg:               imported: 1
  
  ```
  
  The first run failed. When I repeated, it took very long but eventually succeeded. Especially, in a CI environment, it breaks a lot, that is why I am looking for alternatives.
  
  Question:
  
  * How do you avoid the dependence to the remote keyserver?
  * Is there an easy way to export the key as a file and use it later to import it in the CI environment without making a request to the keyserver?
  
  **Tags:** continuous-integration
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_0 on 2018-04-26. Score: 4 | Accepted answer
  
  Download the key once:
  
  ```
  gpg --keyserver pgpkeys.mit.edu --recv-key A0E98066
  gpg --export A0E98066 > openresty-agentzh-A0E98066.gpg
  
  ```
  
  Then later you can import the key without having to access the keyserver:
  
  ```
  gpg --import openresty-agentzh-A0E98066.gpg
  
  ```
  
  > **Comments:**
  > **username_2**: Will the key not be updated so now and then? If true, how could this be automated?  
  > **username_0**: @username_2 Typically, the signatures you want to test are for releases that are already out, and the key will not change. Checking the signature is a stronger guarantee than verifying only the checksum. It is true that a key could have been revoked and you will loose the protection against it. If detecting such scenario is important, I would recommend to query the key server normally and live with the occasional breakages. You could automate the first step, too, by  regularly checking whether your exported key is still up to date and otherwise raising an alert, but I think that would be overkill.  
  
  ---
  
  ### Answer by username_1 on 2018-04-26. Score: 2
  
  Another option, if you trust your repo or package source is to disable gpg key checking. This is especially viable if you are connecting to a repo over SSL as you can verify you are pulling the correct source and there has been no MITM attack, though you lose verification of the integrity of each individual package (in the case the repo was hacked and a rogue package inserted or package is tampered with). To do this set in your repo file:
  
  gpgcheck=0
  
  
  ---
  
  