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

Artifactory caches and defaults to Docker manifest schemaVersion 1



    • Type: Bug
    • Status: Done
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: 7.9.0, 6.23.0
    • Component/s: Docker
    • Labels:
    • Severity:


      Symptoms: External clients like the Concourse docker-image-resource will intermittently return the incorrect SHA256 checksum of a Docker Manifest.json file on remote resources.


      Artifactory is able to proxy remote Docker registries and serves as a Docker Registry well. However, some third party clients will make requests that simulate, but do not exactly match, the Docker client.

      To understand this issue, we need to compare the two clients (Docker and Concourse docker-image-resource).

      *docker pull docker.art.local/hello-worl*d

      1. Docker first gets the list.manifest.json from Artifactory using the header "Accept: application/vnd.docker.distribution.manifest.list.v2+json"
      2. The client then directly pulls the "latest" manifest.json using the list.manifest.json metadata file contents

      This works well and is very stable. Artifactory always returns both the correct list.manifest.json as well as the correct manifest.json.


      docker-image-resource "check"

      The Concourse CI suite includes a method of getting the "latest" SHA256 Docker manifest checksum, it can be used as follows:

      echo '{"source":{"repository":"docker.art.local/cfcommunity/slack-notification-resource","tag": "latest"' | docker run -i --entrypoint /opt/resource/check concourse/docker-image-resource}}

      This client returns the incorrect checksum intermittently. This is a problem as some customers have extensively deployed Concourse CI tools, and Artifactory is not respecting the header the client is sending.

      The Concourse CLI does a single API call to Artifactory, requesting the manifest.json using the "Accept: application/vnd.docker.distribution.manifest.v2+json" header. This is listed on their GitHub here:



      Steps to reproduce:

      Cache a Schema1 manifest.json by manually calling the remote Docker repository in Artifactory via curl

      1. Get a token

      curl -uadmin:password -v [http://docker.art.local/v2/token


      2. Use the token to request the "latest" manifest.json with no headers

      curl -H"Authorization: Bearer AKCp5ccRjL5rGHDQK4aLoxNwvenYqGhHDhrFukXiTaB3Gs1YtFY4gK9tEWQ6rKNwzXJ8KGAqL" http://docker.art.local/v2/hello-world/manifests/latest -vv

      #Artifactory returns schemaVersion 1 by default, and caches the result:
      { "schemaVersion": 1,
      "name": "library/hello-world",

      3. Attempt to request a schemaVersion2 manifest.json, and instead receive the schemaVersion1

      curl -H"Authorization: Bearer AKCp5ccRjL5rGHDQK4aLoxNwvenYqGhHDhrFukXiTaB3Gs1YtFY4gK9tEWQ6rKNwzXJ8KGAqL" -H "Accept: application/vnd.docker.distributio.manifest.v2+json" http://docker.art.local/v2/hello-world/manifests/latest -vv

         "schemaVersion": 1,
         "name": "library/hello-world",


      I believe the problem is that Artifactory is by default sending a schemaVersion 1 manifest, and it does not respect the manifest headers other clients are sending. Artifactory needs to return a schemaVersion 2 manifest if the client supplies the right header.




              andreik Andrei Komarov (Inactive)
              patrickr Patrick Russell
              2 Vote for this issue
              7 Start watching this issue



                  Sync Status

                  Connection: RTFACT Sync
                  RTMID-20795 -
                  • Last Sync Date: