Hi Orlix,

the issue is also opened here: https://github.com/goharbor/harbor/issues/16718.

Greetings,

Gábor

Dear Community,

pushing an OCI image index similar to the below one fails:

cat oci-image-index.json

{

    "schemaVersion": 2,

    "mediaType": "application/vnd.oci.image.index.v1+json",

    "manifests": [ {

        "mediaType": "application/vnd.oci.image.manifest.v1+json",

        "digest": "sha256:368fdd22c21f62f93c3d9bdbb0f26f8bf13dd984f423b174dc1ec1967e1b8a58",

        "size": 583,

        "annotations": {

            "org.opencontainers.image.ref.name": "project/a/b/c/kubectl:v1.23.1"

        }

    },{

        "mediaType": "application/vnd.oci.image.manifest.v1+json",

        "digest": "sha256:368fdd22c21f62f93c3d9bdbb0f26f8bf13dd984f423b174dc1ec1967e1b8a58",

        "size": 583,

        "annotations": {

            "org.opencontainers.image.ref.name": "project/c/d/e/kubectl:v1.23.1"

        }

    }],

    "annotations": {

        "org.opencontainers.image.created": "2022-04-14T09:14:00.000000Z"

    }

}

curl -k -u ... -X PUT -H ... -d @oci-image-index.json https://$HARBOR_REGISTRY/v2/$PROJECT/$REPOSITORY/manifests/$TAG

{

  "errors": [

    {

      "code": "NOT_FOUND",

      "message": "artifact .../.../...@sha256:ef52a37a715e1fc601a3488e42a08a48e9c16e9e001cd5cecf70b5bf01f04501 not found"

    }

  ]

}

The error is caused by the two manifests referring to the the same image manifest.

To me, this seems like a bug. Rationale: image index (“fat manifest”) is originally meant for multi-platform support. With this in mind, it seems valid to have the same image for two different platforms, say only differing in their name.

The root cause of the error seems to be this database constraint (postgresql/0030_2.0.0_schema.up.sql):

CREATE TABLE artifact_reference

(

  id          SERIAL PRIMARY KEY NOT NULL,

  parent_id   int NOT NULL,

  child_id    int NOT NULL,

  child_digest varchar(255) NOT NULL ,

  platform    varchar(255),

  urls        varchar(1024),

  annotations jsonb,

  FOREIGN KEY (parent_id) REFERENCES artifact(id),

  FOREIGN KEY (child_id) REFERENCES artifact(id),

  CONSTRAINT  unique_reference UNIQUE (parent_id, child_id)

);

A possible fix could be to add platform and annotations to the uniquness set:

CREATE TABLE artifact_reference

(

  ...

  CONSTRAINT  unique_reference UNIQUE (parent_id, child_id, platform, annotations)

);

What do you think about the issue?

KInd regards,

Gábor

Hi, please file github issue with logs, and please also provide harbor version, your configuration, and how did you install harbor.

Thanks,

Yan

Hi Team,

I am getting below error after deploying the certificates signed by Digicert CA.

Error occurred during a connection to ilharbor.xxxx.net. SSL received a record that exceeded the maximum permissible length. Error code: SSL_ERROR_RX_RECORD_TOO_LONG.

All harbor containers are running healthy

Please assist to solve this issues.

Best Regards,

Sujan

See Harbor faq:

https://github.com/goharbor/harbor/wiki/Harbor-FAQs

you could add a ca cert:

1. How to add a CA cert for the LDAP server or other Harbor server?

[A] After installed the Harbor, there is a directory under common/config/shared/trust-certificates Copy the LDAP certificate, for example, ldap_ca.crt to this directory and restart the Harbor, The certificate is added to the trust store of the core container, and then you could enable “Verify Cert” in the LDAP configuration.

Hi,
I have posted a similar post but  not exactly the same question.

My understanding is that whe you create a registry end point , the harbor tries to check the remote certifacte so in your case the docker registry
The help online states that the verify remote cert flag should be unchecked  when remote registry is using a self signed cert, so it might be normal that the connection test is failing.

In my case, i wanted to know if need to configure the harbor with the CA cert of remote registry and how ;
cna you elaborate on what you did  on your habor host