-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Harbor Replication Issue: Invalid Image Manifest Causes Transfer Failure and Vulnerability Scan Error #18813
Comments
you can look this layer |
@lengrongfu Just the replication/trivy cant work with it. |
could you please share the manifest json of ops-nexboard/cert-manager/trust-manager:sha256:d9fb966245a7fa6e59868d32ac9d5dac4f2ad92ac2982ed5f31ee7320a36552a? It appears that the format doesn't confirm to the OCI image spec. |
Yeah I mean, it seams to expect more architectures then the OCI artifact has.
|
@wy65701436 @lengrongfu Any noticable Updates on this? |
This is the manifest list for the |
Returns: {
"errors": [
{
"code": "MANIFEST_UNKNOWN",
"message": "OCI manifest found, but accept header does not support OCI manifests"
}
]
}
|
@wy65701436 @lengrongfu @lengrongfu any progress? |
@chlins any update? As mentioned prior, we're blocked by this. |
Please try to add the Accept header when curl request, the value can refer to https://docs.docker.com/registry/spec/manifest-v2-2/#media-types. |
Well yes, you did a replication from |
OK, so the image can be replicated from |
The vender is huawei SWR or Software Repository for Container. |
From my perspective, the issue may relate with remote registry because from the replication logs it shows the process is normal, and eventually it failed due to receive the error from remote registry. You can try to replicate the image to other registries such as |
@chlins Could you also try with this image
|
Please check whether the artifact |
@chlins it does, like I said, the pull to |
@chlins
|
@chlins I assume trivy uses the wrong mime_type, could that be? "artifact": {
"namespace_id": 3211,
"repository": "cache-common/linkerd/policy-controller",
"tag": "",
"digest": "sha256:583bdaf4c614da89a2f806ce2d04071b36ad532d25057f056e7e32753153c63b",
"mime_type": "application/vnd.oci.image.manifest.v1+json" <------ see here
} |
This image can also be replicated successfully in my environment... |
@zyyw Could you help to confirm the supported list of layer type with trivy? |
Related? |
@chlins / @zyyw / @lengrongfu / @wy65701436 any update? |
This issue is being marked stale due to a period of inactivity. If this issue is still relevant, please comment or remove the stale label. Otherwise, this issue will close in 30 days. |
This issue was closed because it has been stalled for 30 days with no activity. If this issue is still relevant, please re-open a new issue. |
Please do not close. |
as well as respond please @chlins / @zyyw / @lengrongfu / @wy65701436 any update? |
Sorry for the delayed response. We did reproduce this error and will discuss it with the Trivy team. This error message is returned by Trivy:
Step to reproduce:
![]()
|
Artifacts that are scanned successfully have
while those errored out by Trivy doesn't have
@knqyf263 |
It is not a container image. It makes sense to fail to scan it. What does Harbor expect in this case? IMO, Harbor should not show the "Scan" button and trigger scanning on the provenance. It is not only provenance technically. The scanning should not be triggered on anything other than supported types, images (and SBOM). What do you think?
|
BTW, I think the attestations should ideally be linked to the artifact via OCI reference API rather than mixed in the image manifest list. |
Yeah, I agree with you on that. And if these non-image artifacts are linked to subject artifacts via |
Anyway, a non-image digest is passed to Trivy and the scanning failed. It's an expected behavior on the scanner side. Please let me know if you request any changes to the scanners. |
Sure, and thank you for the feedback! |
For reference, this issue is essentially a duplicate of my issue at #17630 Also, shouldn't this issue be reopened? It hasn't been fixed and the issue still appears with current harbor versions. |
+1 - still an issue, please reopen the issue. |
Expected behavior and actual behavior:
Since I use harbor I replicate (cache) my images into our registry and mirror them whereever I need them.
Since OCI there seem to be some issues rising atm.
Steps to reproduce the problem:
Sync OCI any linkerd image from current stable or
quay.io/jetstack/trust-manager:v0.5.0
into your registry using a replica job.Versions:
Version
Additional context:

Replication into the registry:
Job succeeded

Replicate out of the registry:
Trivy logs
The OCI in the registry looks like so

See issue on OCI opencontainers/image-spec#1025
The text was updated successfully, but these errors were encountered: