Bug 1779355 - Verify outgoing manifests when uploading or creating new manifests [NEEDINFO]
Summary: Verify outgoing manifests when uploading or creating new manifests
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: oc
Version: 4.2.z
Hardware: Unspecified
OS: Unspecified
low
high
Target Milestone: ---
: 4.2.z
Assignee: Clayton Coleman
QA Contact: zhou ying
URL:
Whiteboard: LifecycleStale
Depends On: 1779351 1779353
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-12-03 19:52 UTC by Clayton Coleman
Modified: 2020-11-18 14:04 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1779353
Environment:
Last Closed: 2020-11-18 14:04:06 UTC
Target Upstream Version:
Embargoed:
mfojtik: needinfo?


Attachments (Terms of Use)

Description Clayton Coleman 2019-12-03 19:52:38 UTC
+++ This bug was initially created as a clone of Bug #1779353 +++

+++ This bug was initially created as a clone of Bug #1779351 +++

To better catch failures due to misbehaving or faulty registries, the verifying manifest service used by image and release tooling should verify outgoing manifests (as well as incoming manifests) by digest.

This is acceptable now that we require schema2 container image registry support for our release tooling, and helps close another possible failure point by verifying what we send matches what the server tells us it gets.

Comment 1 Maciej Szulik 2020-05-04 14:33:18 UTC
This was fixed in versions 4.3 and newer.

Comment 2 Michal Fojtik 2020-11-18 10:12:09 UTC
This bug hasn't had any activity in the last 30 days. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're marking this bug as "LifecycleStale" and decreasing the severity/priority. If you have further information on the current state of the bug, please update it, otherwise this bug can be closed in about 7 days. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. Additionally, you can add LifecycleFrozen into Keywords if you think this bug should never be marked as stale. Please consult with bug assignee before you do that.


Note You need to log in before you can comment on or make changes to this bug.