<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>

CC BY-SA 3.0
2018-04-26T16:33:31.117Z
2018-04-26T16:33:31.117Z
James Shewey
<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>

CC BY-SA 3.0
2018-04-26T17:54:50.377Z
Will the key not be updated so now and then? If true, how could this be automated?
030
CC BY-SA 3.0
2018-04-26T18:08:51.637Z
@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.
Philipp Claßen
CC BY-SA 3.0
2018-04-26T12:48:03.930Z
2018-04-26T13:00:19.223Z
2018-04-26T13:00:19.223Z
Philipp Claßen
<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>

<continuous-integration>
How to avoid the flakyness that comes with "gpg --recv-key"?
Philipp Claßen
# 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) " 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


---

