genuinetools
Clair support can be affected by layer name collisions
It isn't safe to use the layer name or SHA for the name of a layer in Clair 2.x. This is because in the Clair 2.x data model, each layer has a pointer to its parent layer. This means that the name has to be unique to the ancestry (aka image) in order to avoid accidentally tangling up your history with another image's history.
Clair 3.x fixes this by forcing users to explicitly POST all the layers at once allowing Clair to maintain the idea of an ancestry internally, rather than simply by naming convention.
I should have totally warned you about this before. Sorry!
Oh good to know thanks, I can update
On Mon, Mar 12, 2018 at 6:33 PM, Jimmy Zelinskie [email protected] wrote:
It isn't safe to use the layer name or SHA for the name of a layer in Clair 2.x. This is because in the Clair 2.x data model, each layer has a pointer to its parent layer. This means that the name has to be unique to the ancestry (aka image) in order to avoid accidentally tangling up your history with another image's history.
Clair 3.x fixes this by forcing users to explicitly POST all the layers at once allowing Clair to maintain the idea of an ancestry internally, rather than simply by naming convention.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/genuinetools/reg/issues/80, or mute the thread https://github.com/notifications/unsubscribe-auth/ABYNbNXYIhGRmMP1BtQCAGLWlDumf8yDks5tdve9gaJpZM4SnzHT .
--
Jessie Frazelle 4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3 pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3
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.
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.
@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.
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