[RTFACT-20257] Initial GPG Verification Fails When Using Your Own GPG Keys In Debian Client When Resolving From Debian Virtual Repository Created: 05/Oct/19 Updated: 01/Apr/20
|Project:||Artifactory Binary Repository|
|Component/s:||Debian, Virtual Repositories|
|Affects Version/s:||6.12.0, 6.14.0, 6.14.1|
|Attachments:||10.jpg 11.jpg 12.jpg 13.jpg 14.jpg 15.jpg 16.jpg|
In some use cases Users do not want to use GPG keys from the upstream in their Debian client & Artifactory. Instead, they want to use their own generated GPG keys to sign Releases file. However, GPG Verification fails during the initial apt-get update, subsequent apt-get succeeds until the Metadata Retrieval Cache period expires in Remote repository:
User uses his/her own GPG Keys In Debian Client (and In Artifactory) when resolving from Debian remote repository using apt-get update, with the following ERRORs:
root@ip-10-0-1-146:~# apt-get update
Nothing in the catalina.out logs
Here are the entries from request.log file:
Steps to reproduce:
On Ubuntu 16
1. Create Remote Debian repository (in my case: remote-download.docker.com) pointing to:
2. Create Debian Virtual repository (in my case: download.docker.com), and aggregate that newly created Debian Remote repository
3. Create GPG keys using: gpg --gen-key
4. Add keys to keystore using: apt-key add <your_public.key> , then check if it was added by running: apt-key list
5. Add those two keys(public and private) to Artifactory under: Admin --> Signing Keys
6. Add Artifactory Debian virtual to /etc/apt/sources.list file, in my case: deb http://localhost:8081/artifactory/download.docker.com bionic stable
7. Delete the following folders in your apt client: rm -rf /var/cache/apt /var/lib/apt
8. Run: apt-get update
You will notice that the very first apt-get will fail, and the subsequent apt-get update will succeed UNTIL the "Missed Retrieval Cache Period" expires. Once it expires, the initial apt-get update will fail again, then it will succeed until "Missed Retrieval Cache Period" expires again. If you set the value of "Missed Retrieval Cache Period" to "0", you will be able to reproduce this issue continuously.
Possible Workaround is to increase the value for "Missed Retrieval Cache Period" to prolong the expiration. With that you will reduce the number of failed "apt-get" updates.
Screenshots of my environment are attached below. I can share my environment for testing and debugging, if needed.
|Comment by Ben Abineri [ 29/Oct/19 ]|
We are encountering this issue too on 6.13.1.
If I add the key with `sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys ` I get a different error:
|Comment by Arto Hakola [ 07/Nov/19 ]|
By default, the functionality should be (logical) like:
Otherwise, virtual repos can only have local repositories which would make this virtual repository feature quite narrow usability.
|Comment by Valeriy Petrov [ 13/Nov/19 ]|
1. Generating and exporting PGP keys, according to the following documentation article - Generating Keys
****apt update Successful ****
However, after Metadata cache retrieval expires or Setting it to 0 on the remote repo, the apt update will fail with the following error:
W: GPG error: http://art.jfrog.local:12176/artifactory/debian buster Release: The following signatures were invalid: BADSIG 04EE7237B7D453EC Debian Archive Automatic Signing Key (9/stretch) <email@example.com>
Then, after triggering Index Recalculation, we were able to run apt update successfully again.
from the artifactory.log after manually triggering recalculation:
2019-10-31 13:50:39,554 [http-nio-8081-exec-5] [INFO ] (o.a.u.r.s.a.b.t.a.RecalculateIndexService:62) - Recalculating index for repository debian scheduled to run
2019-10-31 13:50:42,541 [art-exec-2] [INFO ] (o.a.r.HttpRepo :470) - one downloading http://cdn-fastly.deb.debian.org/debian/dists/buster-updates/Release 46.52 KB
2019-10-31 13:50:42,583 [art-exec-2] [INFO ] (o.a.r.HttpRepo :483) - one downloaded http://cdn-fastly.deb.debian.org/debian/dists/buster-updates/Release 46.52 KB at 1,138.50 KB/sec
2019-10-31 13:50:42,596 [art-exec-2] [INFO ] (o.a.r.d.DbCacheRepo :179) - Zapped 'one-cache:dists/buster-updates/Release.gpg' from local cache: 1 items zapped.
Now all this happens due to different gpg returned from a virtual repo on the same requests:
This fails with BADSIG err (Metadata Retrieval Cache Period (Sec) Set to 0 will allways fail):
This is successfull:
My public key:
|Comment by Ben Ifrach [ 21/Nov/19 ]|
By requesting the release GPG from the virtual repository (see request attached) if the artifact is expired the wrong file GPG file will be served and the client will fail the request.
Two workarounds to use in the meantime:
|Comment by Andrew Ferguson [ 10/Dec/19 ]|
We've recently upgraded our instance to 6.15.1 in response to the recent CVE notice & can confirm that this issue is also affecting Artifactory 6.15.1.
|Comment by Grzegorz Skołyszewski [ 16/Dec/19 ]|
We're observing the same issue on 6.14.2. This is a blocker for us. Do you have any updates or ETA for the fix?