You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First of all, thank you for your work, Clair is an impressive software.
We are using Clair internally for our private repositories and we ran into the issue described in #68. To sum up: Clair is not aware of the whole chain of layers that make up a Docker image. As a layer is identified by its content, you can have the same layer in different images, with different parents, leading to false positives (or false negatives).
Here is how we ran into the problem:
We built an image FROM grafana/grafana:4.1.1. Clair informed us that there were some vulnerabilities in this image (because it was not built from the latest debian:jessie image). The Dockerfile looks like this:
FROM grafana/grafana:4.1.1
COPY file1 /foo
COPY file2.sh /bar
ENTRYPOINT ['/bar/file2.sh']
To fix the problem, we took the Dockerfile from grafana/grafana:4.1.1 and sourced our image directly from the latest debian:jessie:
The last few layers are the same in the 2 resulting images, but the parents are not. In the first case, the parents have some vulnerabilities while they have not in the second (they have only vulnerabilities for which there is no fix).
When POSTing the layers of the second image to Clair, we got a 201 status code, but the parent of the layers were not updated in the database. So, when fetching the vulnerabilities for the last layer of the second image, we actually got the vulnerabilities of the first image.
In #68, it is said that the issue has been identified and put into the roadmap, but the current roadmap makes no mention of it. Is this problem still identified somewhere?
The text was updated successfully, but these errors were encountered:
Presently the layer and namespace tables use type `varchar(128)` for
their respective name columns. For layer, this width works fine enough
using the sha256 digests provided by docker. However, if one wishes to
encode the image name into the layer name (eg, to avoid collisions like
in [0]), the limit of 128 bytes starts to feel a bit cramped. Bump to
256 bytes, since that "ought to be enough for anybody." (TM)
[0]: quay#319
This issue does not effect Clair v3 as we force users to post all the layers in an image upfront and we do not conflate relationships outside of that specified ancestry.
Hello,
First of all, thank you for your work, Clair is an impressive software.
We are using Clair internally for our private repositories and we ran into the issue described in #68. To sum up: Clair is not aware of the whole chain of layers that make up a Docker image. As a layer is identified by its content, you can have the same layer in different images, with different parents, leading to false positives (or false negatives).
Here is how we ran into the problem:
FROM grafana/grafana:4.1.1
. Clair informed us that there were some vulnerabilities in this image (because it was not built from the latestdebian:jessie
image). The Dockerfile looks like this:grafana/grafana:4.1.1
and sourced our image directly from the latestdebian:jessie
:The last few layers are the same in the 2 resulting images, but the parents are not. In the first case, the parents have some vulnerabilities while they have not in the second (they have only vulnerabilities for which there is no fix).
When POSTing the layers of the second image to Clair, we got a 201 status code, but the parent of the layers were not updated in the database. So, when fetching the vulnerabilities for the last layer of the second image, we actually got the vulnerabilities of the first image.
In #68, it is said that the issue has been identified and put into the roadmap, but the current roadmap makes no mention of it. Is this problem still identified somewhere?
The text was updated successfully, but these errors were encountered: