Skip to content
This repository has been archived by the owner on Jul 18, 2023. It is now read-only.

Added encryption mediatype doc #15

Closed
wants to merge 3 commits into from

Conversation

lumjjb
Copy link

@lumjjb lumjjb commented Mar 5, 2020

Following discussions in opencontainers/image-spec#775, adding details on encrypted mediatype definitions.

Signed-off-by: Brandon Lum [email protected]

encrypted-mediatype.md Outdated Show resolved Hide resolved
encrypted-mediatype.md Outdated Show resolved Hide resolved
@lumjjb lumjjb force-pushed the encryption-mediatype branch from 0f2cfb8 to 2b964a0 Compare March 12, 2020 19:53
@lumjjb
Copy link
Author

lumjjb commented Mar 12, 2020

Thanks for the fixes, @vbatts. Pushed the changes.

@vbatts
Copy link
Member

vbatts commented Feb 5, 2021

@SteveLasker what is the plan for merging things into this artifacts project?

@SteveLasker
Copy link
Contributor

Great question. To be honest, I've been focused on how we add new artifacts, and how we can link artifacts together with reference types, including the reverse lookup pattern. (like Notary, SBoM, GPL, ...) Artifacts PR#27
I see this conversation more about how a specific artifact type (Images) adds new capabilities to their artifact type and schema.
The debate prior to the new year was: how do we add new compression to an existing type, without breaking the existing users.
Happy to expand the artifacts conversation to talk more about it. May a good discussion for next Wednesday?

Copy link
Member

@mikebrow mikebrow left a comment

Choose a reason for hiding this comment

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

LGTM

@mikebrow
Copy link
Member

mikebrow commented Apr 19, 2021

suggest creating an incoming or under-consideration path for artifacts in progress and an approved path for artifacts approved...

this is more a common extension but I'd still put it in the incoming till we push an artifact type to the approved path that has optional / required dependency on this.. and for when we can get approval from the owner of the artifact type that this extension is approved for said type.

@SteveLasker
Copy link
Contributor

suggest creating an incoming or under-consideration path for artifacts in progress and an approved path for artifacts approved...

This is great suggestion.
Reviewing the pr again, this looks like a way to define how encryption can be done on any artifact type.


To be able to protect the confidentiality of the data in layers, encryption of the layer data blobs can be done to prevent unauthorized access to layer data. Encryption is performed on the data blob of a by specifying a media type with the `+encrypted` suffix. For example, `application/vnd.oci.image.layer.v1.tar+encrypted` is an layer representation of an encrypted `application/vnd.oci.image.layer.v1.tar` layer.

## `+encrypted` media type and annotation definitions
Copy link

@jonjohnsonjr jonjohnsonjr Apr 21, 2021

Choose a reason for hiding this comment

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

Defining media types this way does not scale: opencontainers/image-spec#791

Copy link
Member

Choose a reason for hiding this comment

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

nod...

@lumjjb Perhaps you could add an explanation at the top something to the effect that this is a work in progress (WIP) because the + compression/encoding suffix model is not seen as a scaleable model and provide link(s) to the discussion underway. For that matter we could place it in a WIP section.

Copy link
Author

Choose a reason for hiding this comment

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

Agreed on this, I've added the note that the mediatype definition is subject to change.

@lumjjb
Copy link
Author

lumjjb commented May 4, 2021

The PR is updated addressing the comments... Hmm since we were recently discussing this, are there plans to move this forward at the moment?

@SteveLasker
Copy link
Contributor

@lumjjb, we've been discussing how we can enable flexibility to the manifests to support versioning within an artifact type.
@justincormack has been proposing #37 as a superset of #29 to address these types of needs.
Can I suggest some 👀 on #37 to get your input for how it may or may not solve encryption capabilities?

@lumjjb
Copy link
Author

lumjjb commented May 4, 2021

Sounds good, i'll take a look at #37

@jonjohnsonjr
Copy link

@justincormack has been proposing #37 as a superset of #29 to address these types of needs.

That's not what superset means

@mikebrow
Copy link
Member

FYI artifacts mission is moving to opencontainers/image-spec this repo is being archived.

@mikebrow
Copy link
Member

closing for now due to pending archive action.. pls reopen if archive is not completed and/or if you believe this close to be in error

@mikebrow mikebrow closed this Jul 17, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants