Bug 1939361

Summary:	no signatures for redhat-operator-index
Product:	OpenShift Container Platform	Reporter:	peter ducai <pducai>
Component:	OLM	Assignee:	tflannag
OLM sub component:	OperatorHub	QA Contact:	Jian Zhang <jiazha>
Status:	CLOSED DUPLICATE	Docs Contact:
Severity:	high
Priority:	high	CC:	tflannag
Version:	4.7
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-03-16 19:17:37 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description peter ducai 2021-03-16 08:44:45 UTC

Description of problem:

When running

skopeo copy docker://registry.redhat.io/redhat/redhat-operator-index:v4.7 dir:redhat-operator-index"

I notice that no signatures are downloaded. If I use eg. ubi8/ubi-minimal I get signatures, so I know the command will retrieve signatures for registry.redhat.io if available.

I'm using this image to setup a disconnected mirror of the operator catalog. This contains the file /database/index.db which contains the sha256 of all the containers in the offline mirror. In the disconnected environment my plan was to validate that redhat-operator-index:v4.7 was signed by Red Hat, therefore I can trust all the sha256 of the operators listed within /database/index.db.


Additional info:

Unless this container is properly signed by Red Hat, how can I trust the mirrored operators in the disconnected environment? I note for mirroring the OpenShift release itself, a signature is provided of the release container, which in turn contains the SHA256 of all the components.



PS: could this be related to https://bugzilla.redhat.com/show_bug.cgi?id=1917292 ?

Comment 1 tflannag 2021-03-16 19:17:37 UTC

It looks like this is a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1903632, which essentially is tracking the effort to sign the production index images.

OLM isn't the team that controls the release of those images but just serves as the component that digests them.

It doesn't look like this is affecting cluster upgrades from the initial description, but if it is, then I would recommend going through that BZ I linked and seeing if the workaround described there is appropriate.

*** This bug has been marked as a duplicate of bug 1903632 ***