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

validation requires a network connection #499

Open
cyphar opened this issue Oct 26, 2017 · 7 comments
Open

validation requires a network connection #499

cyphar opened this issue Oct 26, 2017 · 7 comments

Comments

@cyphar
Copy link
Member

cyphar commented Oct 26, 2017

At the moment, oci-runtime-tool validate attempts to fetch https://raw.githubusercontent.com/opencontainers/runtime-spec/v1.0.0/schema/config-schema.json. This is a problem if you want to do validation without having access to the network (and it's also a concern with distributions that would prefer to be able to package the schema somewhere). There are two ways I can see that we deal with this problem:

  • Just include the json file in the source code, so that it's baked into each binary. Obviously this has the downside that you can't test against future versions of the runtime-spec -- but ultimately we do a lot of validation outside of the json so it's of questionable use to be able to test future versions partially. This is what image-tools does (but the data is stored in the upstream image-spec repo).

  • Have some local cache (something like /usr/share/oci/runtime-tool/schemas/vXYZ.json) that is used if available, otherwise the schema is downloaded (and saved there if we have enough permissions). This is more fallback-friendly, and still has the "future versions" feature, but it's also kinda clunky in some senses.

@liangchenye
Copy link
Member

I think future version is not a problem, runtime tool can not and should not guarantee it will support the future version. To me, the problem is 'how can we get schema files'.

We won't have this problem if we release runtime-tools as the rpm package.
We can put json files to rpm package, so when a user install it, he/she can have both a binary and a couple of data files. But now we only have a binary file if we get the runtime-tools by go get :(

So +1 for your second proposal, maybe we should add a new command like

    oci-runtime-tool init

so all the required data could be installed in the right place.

@cyphar
Copy link
Member Author

cyphar commented Oct 26, 2017

We won't have this problem if we release runtime-tools as the rpm package.

Well, we already do this in openSUSE -- and I use the validation suite as part of umoci's test suite. 😉

My issue with the second proposal is that it's not consistent with how oci-image-tools works, and also it feels more clunky than just including the schema inside the Go binary itself. oci-image-tools does this by having a in-memory "filesystem" which is generated using the tool "esc".

@wking
Copy link
Contributor

wking commented Oct 26, 2017 via email

@cyphar
Copy link
Member Author

cyphar commented Oct 26, 2017

@wking I don't personally agree with the decision to not use esc in #197 (requiring a network for a file which is going to be static for any given version of the spec doesn't make any sense to me -- having it hard-coded into the binary makes more sense, at least as a default). Maybe if we just did something simpler like generate a const string which contains the JSON and is then parsed by gojsonschema would be nicer? If we go with that, I'd like to match the change in image-spec (for consistency reasons).

As for $XDG_DATA_DIRS, I'd still want an explicit global fallback in case a user sets $XDG_DATA_DIRS to something silly. Also a matching change in image-tools (this inconsistency between tools that are maintained by similar groups of people is a little worrying).

@wking
Copy link
Contributor

wking commented Oct 26, 2017 via email

@cyphar
Copy link
Member Author

cyphar commented Oct 26, 2017

I think the long-term goal is to be able to test against multiple spec versions.

I'm not sure that this is something that makes a lot of sense to do "automatically" by just downloading a schema file from the internet and then trusting that the validation is correct. There's already a lot of additional checking we do in validate.go -- checking that might not be version-independent and is definitely not part of the schema we are downloading.

If we want to validate against multiple spec versions, we should curate which versions we test against (to make sure that we don't provide incorrect results for a spec version we didn't test an old version against -- after all this tooling is going to be part of the conformance testing eventually from what I understand).

You're right that we can do "preliminary checking" but I honestly don't see what the benefit is. It feels like it would be more confusing than it is helpful.

@wking
Copy link
Contributor

wking commented Oct 26, 2017 via email

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

No branches or pull requests

3 participants