layers: describe policy enforcement for foreign layer media type by stevvooe · Pull Request #233 · opencontainers/image-spec (original) (raw)

On Tue, Sep 06, 2016 at 01:58:50PM -0700, Stephen Walli wrote:

While it might be difficult to write a test to prove the MUST NOT,
if an implementation was demonstrated to distribute such a layer, it
clearly doesn't do what the specification says, and would not be
able to claim conformance/compliance. Likewise, for a certification
process, one can design the process to manual test such a thing or
to use the condition to revoke a certification until the
implementation complies.

“Yeah, automatically testing that would be hard, but we can manually
test it” is a marker for a wishy definition 1. I think the problem
here is that “distributing” is not something that one instance can do
by itself. If it's pushing a blob, someone else must be receiving it.
In some cases (e.g. pushing to a local disk on a single-user system),
that probably doesn't count as “distributing” in a legal sense. In
others (e.g. pushing to a public repo on hub.docker.com) it does.
Where does caching to disk on a multi-user system fall in that
continuum? Are you distributing it by saving to a system-readabale
cache? Or is it only distributing if another user on the system reads
it out of that cache? If that system-readable cache happens to live
under your home directory, are you being robbed (and not distributing)
when the other user reads the file?

I imagine there are consensus opinions on at least some of that
(although I'm not aware of them). I don't think we want to make it
the business of spec implementers and validators to independently
figure out what those opinions are. If there are conditions under
which you would certify (or not) an implementation, I'd like to see
those conditions spelled out in the spec in enough detail for them to
be objectively tested without appealing to “The average person,
applying local community standards, looking at the work in its
entirety” and such. In some cases, that wishyness is unavoidable.
But we need something more solid if we're expecting implementation
software to act consistently based on a ‘foreign’ boolean.

One option would be to have a CAS engine API (e.g. #159) where the
public/private-ness of the engine was part of its initialization.
E.g.:

casEngine, err := NewEngine(ctx, path, public)

Then the engine is non-compliant if you can successfully:

casEngine.Put(ctx, reader, mediaType)

with a foreign mediaType (this is testable by the OCI). And the
engine-initializer is breaking the law if they create a CAS engine
pointing at a public hub.docker.com repo and claiming it is not public
(this is between the CAS engine configurer and the copyright holders
of the pushed content, and not something the OCI has to certify).