Clair support can be affected by layer name collisions about reg HOT 6 OPEN

Yeah it's using layer[0] digest at the moment, I'll PR this shortly.

from reg.

from reg.

I think this might still affect the VulnerabilitiesV3 method in this case as reg is using the digest of layer[0] as the name, it looks like I'm getting some false positives and I'm not positive just yet but I think it's images that have the same digest for layer[0] picking up ancestry from previous images scans, or something.

I'll have a play changing the report name to something else and see if I still see the same issues, I'll PR it if that's what it is.

(edit): confirmed this is the case, apparently I have over 1000 images with the same layer[0].Digest.

Is there any preferred way to store the name? I was just gonna prepend the repo/tag or something.

from reg.

The name is intended to be the SHA of the manifest and not of any individual layer. If reg isn't using that, it's a bug.

from reg.

@jzelinskie what's the recommendation for schema V1 manifests? Those don't seem to have a digest of the whole image like schema 2 does.

from reg.

That's far more tricky and depends on the use case.

Internally, Quay used a unique identifier composed of the image ID and the unique id used for locating storage from the Quay database.

If you know that you'll never retag the image, you could use the fully qualified name and tag (e.g. quay.io/jzelinskie/chihaya-git:28df9sd. Using the tag is definitely prone to error so you are probably best crafting something totally unique like a UUID and storing a mapping to the image. v1 image ids are supposed to be globally unique, so you could try using layer[0].

Ideally, you should avoid v1 docker images if you aren't using Quay, which is the only registry I know that generates everything backwards compatibly to Docker 0.8.

edit: I'm totally confusing v1 and v2 schema1 and v2 schema2

from reg.