Overview content-prior to operator and author content #5

SteveLasker · 2019-08-24T00:59:54Z

Signed-off-by: Steven Lasker stevenlasker@hotmail.com

Signed-off-by: Steven Lasker <stevenlasker@hotmail.com>

SteveLasker · 2019-08-24T01:10:28Z

Consumes #3 & #4 with overview content that links to the previous commits.

Signed-off-by: Steven Lasker <stevenlasker@hotmail.com>

mikebrow

should avoid checking in logos of other products?

see artifact-layer.png

mikebrow · 2019-08-29T19:22:07Z

README.md

+* [Overview of Registry Content Delivery](#overview-of-registry-content-delivery)
+* [Defining OCI Artifact Types](#defining-oci-artifact-types)
+* [Definitions & Terms](definitions-terms.md)
+* [OCI Artifact Implementations](implementors.md)


see review comments on the implementor's PR

On the logos, what do you suggest here? Can I reference logos, via a URL to their official logo? Do I have to resort to text :(
Can I ask the maintainers of Helm and Singularity to make a PR, this way it's their contribution?
Eventually, for the artifactTypes folder, I was planning on asking artifact authors to submit their logo for general consumption, so they are giving rights to others to use when displaying the type within their registry products & services.

yeah just reference their logo ..

mikebrow · 2019-08-29T19:27:14Z

README.md


-## Table of Contents
+## OCI Artifact Table of Contents


s/OCI Artifact//

mikebrow · 2019-08-29T19:33:33Z

README.md

@@ -19,6 +26,48 @@ By providing an OCI artifact definition, the community can continue to innovate,
 * [Project governance](GOVERNANCE.md)
 * [Release procedures](RELEASES.md)

+## Overview of Registry Content Delivery


I don't think we should define what a registry is in the Artifacts readme. Maybe in a "treatise" document that you could link to from here.

See https://opencontainers.github.io/org/ and the source for it over here: https://github.com/opencontainers/org/tree/master/docs/docs

mikebrow · 2019-08-29T19:41:34Z

README.md

+| [Manifest Schemas](#manifest-schemas) |<img src=./media/manifest-layer.png height=40> |
+| [Artifacts](#artifacts) |<img src=./media/artifact-layer.png height=100> |
+
+### Registry


same comment

mikebrow · 2019-08-29T19:44:32Z

README.md

+
+### Manifest Schemas
+
+For a registry to store collections of content, it must have well known schemas to uniquely describe each content addressable object. The [OCI Manifest][image-manifest] and [OCI Index][image-index] are two well known schemas that implementations of the [OCI Distribution Spec][distribution-spec] MUST support.


yes, but let's not use MUST language here. It's fine in the distribution spec but we should avoid using directive language that applies to a different spec.

s/MUST/must/

mikebrow · 2019-08-29T20:02:03Z

README.md

+
+[Registries][def-registry], vulnerability scanners and artifact tooling must understand the types of artifacts they support. Registry scanning tools may only support a subset of artifact types, or they may need to apply different scanning methods based on the artifact type.
+
+If a security scanning solution were to scan all types, it would fail when it encounters unsupported types, representing false negatives. By differentiating types, a registry scanning solution can ignore unknown types, representing a known state. As new artifact types become [well known][def-well-known-types], scanners can expand the types they offer, providing a more complete known state.


mikebrow · 2019-08-29T20:02:10Z

README.md

+
+If a security scanning solution were to scan all types, it would fail when it encounters unsupported types, representing false negatives. By differentiating types, a registry scanning solution can ignore unknown types, representing a known state. As new artifact types become [well known][def-well-known-types], scanners can expand the types they offer, providing a more complete known state.
+
+Artifact tooling must also know the types they support. The docker and containerD client know how to instance container images. However, they are not intended to instance Helm Charts or Singularity images. By defining the artifact type, registries can present the type to their users, and tools pulling artifacts from a registry can determine if they can support the specific type before encountering a runtime error.


mikebrow · 2019-08-29T20:03:03Z

README.md

+
+Artifact tooling must also know the types they support. The docker and containerD client know how to instance container images. However, they are not intended to instance Helm Charts or Singularity images. By defining the artifact type, registries can present the type to their users, and tools pulling artifacts from a registry can determine if they can support the specific type before encountering a runtime error.
+
+Artifacts are defined by setting the `manifest.config.mediaType` to a globally unique value. The `config.mediaType` of `application/vnd.oci.image.config.v1+json` is reserved for artifacts intended to be instanced by docker and [containerD][containerd].


yes but to much detail for the readme...we should cover this in the spec vs readme..

s/containerD/containerd/

mikebrow · 2019-08-29T20:04:00Z

definitions-terms.md

@@ -0,0 +1,90 @@
+# Definitions and Terms


mikebrow · 2019-08-29T20:04:15Z

implementors.md

@@ -0,0 +1,10 @@
+# OCI Artifacts Implementations


... wrong pr

Signed-off-by: Steven Lasker <stevenlasker@hotmail.com>

push real contents test

mikebrow · 2021-09-23T21:31:33Z

@SteveLasker ping :-)

SteveLasker · 2021-09-23T22:36:43Z

Thanks @mikebrow
this is some cleanup when I was intermixing layered PRs to boot up the artifacts repo.
If this is truly overview content (i need to look closer) then it’s outdated.
There’s some content for localized identifiers for each artifact we want to preserve and another doc for what registries need to do to enable artifacts. It was about loosening the restrictions on the config.mediaTyoe and layer.mediaType.

SteveLasker · 2022-07-05T20:04:12Z

This PR is outdated with various other PRs.

typo fixes

2c116db

Signed-off-by: Steven Lasker <stevenlasker@hotmail.com>

SteveLasker force-pushed the readme-overview branch from 3d572af to 36cf15a Compare August 24, 2019 01:07

SteveLasker force-pushed the readme-overview branch 2 times, most recently from aa82c90 to ff1d345 Compare August 24, 2019 01:34

SteveLasker mentioned this pull request Aug 24, 2019

Proposal: Artifacts TOC #2

Closed

SteveLasker force-pushed the readme-overview branch 2 times, most recently from b7bc1a5 to 7ecb4d0 Compare August 26, 2019 00:23

SteveLasker added 2 commits August 25, 2019 17:53

Add well-known types

e011ec5

Signed-off-by: Steven Lasker <stevenlasker@hotmail.com>

Formating cleanup

d902765

Signed-off-by: Steven Lasker <stevenlasker@hotmail.com>

SteveLasker force-pushed the readme-overview branch from 7ecb4d0 to d902765 Compare August 26, 2019 01:07

SteveLasker added 2 commits August 28, 2019 12:51

Merge definitions and terms

05ca12e

Signed-off-by: Steven Lasker <stevenlasker@hotmail.com>

Merge implementors, def & terms

0b99e43

Signed-off-by: Steven Lasker <stevenlasker@hotmail.com>

mikebrow suggested changes Aug 29, 2019

View reviewed changes

Removed implementors for now

c2e706c

Signed-off-by: Steven Lasker <stevenlasker@hotmail.com>

SteveLasker force-pushed the readme-overview branch from 201c413 to c2e706c Compare October 2, 2019 20:30

jdolitsky added a commit to bloodorangeio/artifacts that referenced this pull request Feb 9, 2021

Merge pull request opencontainers#5 from jdolitsky/add-unit-tests

26918fc

push real contents test

SteveLasker closed this Jul 5, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Overview content-prior to operator and author content #5

Overview content-prior to operator and author content #5

SteveLasker commented Aug 24, 2019

SteveLasker commented Aug 24, 2019

mikebrow left a comment

mikebrow Aug 29, 2019

SteveLasker Aug 30, 2019

mikebrow Jun 10, 2021

mikebrow Aug 29, 2019

mikebrow Aug 29, 2019

mikebrow Aug 29, 2019

mikebrow Aug 29, 2019

mikebrow Aug 29, 2019

mikebrow Aug 29, 2019

mikebrow Aug 29, 2019

mikebrow Aug 29, 2019

mikebrow Aug 29, 2019

mikebrow commented Sep 23, 2021 •

edited

Loading

SteveLasker commented Sep 23, 2021

SteveLasker commented Jul 5, 2022


		### Manifest Schemas

		For a registry to store collections of content, it must have well known schemas to uniquely describe each content addressable object. The [OCI Manifest][image-manifest] and [OCI Index][image-index] are two well known schemas that implementations of the [OCI Distribution Spec][distribution-spec] MUST support.


		[Registries][def-registry], vulnerability scanners and artifact tooling must understand the types of artifacts they support. Registry scanning tools may only support a subset of artifact types, or they may need to apply different scanning methods based on the artifact type.

		If a security scanning solution were to scan all types, it would fail when it encounters unsupported types, representing false negatives. By differentiating types, a registry scanning solution can ignore unknown types, representing a known state. As new artifact types become [well known][def-well-known-types], scanners can expand the types they offer, providing a more complete known state.


		If a security scanning solution were to scan all types, it would fail when it encounters unsupported types, representing false negatives. By differentiating types, a registry scanning solution can ignore unknown types, representing a known state. As new artifact types become [well known][def-well-known-types], scanners can expand the types they offer, providing a more complete known state.

		Artifact tooling must also know the types they support. The docker and containerD client know how to instance container images. However, they are not intended to instance Helm Charts or Singularity images. By defining the artifact type, registries can present the type to their users, and tools pulling artifacts from a registry can determine if they can support the specific type before encountering a runtime error.


		Artifact tooling must also know the types they support. The docker and containerD client know how to instance container images. However, they are not intended to instance Helm Charts or Singularity images. By defining the artifact type, registries can present the type to their users, and tools pulling artifacts from a registry can determine if they can support the specific type before encountering a runtime error.

		Artifacts are defined by setting the `manifest.config.mediaType` to a globally unique value. The `config.mediaType` of `application/vnd.oci.image.config.v1+json` is reserved for artifacts intended to be instanced by docker and [containerD][containerd].

Overview content-prior to operator and author content #5

Overview content-prior to operator and author content #5

Conversation

SteveLasker commented Aug 24, 2019

SteveLasker commented Aug 24, 2019

mikebrow left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mikebrow commented Sep 23, 2021 • edited Loading

SteveLasker commented Sep 23, 2021

SteveLasker commented Jul 5, 2022

mikebrow commented Sep 23, 2021 •

edited

Loading