Uploaded image for project: 'Artifactory Binary Repository'
  1. Artifactory Binary Repository
  2. RTFACT-20257

Initial GPG Verification Fails When Using Your Own GPG Keys In Debian Client When Resolving From Debian Virtual Repository

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open
    • Priority: High
    • Resolution: Unresolved
    • Affects Version/s: 6.12.0, 6.14.0, 6.14.1
    • Fix Version/s: None
    • Labels:
      None

      Description

      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
      Ign:1 http://localhost:8081/artifactory/download.docker.com bionic InRelease
      Hit:2 http://localhost:8081/artifactory/download.docker.com bionic Release
      Get:3 http://localhost:8081/artifactory/download.docker.com bionic Release.gpg [819 B]
      Ign:3 http://localhost:8081/artifactory/download.docker.com bionic Release.gpg
      Fetched 819 B in 0s (8,608 B/s)
      Reading package lists... Done
      W: GPG error: http://localhost:8081/artifactory/download.docker.com bionic Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 7EA0A9C3F273FCD8
      W: The repository 'http://localhost:8081/artifactory/download.docker.com bionic Release' is not signed.
      N: Data from such a repository can't be authenticated and is therefore potentially dangerous to use.
      N: See apt-secure(8) manpage for repository creation and user configuration details.
      root@ip-10-0-1-146:~#

       

      Nothing in the catalina.out logs

      Here are the entries from request.log file:

       

      20191106194243|14|REQUEST|127.0.0.1|anonymous|GET|/download.docker.com/dists/bionic/InRelease|HTTP/1.1|404|0
      20191106194243|1|REQUEST|127.0.0.1|anonymous|GET|/download.docker.com/dists/bionic/Release|HTTP/1.1|304|0
      20191106194243|15|REQUEST|127.0.0.1|anonymous|GET|/download.docker.com/dists/bionic/Release.gpg|HTTP/1.1|200|819

      =======================================================

       

      Steps to  reproduce:

       

      On Ubuntu 16

      Art v6.12.0

       

      1. Create Remote Debian repository (in my case: remote-download.docker.com) pointing to: 

      https://download.docker.com/linux/ubuntu

      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.

       

       

        Attachments

        1. 10.jpg
          10.jpg
          315 kB
        2. 11.jpg
          11.jpg
          162 kB
        3. 12.jpg
          12.jpg
          270 kB
        4. 13.jpg
          13.jpg
          907 kB
        5. 14.jpg
          14.jpg
          655 kB
        6. 15.jpg
          15.jpg
          272 kB
        7. 16.jpg
          16.jpg
          238 kB

          Issue Links

            Activity

              People

              Assignee:
              Unassigned
              Reporter:
              timt Tim Telman
              Votes:
              9 Vote for this issue
              Watchers:
              14 Start watching this issue

                Dates

                Created:
                Updated: