Skip to content
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

cmd/oci-image-tool: validate all refs by default #279

Merged
merged 1 commit into from
Sep 13, 2016

Conversation

runcom
Copy link
Member

@runcom runcom commented Sep 8, 2016

This is taking care of #271 (comment) (left a TODO/FIXME for later in case).

I'll adapt everything to be same as per #266 later

$ oci-image-tool validate /home/amurdaca/src/github.com/projectatomic/skopeo/busybox-oci2
reference "12.04": OK
reference "3.1": OK
reference "a59906e33509d14c036c8678d687bd4eec81ed7c4b8ce907b888c607f6a1e0e6": OK
reference "latest": OK
reference "notlatest": OK
reference "tag": OK
/home/amurdaca/src/github.com/projectatomic/skopeo/busybox-oci2: OK

/cc @wking @vbatts @philips @stevvooe

Signed-off-by: Antonio Murdaca [email protected]

@@ -49,6 +49,30 @@ func (d *descriptor) hash() string {
return pts[1]
}

func findDescriptors(w walker) (map[string]*descriptor, error) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe listReferences? In #159, the analogous function is refs.Engine.List().

@wking
Copy link
Contributor

wking commented Sep 8, 2016

On Thu, Sep 08, 2016 at 06:52:45AM -0700, Antonio Murdaca wrote:

-- File Changes --

M cmd/oci-image-tool/validate.go (2)
M image/descriptor.go (24)
M image/image.go (30)

Update the man page too.

@stevvooe
Copy link
Contributor

stevvooe commented Sep 8, 2016

@runcom If unknown types are encountered, what is the intended behavior?

I ask because we do need to be able to have references to unknown things but still pass validation. This will make it easier to extend in the future.

@wking
Copy link
Contributor

wking commented Sep 8, 2016

On Thu, Sep 08, 2016 at 12:47:36PM -0700, Stephen Day wrote:

@runcom If unknown types are encountered, what is the intended behavior?

I think we need to error with “not implemented”-level errors.

I ask because we do need to be able to have references to unknown
things but still pass validation. This will make it easier to extend
in the future.

That makes sense. We might want an --ignore-unknown-media-types flag
to avoid erroring out if we hit an unrecognized type. There's some
more discussion of unrecognized types in 1.

What happens if you recognize the ref type
(e.g. application/vnd.oci.image.manifest.list.v1+json) but not an
-ancestor- [edit: descendant] type (e.g. application/vnd.oci.image.layer.zip) and
--ignore-unknown-media-types is set? Do you print your warning and
return zero? Or is the error→warning softening only for the root
refs? We can have a global error→warning softening and still error
for the application/vnd.oci.image.layer.zip case if the specs for our
objects explicitly list allowed descriptor types [2,3].

@stevvooe
Copy link
Contributor

stevvooe commented Sep 8, 2016

@wking I was asking @runcom. It's okay to let a conversation develop before commenting.

@wking
Copy link
Contributor

wking commented Sep 8, 2016

On Thu, Sep 08, 2016 at 01:00:21PM -0700, Stephen Day wrote:

It's okay to let a conversation develop before commenting.

Sure. I was just linking in previous unrecognized-type discussion to
try and avoid a fragmented discussion of that issue.

@runcom
Copy link
Member Author

runcom commented Sep 8, 2016

@stevvooe right now, if the media type is unknown the tool errors out. We should at least soften that to just print a warning. This behavior is in the validate function though, I can address this in a follow up and discuss more about errors/warnings if it's ok for you, this PR just makes sure we "find" every reference under refs/ to shorten the command line flags.

@wking
Copy link
Contributor

wking commented Sep 8, 2016

On Thu, Sep 08, 2016 at 01:58:18PM -0700, Antonio Murdaca wrote:

This behavior is in the validate function though, I can address
this in a follow up and discuss more about errors/warnings if it's
ok for you, this PR just makes sure we "find" every reference under
refs/ to shorten the command line flags.

I'm fine punting unrecognized media type issues to follow up work,
since that is an orthogonal problem (this PR just increases the
likelyhood that we find unrecognized types).

@stevvooe
Copy link
Contributor

stevvooe commented Sep 8, 2016

@runcom SGTM. Please open an issue.

@runcom
Copy link
Member Author

runcom commented Sep 9, 2016

@stevvooe @vbatts @philips PTAL

@philips
Copy link
Contributor

philips commented Sep 12, 2016

LGTM.

@s-urbaniak ?

Approved with PullApprove

@stevvooe
Copy link
Contributor

stevvooe commented Sep 12, 2016

LGTM

Approved with PullApprove

@@ -33,7 +34,7 @@ func ValidateLayout(src string, refs []string, out *log.Logger) error {

// Validate walks through the given .tar file and
// validates the manifest pointed to by the given refs
// or returns an error if the validation failed.
//iiii or returns an error if the validation failed.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

iiii? ;-)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lol

@s-urbaniak
Copy link
Collaborator

LGTM, with one small nit

@philips
Copy link
Contributor

philips commented Sep 13, 2016

LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants