├── CODEOWNERS ├── CONTRIBUTING.md ├── GOVERNANCE.md ├── LICENSE ├── MAINTAINERS ├── MAINTAINERS_GUIDE.md ├── README.md ├── RELEASES.md ├── artifact-authors.md ├── definitions-terms.md ├── implementers.md └── media ├── artifacts-spec-objects.png └── image-spec-objects.png /CODEOWNERS: -------------------------------------------------------------------------------- 1 | * @dmcgowan @josephschorr @mikebrow @stevelasker @stevvooe 2 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contribution Guidelines 2 | 3 | Development happens on GitHub. 4 | Issues are used for bugs and actionable items and longer discussions can happen on the [mailing list](#mailing-list). 5 | 6 | The content of this repository is licensed under the [Apache License, Version 2.0](LICENSE). 7 | 8 | ## Code of Conduct 9 | 10 | Participation in the Open Container community is governed by [Open Container Code of Conduct][code-of-conduct]. 11 | 12 | ## Meetings 13 | 14 | The contributors and maintainers of all OCI projects have monthly meetings at 2:00 PM (USA Pacific) on the first Wednesday of every month. 15 | There is an [iCalendar][rfc5545] format for the meetings [here][meeting.ics]. 16 | Everyone is welcome to participate via [UberConference web][UberConference] or audio-only: +1 415 968 0849 (no PIN needed). 17 | An initial agenda will be posted to the [mailing list](#mailing-list) in the week before each meeting, and everyone is welcome to propose additional topics or suggest other agenda alterations there. 18 | Minutes from past meetings are archived [here][minutes]. 19 | 20 | ## Mailing list 21 | 22 | You can subscribe and browse the mailing list on [Google Groups][mailing-list]. 23 | 24 | ## IRC 25 | 26 | OCI discussion happens on #opencontainers on [Freenode][] ([logs][irc-logs]). 27 | 28 | ## Git 29 | 30 | ### Security issues 31 | 32 | If you are reporting a security issue, do not create an issue or file a pull 33 | request on GitHub. Instead, disclose the issue responsibly by sending an email 34 | to security@opencontainers.org (which is inhabited only by the maintainers of 35 | the various OCI projects). 36 | 37 | ### Pull requests are always welcome 38 | 39 | We are always thrilled to receive pull requests, and do our best to 40 | process them as fast as possible. Not sure if that typo is worth a pull 41 | request? Do it! We will appreciate it. 42 | 43 | If your pull request is not accepted on the first try, don't be 44 | discouraged! If there's a problem with the implementation, hopefully you 45 | received feedback on what to improve. 46 | 47 | We're trying very hard to keep the project lean and focused. We don't want it 48 | to do everything for everybody. This means that we might decide against 49 | incorporating a new feature. 50 | 51 | ### Conventions 52 | 53 | Fork the repo and make changes on your fork in a feature branch. 54 | For larger bugs and enhancements, consider filing a leader issue or mailing-list thread for discussion that is independent of the implementation. 55 | Small changes or changes that have been discussed on the [project mailing list](#mailing-list) may be submitted without a leader issue. 56 | 57 | If the project has a test suite, submit unit tests for your changes. Take a 58 | look at existing tests for inspiration. Run the full test suite on your branch 59 | before submitting a pull request. 60 | 61 | Update the documentation when creating or modifying features. Test 62 | your documentation changes for clarity, concision, and correctness, as 63 | well as a clean documentation build. 64 | 65 | Pull requests descriptions should be as clear as possible and include a 66 | reference to all the issues that they address. 67 | 68 | Commit messages must start with a capitalized and short summary 69 | written in the imperative, followed by an optional, more detailed 70 | explanatory text which is separated from the summary by an empty line. 71 | 72 | Code review comments may be added to your pull request. Discuss, then make the 73 | suggested modifications and push additional commits to your feature branch. Be 74 | sure to post a comment after pushing. The new commits will show up in the pull 75 | request automatically, but the reviewers will not be notified unless you 76 | comment. 77 | 78 | Before the pull request is merged, make sure that you squash your commits into 79 | logical units of work using `git rebase -i` and `git push -f`. After every 80 | commit the test suite (if any) should be passing. Include documentation changes 81 | in the same commit so that a revert would remove all traces of the feature or 82 | fix. 83 | 84 | Commits that fix or close an issue should include a reference like `Closes #XXX` 85 | or `Fixes #XXX`, which will automatically close the issue when merged. 86 | 87 | ### Sign your work 88 | 89 | The sign-off is a simple line at the end of the explanation for the 90 | patch, which certifies that you wrote it or otherwise have the right to 91 | pass it on as an open-source patch. The rules are pretty simple: if you 92 | can certify the below (from [developercertificate.org][]): 93 | 94 | ``` 95 | Developer Certificate of Origin 96 | Version 1.1 97 | 98 | Copyright (C) 2004, 2006 The Linux Foundation and its contributors. 99 | 1 Letterman Drive 100 | Suite D4700 101 | San Francisco, CA, 94129 102 | 103 | Everyone is permitted to copy and distribute verbatim copies of this 104 | license document, but changing it is not allowed. 105 | 106 | 107 | Developer's Certificate of Origin 1.1 108 | 109 | By making a contribution to this project, I certify that: 110 | 111 | (a) The contribution was created in whole or in part by me and I 112 | have the right to submit it under the open source license 113 | indicated in the file; or 114 | 115 | (b) The contribution is based upon previous work that, to the best 116 | of my knowledge, is covered under an appropriate open source 117 | license and I have the right under that license to submit that 118 | work with modifications, whether created in whole or in part 119 | by me, under the same open source license (unless I am 120 | permitted to submit under a different license), as indicated 121 | in the file; or 122 | 123 | (c) The contribution was provided directly to me by some other 124 | person who certified (a), (b) or (c) and I have not modified 125 | it. 126 | 127 | (d) I understand and agree that this project and the contribution 128 | are public and that a record of the contribution (including all 129 | personal information I submit with it, including my sign-off) is 130 | maintained indefinitely and may be redistributed consistent with 131 | this project or the open source license(s) involved. 132 | ``` 133 | 134 | then you just add a line to every git commit message: 135 | 136 | Signed-off-by: Joe Smith 137 | 138 | using your real name (sorry, no pseudonyms or anonymous contributions.) 139 | 140 | You can add the sign off when creating the git commit via `git commit -s`. 141 | 142 | [code-of-conduct]: https://github.com/opencontainers/tob/blob/d2f9d68c1332870e40693fe077d311e0742bc73d/code-of-conduct.md 143 | [developercertificate.org]: http://developercertificate.org/ 144 | [Freenode]: https://freenode.net/ 145 | [irc-logs]: http://ircbot.wl.linuxfoundation.org/eavesdrop/%23opencontainers/ 146 | [mailing-list]: https://groups.google.com/a/opencontainers.org/forum/#!forum/dev 147 | [meeting.ics]: https://github.com/opencontainers/runtime-spec/blob/master/meeting.ics 148 | [minutes]: http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/ 149 | [rfc5545]: https://tools.ietf.org/html/rfc5545 150 | [UberConference]: https://www.uberconference.com/opencontainers 151 | -------------------------------------------------------------------------------- /GOVERNANCE.md: -------------------------------------------------------------------------------- 1 | # Project governance 2 | 3 | The [OCI charter][charter] §5.b.viii tasks an OCI Project's maintainers (listed in the repository's MAINTAINERS file and sometimes referred to as "the TDC", [§5.e][charter]) with: 4 | 5 | > Creating, maintaining and enforcing governance guidelines for the TDC, approved by the maintainers, and which shall be posted visibly for the TDC. 6 | 7 | This section describes generic rules and procedures for fulfilling that mandate. 8 | 9 | ## Proposing a motion 10 | 11 | A maintainer SHOULD propose a motion on the dev@opencontainers.org mailing list (except [security issues](#security-issues)) with another maintainer as a co-sponsor. 12 | 13 | ## Voting 14 | 15 | Voting on a proposed motion SHOULD happen on the dev@opencontainers.org mailing list (except [security issues](#security-issues)) with maintainers posting LGTM or REJECT. 16 | Maintainers MAY also explicitly not vote by posting ABSTAIN (which is useful to revert a previous vote). 17 | Maintainers MAY post multiple times (e.g. as they revise their position based on feedback), but only their final post counts in the tally. 18 | A proposed motion is adopted if two-thirds of votes cast, a quorum having voted, are in favor of the release. 19 | 20 | Voting SHOULD remain open for a week to collect feedback from the wider community and allow the maintainers to digest the proposed motion. 21 | Under exceptional conditions (e.g. non-major security fix releases) proposals which reach quorum with unanimous support MAY be adopted earlier. 22 | 23 | A maintainer MAY choose to reply with REJECT. 24 | A maintainer posting a REJECT MUST include a list of concerns or links to written documentation for those concerns (e.g. GitHub issues or mailing-list threads). 25 | The maintainers SHOULD try to resolve the concerns and wait for the rejecting maintainer to change their opinion to LGTM. 26 | However, a motion MAY be adopted with REJECTs, as outlined in the previous paragraphs. 27 | 28 | ## Quorum 29 | 30 | A quorum is established when at least two-thirds of maintainers have voted. 31 | 32 | For projects that are not specifications, a [motion to release](#release-approval) MAY be adopted if the tally is at least three LGTMs and no REJECTs, even if three votes does not meet the usual two-thirds quorum. 33 | 34 | ## Amendments 35 | 36 | The [project governance](#project-governance) rules and procedures MAY be amended or replaced using the procedures themselves. 37 | The MAINTAINERS of this project governance document is the total set of MAINTAINERS from all Open Containers projects (go-digest, image-spec, image-tools, runC, runtime-spec, runtime-tools, and selinux). 38 | 39 | ## Subject templates 40 | 41 | Maintainers are busy and get lots of email. 42 | To make project proposals recognizable, proposed motions SHOULD use the following subject templates. 43 | 44 | ### Proposing a motion 45 | 46 | > [{project} VOTE]: {motion description} (closes {end of voting window}) 47 | 48 | For example: 49 | 50 | > [runtime-spec VOTE]: Tag 0647920 as 1.0.0-rc (closes 2016-06-03 20:00 UTC) 51 | 52 | ### Tallying results 53 | 54 | After voting closes, a maintainer SHOULD post a tally to the motion thread with a subject template like: 55 | 56 | > [{project} {status}]: {motion description} (+{LGTMs} -{REJECTs} #{ABSTAINs}) 57 | 58 | Where `{status}` is either `adopted` or `rejected`. 59 | For example: 60 | 61 | > [runtime-spec adopted]: Tag 0647920 as 1.0.0-rc (+6 -0 #3) 62 | 63 | [charter]: https://www.opencontainers.org/about/governance 64 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Apache License 2 | Version 2.0, January 2004 3 | http://www.apache.org/licenses/ 4 | 5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 6 | 7 | 1. Definitions. 8 | 9 | "License" shall mean the terms and conditions for use, reproduction, 10 | and distribution as defined by Sections 1 through 9 of this document. 11 | 12 | "Licensor" shall mean the copyright owner or entity authorized by 13 | the copyright owner that is granting the License. 14 | 15 | "Legal Entity" shall mean the union of the acting entity and all 16 | other entities that control, are controlled by, or are under common 17 | control with that entity. For the purposes of this definition, 18 | "control" means (i) the power, direct or indirect, to cause the 19 | direction or management of such entity, whether by contract or 20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 21 | outstanding shares, or (iii) beneficial ownership of such entity. 22 | 23 | "You" (or "Your") shall mean an individual or Legal Entity 24 | exercising permissions granted by this License. 25 | 26 | "Source" form shall mean the preferred form for making modifications, 27 | including but not limited to software source code, documentation 28 | source, and configuration files. 29 | 30 | "Object" form shall mean any form resulting from mechanical 31 | transformation or translation of a Source form, including but 32 | not limited to compiled object code, generated documentation, 33 | and conversions to other media types. 34 | 35 | "Work" shall mean the work of authorship, whether in Source or 36 | Object form, made available under the License, as indicated by a 37 | copyright notice that is included in or attached to the work 38 | (an example is provided in the Appendix below). 39 | 40 | "Derivative Works" shall mean any work, whether in Source or Object 41 | form, that is based on (or derived from) the Work and for which the 42 | editorial revisions, annotations, elaborations, or other modifications 43 | represent, as a whole, an original work of authorship. For the purposes 44 | of this License, Derivative Works shall not include works that remain 45 | separable from, or merely link (or bind by name) to the interfaces of, 46 | the Work and Derivative Works thereof. 47 | 48 | "Contribution" shall mean any work of authorship, including 49 | the original version of the Work and any modifications or additions 50 | to that Work or Derivative Works thereof, that is intentionally 51 | submitted to Licensor for inclusion in the Work by the copyright owner 52 | or by an individual or Legal Entity authorized to submit on behalf of 53 | the copyright owner. For the purposes of this definition, "submitted" 54 | means any form of electronic, verbal, or written communication sent 55 | to the Licensor or its representatives, including but not limited to 56 | communication on electronic mailing lists, source code control systems, 57 | and issue tracking systems that are managed by, or on behalf of, the 58 | Licensor for the purpose of discussing and improving the Work, but 59 | excluding communication that is conspicuously marked or otherwise 60 | designated in writing by the copyright owner as "Not a Contribution." 61 | 62 | "Contributor" shall mean Licensor and any individual or Legal Entity 63 | on behalf of whom a Contribution has been received by Licensor and 64 | subsequently incorporated within the Work. 65 | 66 | 2. Grant of Copyright License. Subject to the terms and conditions of 67 | this License, each Contributor hereby grants to You a perpetual, 68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 69 | copyright license to reproduce, prepare Derivative Works of, 70 | publicly display, publicly perform, sublicense, and distribute the 71 | Work and such Derivative Works in Source or Object form. 72 | 73 | 3. Grant of Patent License. Subject to the terms and conditions of 74 | this License, each Contributor hereby grants to You a perpetual, 75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 76 | (except as stated in this section) patent license to make, have made, 77 | use, offer to sell, sell, import, and otherwise transfer the Work, 78 | where such license applies only to those patent claims licensable 79 | by such Contributor that are necessarily infringed by their 80 | Contribution(s) alone or by combination of their Contribution(s) 81 | with the Work to which such Contribution(s) was submitted. If You 82 | institute patent litigation against any entity (including a 83 | cross-claim or counterclaim in a lawsuit) alleging that the Work 84 | or a Contribution incorporated within the Work constitutes direct 85 | or contributory patent infringement, then any patent licenses 86 | granted to You under this License for that Work shall terminate 87 | as of the date such litigation is filed. 88 | 89 | 4. Redistribution. You may reproduce and distribute copies of the 90 | Work or Derivative Works thereof in any medium, with or without 91 | modifications, and in Source or Object form, provided that You 92 | meet the following conditions: 93 | 94 | (a) You must give any other recipients of the Work or 95 | Derivative Works a copy of this License; and 96 | 97 | (b) You must cause any modified files to carry prominent notices 98 | stating that You changed the files; and 99 | 100 | (c) You must retain, in the Source form of any Derivative Works 101 | that You distribute, all copyright, patent, trademark, and 102 | attribution notices from the Source form of the Work, 103 | excluding those notices that do not pertain to any part of 104 | the Derivative Works; and 105 | 106 | (d) If the Work includes a "NOTICE" text file as part of its 107 | distribution, then any Derivative Works that You distribute must 108 | include a readable copy of the attribution notices contained 109 | within such NOTICE file, excluding those notices that do not 110 | pertain to any part of the Derivative Works, in at least one 111 | of the following places: within a NOTICE text file distributed 112 | as part of the Derivative Works; within the Source form or 113 | documentation, if provided along with the Derivative Works; or, 114 | within a display generated by the Derivative Works, if and 115 | wherever such third-party notices normally appear. The contents 116 | of the NOTICE file are for informational purposes only and 117 | do not modify the License. You may add Your own attribution 118 | notices within Derivative Works that You distribute, alongside 119 | or as an addendum to the NOTICE text from the Work, provided 120 | that such additional attribution notices cannot be construed 121 | as modifying the License. 122 | 123 | You may add Your own copyright statement to Your modifications and 124 | may provide additional or different license terms and conditions 125 | for use, reproduction, or distribution of Your modifications, or 126 | for any such Derivative Works as a whole, provided Your use, 127 | reproduction, and distribution of the Work otherwise complies with 128 | the conditions stated in this License. 129 | 130 | 5. Submission of Contributions. Unless You explicitly state otherwise, 131 | any Contribution intentionally submitted for inclusion in the Work 132 | by You to the Licensor shall be under the terms and conditions of 133 | this License, without any additional terms or conditions. 134 | Notwithstanding the above, nothing herein shall supersede or modify 135 | the terms of any separate license agreement you may have executed 136 | with Licensor regarding such Contributions. 137 | 138 | 6. Trademarks. This License does not grant permission to use the trade 139 | names, trademarks, service marks, or product names of the Licensor, 140 | except as required for reasonable and customary use in describing the 141 | origin of the Work and reproducing the content of the NOTICE file. 142 | 143 | 7. Disclaimer of Warranty. Unless required by applicable law or 144 | agreed to in writing, Licensor provides the Work (and each 145 | Contributor provides its Contributions) on an "AS IS" BASIS, 146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 147 | implied, including, without limitation, any warranties or conditions 148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 149 | PARTICULAR PURPOSE. You are solely responsible for determining the 150 | appropriateness of using or redistributing the Work and assume any 151 | risks associated with Your exercise of permissions under this License. 152 | 153 | 8. Limitation of Liability. In no event and under no legal theory, 154 | whether in tort (including negligence), contract, or otherwise, 155 | unless required by applicable law (such as deliberate and grossly 156 | negligent acts) or agreed to in writing, shall any Contributor be 157 | liable to You for damages, including any direct, indirect, special, 158 | incidental, or consequential damages of any character arising as a 159 | result of this License or out of the use or inability to use the 160 | Work (including but not limited to damages for loss of goodwill, 161 | work stoppage, computer failure or malfunction, or any and all 162 | other commercial damages or losses), even if such Contributor 163 | has been advised of the possibility of such damages. 164 | 165 | 9. Accepting Warranty or Additional Liability. While redistributing 166 | the Work or Derivative Works thereof, You may choose to offer, 167 | and charge a fee for, acceptance of support, warranty, indemnity, 168 | or other liability obligations and/or rights consistent with this 169 | License. However, in accepting such obligations, You may act only 170 | on Your own behalf and on Your sole responsibility, not on behalf 171 | of any other Contributor, and only if You agree to indemnify, 172 | defend, and hold each Contributor harmless for any liability 173 | incurred by, or claims asserted against, such Contributor by reason 174 | of your accepting any such warranty or additional liability. 175 | 176 | END OF TERMS AND CONDITIONS 177 | 178 | APPENDIX: How to apply the Apache License to your work. 179 | 180 | To apply the Apache License to your work, attach the following 181 | boilerplate notice, with the fields enclosed by brackets "{}" 182 | replaced with your own identifying information. (Don't include 183 | the brackets!) The text should be enclosed in the appropriate 184 | comment syntax for the file format. We also recommend that a 185 | file or class name and description of purpose be included on the 186 | same "printed page" as the copyright notice for easier 187 | identification within third-party archives. 188 | 189 | Copyright {yyyy} {name of copyright owner} 190 | 191 | Licensed under the Apache License, Version 2.0 (the "License"); 192 | you may not use this file except in compliance with the License. 193 | You may obtain a copy of the License at 194 | 195 | http://www.apache.org/licenses/LICENSE-2.0 196 | 197 | Unless required by applicable law or agreed to in writing, software 198 | distributed under the License is distributed on an "AS IS" BASIS, 199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 200 | See the License for the specific language governing permissions and 201 | limitations under the License. 202 | -------------------------------------------------------------------------------- /MAINTAINERS: -------------------------------------------------------------------------------- 1 | + Steve Lasker (@stevelasker) 2 | + Derek McGowan (@dmcgowan) 3 | + Mike Brown (@mikebrow) 4 | + Stephen Day (@stevvooe) 5 | + Joey Schorr (@josephschorr) 6 | -------------------------------------------------------------------------------- /MAINTAINERS_GUIDE.md: -------------------------------------------------------------------------------- 1 | ## Introduction 2 | 3 | Dear maintainer. Thank you for investing the time and energy to help 4 | make this project as useful as possible. Maintaining a project is difficult, 5 | sometimes unrewarding work. Sure, you will get to contribute cool 6 | features to the project. But most of your time will be spent reviewing, 7 | cleaning up, documenting, answering questions, justifying design 8 | decisions - while everyone has all the fun! But remember - the quality 9 | of the maintainers work is what distinguishes the good projects from the 10 | great. So please be proud of your work, even the unglamourous parts, 11 | and encourage a culture of appreciation and respect for *every* aspect 12 | of improving the project - not just the hot new features. 13 | 14 | This document is a manual for maintainers old and new. It explains what 15 | is expected of maintainers, how they should work, and what tools are 16 | available to them. 17 | 18 | This is a living document - if you see something out of date or missing, 19 | speak up! 20 | 21 | ## What are a maintainer's responsibilities? 22 | 23 | It is every maintainer's responsibility to: 24 | 25 | * Expose a clear roadmap for improving their component. 26 | * Deliver prompt feedback and decisions on pull requests. 27 | * Be available to anyone with questions, bug reports, criticism etc. on their component. 28 | This includes IRC and GitHub issues and pull requests. 29 | * Make sure their component respects the philosophy, design and roadmap of the project. 30 | 31 | ## How are decisions made? 32 | 33 | This project is an open-source project with an open design philosophy. This 34 | means that the repository is the source of truth for EVERY aspect of the 35 | project, including its philosophy, design, roadmap and APIs. *If it's 36 | part of the project, it's in the repo. It's in the repo, it's part of 37 | the project.* 38 | 39 | As a result, all decisions can be expressed as changes to the 40 | repository. An implementation change is a change to the source code. An 41 | API change is a change to the API specification. A philosophy change is 42 | a change to the philosophy manifesto. And so on. 43 | 44 | All decisions affecting this project, big and small, follow the same procedure: 45 | 46 | 1. Discuss a proposal on the [mailing list](CONTRIBUTING.md#mailing-list). 47 | Anyone can do this. 48 | 2. Open a pull request. 49 | Anyone can do this. 50 | 3. Discuss the pull request. 51 | Anyone can do this. 52 | 4. Endorse (`LGTM`) or oppose (`Rejected`) the pull request. 53 | The relevant maintainers do this (see below [Who decides what?](#who-decides-what)). 54 | Changes that affect project management (changing policy, cutting releases, etc.) are [proposed and voted on the mailing list](GOVERNANCE.md). 55 | 5. Merge or close the pull request. 56 | The relevant maintainers do this. 57 | 58 | ### I'm a maintainer, should I make pull requests too? 59 | 60 | Yes. Nobody should ever push to master directly. All changes should be 61 | made through a pull request. 62 | 63 | ## Who decides what? 64 | 65 | All decisions are pull requests, and the relevant maintainers make 66 | decisions by accepting or refusing the pull request. Review and acceptance 67 | by anyone is denoted by adding a comment in the pull request: `LGTM`. 68 | However, only currently listed `MAINTAINERS` are counted towards the required 69 | two LGTMs. In addition, if a maintainer has created a pull request, they cannot 70 | count toward the two LGTM rule (to ensure equal amounts of review for every pull 71 | request, no matter who wrote it). 72 | 73 | Overall the maintainer system works because of mutual respect. 74 | The maintainers trust one another to act in the best interests of the project. 75 | Sometimes maintainers can disagree and this is part of a healthy project to represent the points of view of various people. 76 | In the case where maintainers cannot find agreement on a specific change, maintainers should use the [governance procedure](GOVERNANCE.md) to attempt to reach a consensus. 77 | 78 | ### How are maintainers added? 79 | 80 | The best maintainers have a vested interest in the project. Maintainers 81 | are first and foremost contributors that have shown they are committed to 82 | the long term success of the project. Contributors wanting to become 83 | maintainers are expected to be deeply involved in contributing code, 84 | pull request review, and triage of issues in the project for more than two months. 85 | 86 | Just contributing does not make you a maintainer, it is about building trust with the current maintainers of the project and being a person that they can depend on to act in the best interest of the project. 87 | The final vote to add a new maintainer should be approved by the [governance procedure](GOVERNANCE.md). 88 | 89 | ### How are maintainers removed? 90 | 91 | When a maintainer is unable to perform the [required duties](#what-are-a-maintainers-responsibilities) they can be removed by the [governance procedure](GOVERNANCE.md). 92 | Issues related to a maintainer's performance should be discussed with them among the other maintainers so that they are not surprised by a pull request removing them. 93 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # OCI Artifacts 2 | 3 | > ## ⚠️This repository has been archived and is no longer maintained. ⚠️ 4 | 5 | For current OCI Artifact guidance, please see: 6 | - image-spec: [artifacts guidance documentation](https://github.com/opencontainers/image-spec/blob/main/artifacts-guidance.md) 7 | - distribution-spec: [referrers API](https://github.com/opencontainers/distribution-spec/blob/main/spec.md#enabling-the-referrers-api) 8 | 9 | 10 | ## OCI Artifacts Converges with Image and Distribution Specs 11 | 12 | OCI Artifacts started in 2019 with [PRs to the Image](https://github.com/opencontainers/image-spec/pull/770) and the [Distribution specs](https://github.com/opencontainers/distribution-spec/pull/65). In September of 2019, the TOB voted to create the [New OCI Artifacts Project](https://opencontainers.org/posts/blog/2019-09-10-new-oci-artifacts-project/), generalizing the deployed container registry infrastructure to serve ecosystems of new artifacts. Artifact Authors no longer needed to create, nor host new package managers. By leveraging existing public and private registries, artifact authors benefit from the reliability, performance and security benefits users already manage. 13 | 14 | In 2020, early supply chain security initiatives were evolving, requiring the addition of [reference information to existing artifacts (#29)](https://github.com/opencontainers/artifacts/pull/29), including signatures, Software Bill of Materials (SBOM), and new developing types. 15 | 16 | We're happy to see the journey completed with the Image and Distribution specs formalizing the addition of OCI Artifacts and Reference Types. With the [Image 1.1](https://github.com/opencontainers/image-spec/releases), and [Distribution 1.1 releases](https://github.com/opencontainers/distribution-spec/releases), the effort has come full circle, making it time to archive the OCI Artifacts project. 17 | 18 | The previous OCI Artifacts content is available in the [pre-archive branch](https://github.com/opencontainers/artifacts/tree/pre-archive) 19 | 20 | ## Project License 21 | 22 | - [The Apache License, Version 2.0](LICENSE) 23 | 24 | ## Code of Conduct 25 | 26 | This project incorporates (by reference) the OCI [Code of Conduct](https://github.com/opencontainers/.github/blob/master/CODE_OF_CONDUCT.md) 27 | 28 | ## Governance and Releases 29 | 30 | This project incorporated the Governance and Releases processes from the OCI project template: https://github.com/opencontainers/project-template. 31 | -------------------------------------------------------------------------------- /RELEASES.md: -------------------------------------------------------------------------------- 1 | # Releases 2 | 3 | The release process hopes to encourage early, consistent consensus-building during project development. 4 | The mechanisms used are regular community communication on the mailing list about progress, scheduled meetings for issue resolution and release triage, and regularly paced and communicated releases. 5 | Releases are proposed and adopted or rejected using the usual [project governance](GOVERNANCE.md) rules and procedures. 6 | 7 | An anti-pattern that we want to avoid is heavy development or discussions "late cycle" around major releases. 8 | We want to build a community that is involved and communicates consistently through all releases instead of relying on "silent periods" as a judge of stability. 9 | 10 | ## Parallel releases 11 | 12 | A single project MAY consider several motions to release in parallel. 13 | However each motion to release after the initial 0.1.0 MUST be based on a previous release that has already landed. 14 | 15 | For example, runtime-spec maintainers may propose a v1.0.0-rc2 on the 1st of the month and a v0.9.1 bugfix on the 2nd of the month. 16 | They may not propose a v1.0.0-rc3 until the v1.0.0-rc2 is accepted (on the 7th if the vote initiated on the 1st passes). 17 | 18 | ## Specifications 19 | 20 | The OCI maintains three categories of projects: specifications, applications, and conformance-testing tools. 21 | However, specification releases have special restrictions in the [OCI charter][charter]: 22 | 23 | * They are the target of backwards compatibility (§7.g), and 24 | * They are subject to the OFWa patent grant (§8.d and e). 25 | 26 | To avoid unfortunate side effects (onerous backwards compatibity requirements or Member resignations), the following additional procedures apply to specification releases: 27 | 28 | ### Planning a release 29 | 30 | Every OCI specification project SHOULD hold meetings that involve maintainers reviewing pull requests, debating outstanding issues, and planning releases. 31 | This meeting MUST be advertised on the project README and MAY happen on a phone call, video conference, or on IRC. 32 | Maintainers MUST send updates to the dev@opencontainers.org with results of these meetings. 33 | 34 | Before the specification reaches v1.0.0, the meetings SHOULD be weekly. 35 | Once a specification has reached v1.0.0, the maintainers may alter the cadence, but a meeting MUST be held within four weeks of the previous meeting. 36 | 37 | The release plans, corresponding milestones and estimated due dates MUST be published on GitHub (e.g. https://github.com/opencontainers/runtime-spec/milestones). 38 | GitHub milestones and issues are only used for community organization and all releases MUST follow the [project governance](GOVERNANCE.md) rules and procedures. 39 | 40 | ### Timelines 41 | 42 | Specifications have a variety of different timelines in their lifecycle. 43 | 44 | * Pre-v1.0.0 specifications SHOULD release on a monthly cadence to garner feedback. 45 | * Major specification releases MUST release at least three release candidates spaced a minimum of one week apart. 46 | This means a major release like a v1.0.0 or v2.0.0 release will take 1 month at minimum: one week for rc1, one week for rc2, one week for rc3, and one week for the major release itself. 47 | Maintainers SHOULD strive to make zero breaking changes during this cycle of release candidates and SHOULD restart the three-candidate count when a breaking change is introduced. 48 | For example if a breaking change is introduced in v1.0.0-rc2 then the series would end with v1.0.0-rc4 and v1.0.0. 49 | * Minor and patch releases SHOULD be made on an as-needed basis. 50 | 51 | [charter]: https://www.opencontainers.org/about/governance 52 | -------------------------------------------------------------------------------- /artifact-authors.md: -------------------------------------------------------------------------------- 1 | # Open Containers Initiative 2 | 3 | ## Artifact Authors Guidance 4 | This reference provides guidance for authoring new artifact types. 5 | 6 | ## OCI Artifacts Support 7 | 8 | OCI Artifacts provides a reference for artifact authors and registry implementors to support new artifact types with pre 1.0 implementations of the [distribution-spec][distribution-spec]. More particularly, this repository has been [tasked by the OCI TOB to serve 3 primary goals](https://github.com/opencontainers/tob/blob/master/proposals/artifacts.md): 9 | 10 | 1. **Artifact Authors** - guidance for authoring new artifact types, including a clearing house for [well known][def-well-known-types] artifact types. 11 | 1. **Registry Operators and Vendors** - guidance for how operators and vendors can support new artifact types, including how they can opt-in or out of well known artifact types. Registry operators that already implement `mediaType` filtering will not have to change. The artifact repo will provide context on how new `mediaTypes` can be used, and how `mediaTypes` can be associated with a type of artifact. 12 | 1. **Clearing House for [Well-known Artifacts][def-well-known-types]** - artifact authors can submit their artifact definitions, providing registry operators a list by which they can easily support. 13 | 14 | ## Dependencies for the Guidance Provided by this Reference 15 | 16 | - [Scope](#scope) 17 | - [Defining OCI Artifact Types](#defining-oci-artifact-types) 18 | - [Defining a Unique Artifact Type](#defining-a-unique-artifact-type) 19 | - [Defining Supported Layer Types](#defining-supported-layer-types) 20 | - [Optional: Defining Config Schema](#optional-defining-config-schema) 21 | - [Registering Unique Types with IANA](#registering-unique-types-with-iana) 22 | - [References](#references) 23 | 24 | ## Scope 25 | 26 | This reference is dependent on [OCI manifest][image-manifest] 1.0 to represent individual artifact types including [OCI Image][image-spec], [Helm][helm] and [Singularity][singularity]. 27 | 28 | 29 | 30 | 31 | 32 | ### Future Scope 33 | 34 | Future versions will support new artifact types representing collections of artifacts using [OCI Index][image-index]. A means to identify an index as a type of artifact will be required. 35 | 36 | ## Defining OCI Artifact Types 37 | 38 | As registries become content addressable distribution points, tools that pull artifacts must know if they can operate on the artifact. Artifact types are equivalent to file extensions. 39 | 40 | A set of comparable file extension use cases include: 41 | 42 | - When users open files, the host operating system typically launches the appropriate program. 43 | - When users open a file, from within a program, the open dialog filters to the supported types. 44 | - When search or security software scan the contents of a storage solution, the software must know how to process the different types of content. 45 | - When users view the storage contents, information about the content is rendered based on the derived type(s) of the content being shown. 46 | 47 | OCI Artifacts enables these use cases for [OCI distribution spec][distribution-spec] based registries by specifying a `manifest.config.mediaType` on the content pushed to a registry. 48 | 49 | ### Visualizing Artifacts 50 | 51 | The manifest `config.mediaType` is the equivalent of a file extension, enabling artifact type differentiation. An example of completed artifacts follows: 52 | 53 | |Icon|Artifact|`config.mediaType`| 54 | |-|-|-| 55 | ||[OCI Image][image-spec]|`application/vnd.oci.image.config.v1+json`| 56 | ||[Helm Chart](https://helm.sh)|`application/vnd.cncf.helm.config.v1+json`| 57 | ||[Singularity][singularity], by [Sylabs][sylabs]|`application/vnd.sylabs.sif.config.v1+json`| 58 | 59 | ## Defining a Unique Artifact Type 60 | 61 | A unique artifact type is similar to defining a file extension. Defining a unique artifact allows various tools to know how to uniquely work with the type. It allows a registry to display the type and tooling, such as vulnerability scanners, a means to know if and how they should interact with the contents. 62 | 63 | Defining a unique type involves uniqueness for computer processing, and uniqueness for humans. 64 | 65 | For computer processing, artifacts are defined by setting the `manifest.config.mediaType` to a globally unique value. 66 | 67 | > **Note:** The `config.mediaType` of `application/vnd.oci.image.config.v1+json` is reserved for artifacts intended to be run and instanced by [docker][docker], [containerd][containerd] and other [OCI Image][image-spec] runtimes and tool chains. 68 | 69 | Each new artifact type MUST be uniquely defined. See [registering unique types with IANA](#registering-unique-types-with-iana) for registering unique [well-known][def-well-known-types] mediaTypes. 70 | 71 | Each `mediaType` SHOULD use all lower case characters. Multi-part names MAY concatenate words, or use `-` to separate words. eg: (`subtype`, `sub-type`) 72 | 73 | The following `config.mediaType` format is used to differentiate the type of artifact: 74 | 75 | `[registration-tree]`.`[org|company|entity]`.`[objectType]`.`[optional-subType]`.config.`[version]`+`[optional-configFormat]` 76 | 77 | - **`registration-tree`** - represents an IANA root tree. See [iana registration trees][iana-trees] for public and private tree options. 78 | - **`org|company|entity`** - represents an open source foundation (`oci`, `cncf`) or a company (`microsoft`, `ibm`) or some unique entity. 79 | - **`objectType`** - a value representing the short name of the type. 80 | - **`optional-subType`** - provides additional extensibility of an `objectType` 81 | - **`version`** - provides artifact authors the ability to revision their schemas and formatting, enabling tools to identify which format they will process. 82 | - **`optional-configFormat`** - while `config.mediaType` represents the unique identifier of an artifact, providing a config object is optional. If a config object is provided, `.json`, `.yaml` or other standard textual formats are preferred. By utilizing standard text formats, registry operators MAY parse the contents to provide additional context to users. If the config object is null, the `optional-configFormat` MUST be empty. 83 | 84 | ### Example `config.mediaTypes` 85 | 86 | |Artifact Type|mediaType| 87 | |-|-| 88 | | null config | `application/vnd.oci.null-sample.config.v1`| 89 | | Config as `.json` | `application/vnd.oci.json-sample.config.v2+json`| 90 | | Config as `.yaml` | `application/vnd.oci.yaml-sample.config.v3+yaml`| 91 | 92 | See [visualizing artifacts](#visualizing-artifacts) for additional `mediaType` examples. 93 | 94 | ## Defining Supported Layer Types 95 | 96 | The content of an artifact is represented through a collection of layers and an optional config object. The layers of an artifact may be independent files, collections of files, or ordered collection of tarballs persisted as blobs within a registries storage provider. 97 | 98 | Defining artifact layers involves: 99 | 100 | 1. [Defining layer content, understanding layer de-duping](#layer-content-format) 101 | 1. [Optional versioning of layer content](#layer-versioning) 102 | 1. [Defining `layer.mediaTypes`](#defining-layermediatypes) 103 | 104 | As an example, [OCI Images][image-layer] are represented through an ordered collection of tar archives. Each tar archive represents a layer. Each layer overlays the previous layer. 105 | 106 | Some artifacts may be represented as a single file, such as a config artifact representing a deployment details for an application. While other artifacts may include a config object, and a collection of binaries compressed as yet another layer. By separating the layers, the artifact author can benefit from layer de-duplication and concurrent downloading of each layer using various distribution-spec clients. How an artifact client processes layers, merging them with overlay, or extracting them to different locations or hosts is up to the artifact authors. 107 | 108 | ### Layer Content Format 109 | 110 | The content layer format is up to the artifact author and may utilize standard or custom formats. Authors are encouraged to utilize existing formats which may benefit from existing libraries to parse those formats. Authors may choose to persist individual files with standard or custom formats, such as `.json`, `.yaml`, `.bin`, `.sif`, or store a collection of files as a `.tar` archive. Optionally, the author MAY choose to compress the contents. The extension of the `layer.mediaType` MUST reflect the format of the blob and its optional compression. 111 | 112 | Artifacts authors may define different layers for a range of reasons: 113 | 114 | 1. Split layers due to size: 115 | - Splitting an artifact into multiple layers enables concurrent downloading. 116 | - Some artifacts will benefit from common layers, such as OCI Images having common base layers and/or common framework/runtime layers. 117 | For example, in OCI, the layers are ordered where each layer overlays the previous layer, creating a unified collection of files. 118 | All layer types are the same, with the position in the index being the important aspect. 119 | 1. Split layers for different groupings, reuse and optimization: 120 | - An artifact may have non-unique environmental config and runtime collections of files. The runtime layer is sent to a host, while the configuration information may be sent to another location on the same host, or to a different host altogether. 121 | - Layers may split for different localization options, where an artifact client can determine which layers it requires for locales and language requirements. The runtime layer, or the localization layers may be individually updated, isolating the storage and download time for delta changes. 122 | - Layers may include optional source code, licenses or software bill of materials (SBoM) that are required for legal requirements or policy management. Different elements of a pipeline may pull the layers they require, while saving bandwidth, memory and compute processing for the layers they don't require. 123 | - In these cases, the ordered position of the layer may not be important, rather the sub-type of the layer identifies its purpose. 124 | 125 | #### De-duping Layers 126 | 127 | When designing layer formats, consider how a registry may de-dupe layers that share the same content across different artifacts. Layers may be shared across different instances of an artifact as they're persisted to a registry. The registry may handle de-duping based on the digest of each layer. Artifact layers types are not expected, nor required to be shared across different artifact types. A layer type that represents an OCI Image is not expected to be shared with a helm chart. However, two helm charts that have the same content may be de-duped within the registry. The `layer.mediaType` provides the definition of the contents. 128 | 129 | ### Layer Versioning 130 | 131 | Layer formats that may change should define a version to future proof new enhancements. How the artifact tooling processes forward and backward compatibility is up to the artifact and tooling authors. 132 | 133 | ### Defining `layer.mediaTypes` 134 | 135 | `layer.mediaTypes` fall into 2 categories: 136 | 137 | 1. **Existing generic formats**: as defined by [IANA][iana-media-types]. 138 | These types are neither artifact nor `vendor|org|entity` specific, nor are they versioned. 139 | Generic formats enable simple single layer scenarios, or where there's little to no differentiation between the different layers. 140 | - [text/*](https://www.iana.org/assignments/media-types/media-types.xhtml#text) 141 | - [application/json](https://www.iana.org/assignments/media-types/application/json) 142 | - [application/xml](https://www.iana.org/assignments/media-types/application/xml) 143 | 1. **Vendor|Org|Entity definitions**: identify different versioned layer types within the same artifact. 144 | Unique definitions enable layers to be handled individually without assuming ordered positioning. Each layer may use an existing [IANA][iana-media-types] format, but represent different usages within the artifact type. 145 | A Registry Doc artifact (`application/vnd.oci.sample-repo-doc.config.v1`) which represents the contents of a repo cloud be represented as: 146 | - `application/vnd.oci.sample-repo-doc.summary.layer.v1.md` - used as the readme of a repo, displayed on a registry webpage. 147 | - `application/vnd.oci.sample-repo-doc.content.layer.v1.tar` - provides detailed documentation, including multiple `.md` files for offline reading. 148 | 149 | **Vendor|Org|Entity definitions** utilize the `layer.mediaType` with the following format: 150 | `[registration-tree]`.`[org|company|entity]`.`[layerType]`.`[optional-layerSubType]`.layer.`[version]`.`[fileFormat]`+`[optional-compressionFormat]` 151 | 152 | - **`registration-tree`** - represents an IANA root tree. See [iana registration trees][iana-trees] for public and private tree options. 153 | - **`org|company|entity`** - represents an open source foundation (`oci`, `cncf`), a company or some unique entity. 154 | - **`layerType`** - a value representing the short name of the type. 155 | - **`optional-layerSubType`** - provides additional extensibility of a `layerType` 156 | - **`version`** - provides artifact authors the ability to revision their schemas and formatting, enabling tools to identify which format they will process. Using a version enables artifact tools to identify the format for processing. 157 | - **`fileFormat`** - provides for standard, or custom formats, enabling artifact authors to leverage existing or custom content processing libraries. 158 | - **`optional-compressionFormat`** - in addition to the fileFormat, optional compression is used. (eg: `+gzip`, `+zstd`) 159 | 160 | ### Example Layer Types 161 | 162 | | Artifact Type | mediaType | 163 | | - | - | 164 | | Simple text file layer | `application/text` | 165 | | Non-compressed OCI Image layer | `application/vnd.oci.image.layer.v1.tar` | 166 | | [gzip] Compressed OCI Image layer | `application/vnd.oci.image.layer.v1.tar+gzip` | 167 | | [gzip] Compressed Docker Image layer | `application/vnd.docker.image.rootfs.diff.tar+gzip` | 168 | | [gzip] Compressed Helm Chart layer | `application/vnd.cncf.helm.chart.content.v1.tar+gzip` | 169 | | Singularity SIF layer | `application/vnd.sylabs.sif.layer.v1.sif` | 170 | | Sample Doc Artifact Summary layer | `application/vnd.oci.sample-repo-doc.summary.layer.v1.md` | 171 | | Sample Doc Artifact Content layer| `application/vnd.oci.sample-repo-doc.content.layer.v1.tar` | 172 | 173 | ## Optional: Defining Config Schema 174 | 175 | When defining an artifact type, the persistence of the artifact may be broken up into content and configuration. Configuration may be stored as a layer, or it may be stored and referenced by the `manifest.config`. 176 | 177 | While the value of `manifest.config.mediaType` is used to determine the artifact type, the persistance of a `config` object is OPTIONAL. Artifacts can push a null reference for `config.json` persistance. 178 | 179 | Some benefits of placing content in `manifest.config` include: 180 | 181 | - Tooling can pull the configuration object prior to layers. An artifact component may use the config to determine how and where the layer should be instantiated. The artifact component might send layer request to different compute instances, such as OCI Image layers being distributed differently based on the target OS. 182 | - Registries may opt-into parsing the `manifest.config` object if it provides meaningful top-level information. For example, [OCI Image Config][image-spec-config] stores `OS`, `Architecture` and `Platform` information that some registry operators may wish to display. The config object is easy to pull & parse, as opposed to getting a layer url to pull, possibly decompress and parse. 183 | 184 | Registries which implement the artifact spec MAY: 185 | 186 | - Parse and process the contents of `manifest.config`, based on the provided schema of `manifest.config.mediaType`, offering additional information or actions. 187 | - Ignore the contents and validation of the `config` object. 188 | 189 | ## Registering Unique Types with IANA 190 | 191 | New artifact types SHOULD register their unique `config.mediaType` and unique `layer.mediaType` with IANA to assure ownership of the type. [Well-known][def-well-known-types] types MUST register their unique `mediaTypes` to be published for registry consumption. 192 | 193 | ## References 194 | 195 | RFC reference: 196 | 197 | - [RFC 6838][rfc-6838] 198 | - [RFC 5226][rfc-5226] 199 | 200 | [annotations]: https://github.com/opencontainers/image-spec/blob/master/annotations.md 201 | [artifacts]: README.md 202 | [containerd]: https://containerd.io/ 203 | [def-registry]: definitions-terms.md#registry 204 | [def-well-known-types]: definitions-terms.md#well-known-type 205 | [def-yass]: definitions-terms.md#yass 206 | [distribution-spec]: https://github.com/opencontainers/distribution-spec/ 207 | [docker]: https://github.com/moby/moby 208 | [gzip]: https://tools.ietf.org/html/rfc1952 209 | [helm]: https://github.com/helm/helm 210 | [iana-registry-media-types]: https://www.iana.org/form/media-types 211 | [iana-trees]: https://tools.ietf.org/html/rfc6838#section-3 212 | [iana-media-types]: https://www.iana.org/assignments/media-types/media-types.xhtml 213 | [image-manifest]: https://github.com/opencontainers/image-spec/blob/master/manifest.md 214 | [image-index]: https://github.com/opencontainers/image-spec/blob/master/image-index.md 215 | [image-layer]: https://github.com/opencontainers/image-spec/blob/master/layer.md 216 | [image-spec]: https://github.com/opencontainers/image-spec/ 217 | [image-spec-config]: https://github.com/opencontainers/image-spec/blob/master/config.md 218 | [iso-639-1]: https://www.iso.org/iso-639-language-codes.html 219 | [iso-3166-1]: https://www.iso.org/iso-3166-country-codes.html 220 | [locale-strings]: #setting-locale-strings 221 | [distribution]: https://github.com/docker/distribution 222 | [rfc-5226]: https://tools.ietf.org/html/rfc5226 223 | [rfc-6838]: https://tools.ietf.org/html/rfc6838 224 | [singularity]: https://github.com/sylabs/singularity 225 | [sylabs]: https://sylabs.io/ 226 | [zstd]: https://tools.ietf.org/html/rfc8478 227 | -------------------------------------------------------------------------------- /definitions-terms.md: -------------------------------------------------------------------------------- 1 | # Definitions and Terms 2 | 3 | A collection of definitions and terms used within this repository. 4 | 5 | * [Artifact Author](#artifact-author) 6 | * [Distribution Operator](#distribution-operator) 7 | * [Media Type](#media-type) 8 | * [OCI Image](#oci-image) 9 | * [Registry](#registry) 10 | * [Well Known Type](#well-known-type) 11 | * [YASS](#yass) 12 | 13 | ## Artifact Author 14 | 15 | The owner of an artifact format. The [OCI Image Spec](https://github.com/opencontainers/image-spec/) is owned by the OCI working group. 16 | 17 | An artifact is defined to be unique by its `config.mediaType`. 18 | 19 | ## Container Registry 20 | 21 | See [Registry](#registry) 22 | 23 | ## Distribution Operator 24 | 25 | Vendors that implement and/or run the [OCI Distribution Spec](https://github.com/opencontainers/distribution-spec/). 26 | 27 | ## Media Type 28 | 29 | The uniqueness of an artifact is defined by its type. An artifact has a type, which has a collection of layers. 30 | 31 | The Artifact is defined as unique by its `manifest.config.mediaType`. Layers are defined by their `layer.config.mediaType`. 32 | 33 | ## OCI Image 34 | 35 | OCI Image is a specific type of artifact. However, an OCI image is not meant to define all artifacts. Tooling, such as docker, containerD and vulnerability scanners that perform security checks upon container images, use the `config.mediaType` to know they can pull and instance container images. Docker and containerD are not intended to pull and instance Helm Charts, Singularity, OPA or other artifact types. 36 | 37 | ## Registry 38 | 39 | A registry, or container registry, is an instance of the [distribution-spec]. See [Implementers][implementers] for a list of registries that support OCI Artifacts. 40 | 41 | ## Well Known Type 42 | 43 | Types that many to most registry operators would likely want to support ([OCI Image][image-spec], [Helm][helm], [Singularity][singularity]). While registry operators are not required to support all types, registry operators would likely want to support well known types, if there was an easy way to understand the differing types. OCI Artifacts includes publishing of well-known types for registry operators to import. 44 | 45 | ## YASS 46 | 47 | [OCI Artifacts][artifacts] provides an alternative to having to build, distribute and run "**Y**et **A**nother **S**torage **S**ervice". 48 | 49 | [artifacts]: https://github.com/opencontainers/artifacts 50 | [helm]: https://helm.sh 51 | [implementers]: implementers.md 52 | [image-spec]: https://github.com/opencontainers/image-spec/ 53 | [distribution-spec]: https://github.com/opencontainers/distribution-spec/ 54 | [singularity]: https://github.com/sylabs/singularity 55 | -------------------------------------------------------------------------------- /implementers.md: -------------------------------------------------------------------------------- 1 | # OCI Artifacts Implementations 2 | 3 | Registries currently supporting OCI Artifacts 4 | 5 | - [Amazon ECR](https://aws.amazon.com/blogs/containers/oci-artifact-support-in-amazon-ecr/) 6 | - [Azure Container Registry](https://aka.ms/acr/artifacts) 7 | - [CNCF Distribution](https://github.com/distribution/distribution/) 8 | - [Project Harbor](https://goharbor.io/blog/harbor-2.0/) 9 | - [Quay.io](https://www.openshift.com/blog/quay-oci-artifact-support-for-helm-charts) 10 | - [zot](https://zotregistry.io) 11 | - _(to add your project, please open a [pull-request](https://github.com/opencontainers/artifacts/pulls))_ 12 | 13 | [distribution-spec]: https://github.com/opencontainers/distribution-spec/ 14 | -------------------------------------------------------------------------------- /media/artifacts-spec-objects.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/opencontainers/artifacts/8fb48d340d166509ee11757c1722155e11bea929/media/artifacts-spec-objects.png -------------------------------------------------------------------------------- /media/image-spec-objects.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/opencontainers/artifacts/8fb48d340d166509ee11757c1722155e11bea929/media/image-spec-objects.png --------------------------------------------------------------------------------