├── CHARTER.md ├── EMERITUS.md ├── LICENSE ├── README.md ├── WG-INFO.md ├── WG-TEMPLATE.md └── proposals ├── artifacts.md ├── cgroups.md ├── digest.md ├── distribution.md ├── image-format └── README.md ├── selinux.md ├── tools.md ├── umoci.md ├── wg-auth.md ├── wg-freebsd-runtime.md ├── wg-image-compatibility.md └── wg-reference-types.md /CHARTER.md: -------------------------------------------------------------------------------- 1 | # Open Container Initiative Charter v1.3 2 | 3 | | Comment | Effective Date | 4 | | ----------------- |:----------------:| 5 | | Initial release | 13 November 2015 | 6 | | Update | 18 May 2020 | 7 | | Update (simplify) | 4 June 2020 | 8 | | Add Working Groups| 10 Aug 2021 | 9 | 10 | ## 1. Mission of the Open Container Initiative (“OCI”). 11 | 12 | The Open Container Initiative provides an open source technical community 13 | within which industry participants may easily contribute to building 14 | vendor-neutral, portable and open specifications, reference implementations, 15 | and tools that deliver on the promise of containers as a source of application 16 | portability backed by a certification program. 17 | 18 | The Open Container Initiative does not seek to be a marketing organization, 19 | define a full stack or solution requirements, and will strive to avoid 20 | standardizing technical areas undergoing innovation and debate. 21 | 22 | ## 2. OCI Projects 23 | 24 | a. The OCI will maintain a collection of projects to execute its Mission (“OCI 25 | Projects”). The initial OCI Projects shall be the specification (“OCI 26 | Specification”) and runtime (“runc”) projects. When an OCI Project claims 27 | that a feature is provided from the OCI Specification, all of its 28 | constituent parts shall comply with the OCI Specification. An OCI project 29 | may have additional capabilities that are not reflected in the associated 30 | specification. In this case, it is understood that the specification (and 31 | any associated test suites) are the standard for judging compliance, not the 32 | reference implementation. 33 | 34 | b. OCI Projects may be modified by the Technical Oversight Board so long as 35 | such modifications are in the spirit of the original charter. For example, 36 | the TOB may choose to add a top level Compliance Test Suite project or a 37 | reference implementation for an optional layer item. 38 | 39 | c. Any Member can bring forward a new project proposal to the TOB for review. 40 | Approval of new OCI Projects requires a two-thirds vote of the TOB. 41 | 42 | d. A project need not be contributed to the OCI in order to be deemed compliant 43 | with an associated OCI specification. For avoidance of doubt, a runtime can 44 | be compliant with the OCI Specification even if: a)it differs substantially 45 | from runC, b)it is housed outside the OCI, c)it is licensed differently from 46 | runC, including if it is licensed under a proprietary license. 47 | 48 | e. In order to support d. above, it is expected that: 49 | 50 | - i. there may be functionality in runC that is not included in the 51 | specification, provided that such functionality does not compromise 52 | compliance with the specification, and 53 | - ii. there may be multiple other implementations of the specification that 54 | also contain functionality not included in the specification, and 55 | - iii. there will be a strong bias to exclude items from the specification 56 | in technical areas undergoing significant innovation and debate, 57 | especially if those areas are likely to be the basis of differentiation 58 | between competing implementations. 59 | 60 | ## 3. Membership. 61 | 62 | a. The Open Container Initiative shall be composed of: 63 | 64 | - i. OCI Members: Corporate Members of The Linux Foundation that have 65 | executed an OCI Membership Agreement to sponsor the activities of the OCI 66 | Community and a certification program through a Trademark Board; 67 | - ii. an open source, Technical Developer Community (“TDC”), open to any 68 | individual, whether an employee of an OCI Member or not; 69 | - iii. a Technical Oversight Board (“TOB”); and 70 | - iv. A Trademark Board. 71 | 72 | b. OCI Members shall be entitled to: 73 | 74 | - i. participate in OCI Trademark Board meetings, OCI Projects, and any 75 | other activities sponsored by the OCI; 76 | - ii. identify their company as a member or participant in the OCI; 77 | - iii. use any approved OCI membership logo in compliance with guidelines 78 | established by the LF Trademark Board 79 | - iv. vote in all decisions of the OCI Trademark Board. 80 | 81 | c. OCI non-Member Participants shall be entitled to fully participate in all 82 | OCI Projects subject to the terms of this Charter and any policies adopted 83 | by the Trademark Board. 84 | 85 | ## 4. Trademark Board 86 | 87 | a. The Trademark Board shall be composed of one representative appointed by 88 | each OCI Member. A Member may appoint an alternative representative for any 89 | meeting. 90 | 91 | b. Trademark Board meetings may be held in-person or via electronic 92 | conferencing. The Trademark Board shall establish its own meeting schedule 93 | and operating procedures. 94 | 95 | c. Quorum for holding meetings shall be established when a simple majority of 96 | Trademark Board representatives is present. 97 | 98 | d. The intention is for the OCI to operate by consensus. However, if consensus 99 | cannot be achieved, the Trademark Board shall vote on a decision. Votes 100 | either at meetings, via email or electronic voting service, shall be based 101 | on a one vote per Active Member basis, requiring a simple majority of votes 102 | cast to pass. An abstain vote equals not voting at all. An Active Member is 103 | defined as any OCI Member whose representative attended (including by 104 | telephone or electronic conference or meeting) at least one of the last four 105 | Trademark Board meetings. An alternative representative’s attendance counts 106 | as participation for determining whether a Member is an Active Member. 107 | 108 | e. The Trademark Board is intended to provide a minimalist governance structure 109 | around the development and use of the OCI trademarks and shall be 110 | responsible for: 111 | 112 | - i. creating the OCI trademarks associated with OCI Projects (including the 113 | OCI Specification Project), the Open Container Format (OCF) or OCI 114 | certified solutions. 115 | - ii. creating a certification program establishing the requirements for 116 | achieving the status of an “OCI Certified Solution” and defining the terms 117 | for using any OCI trademark(s) for an OCI Certified Solution; 118 | - iii. approving the use of OCI funds for specific trademark a trademark 119 | registration program, and for enforcement actions, if any, that may be 120 | advisable; 121 | - iv. creating and approving a budget directing the LF how to use the OCI 122 | funds raised from all sources of revenue; 123 | - v. organizing and directing marketing initiatives including, but not 124 | limited to, press releases, website updates, and creation of collateral 125 | and branding materials; 126 | - vi. electing a Chair of the Trademark Board each January, or at another 127 | time of its choosing by an approved vote of the Trademark Board, to 128 | preside over meetings, set agendas, authorize budgeted expenditures and 129 | managing any day-to-day operations; and 130 | - vii. voting on other decisions or matters that may come before the 131 | Trademark Board, including adopting policies related to the scope of the 132 | Trademark Board which shall be documented for Members. 133 | 134 | f. Any certification program established by the OCI Trademark Board must 135 | support a vendor-neutral process and requirements, including specifically, 136 | the ability for solutions to be certified on multiple operating systems and 137 | usable in multiple environment implementations. 138 | 139 | g. Any issues that cannot be resolved by the Trademark Board shall be referred 140 | to The Linux Foundation for resolution. 141 | 142 | h. For avoidance of doubt, OCI membership does not convey any rights to 143 | directly influence the technical direction of any OCI Project. That 144 | influence will come through code and specification contributions to the 145 | technical projects. 146 | 147 | ## 5. Technical Developer Community 148 | 149 | a. The OCI hosts and supports the participation of a technical development 150 | community (“OCI TDC”) in OCI Projects. The OCI TDC shall be open to any 151 | developer, end user or subject matter expert that chooses to participate in 152 | the activities of OCI, regardless of whether the participant is employed by 153 | an OCI Member company so long as his or her contributions and conduct comply 154 | with this Charter. 155 | 156 | b. The OCI TDC has an established scope of work focused on: 157 | 158 | - i. Creating and maintaining formal specifications (the OCI Specification 159 | project) for container image formats and runtime, which will allow a 160 | compliant container to be portable across all major, compliant operating 161 | systems and platforms without artificial technical barriers; 162 | - ii. Ensuring that OCI Specifications incorporate and align to the OCI 163 | Values, as defined in Section 8 below; 164 | - iii. The TDC will look to agree on a standard set of container actions 165 | (e.g. start, exec, pause) as well as a runtime environment associated with 166 | the container runtime; 167 | - iv. Creating and maintaining test cases that shall serve as the testing 168 | functions for achieving certification as an OCI Certified Solution; 169 | - v. Engaging end users for feedback or input on OCI Projects, including, 170 | but not limited to, relating to usability; 171 | - vi. Ensuring that all OCI Projects follow and adhere to the OCI IP Policy; 172 | - vii. Approving releases by OCI Projects; 173 | - viii. Creating, maintaining and enforcing governance guidelines for the 174 | TDC, approved by the maintainers, and which shall be posted visibly for 175 | the TDC. The guidelines shall cover the following: 176 | - ix. establishing and defining roles and responsibilities (at a minimum, a 177 | role for committers or maintainers authorized to commit code to the 178 | codebase); 179 | - x. defining the process or requirements to take on a role in the TDC (e.g. 180 | how to become a contributor, or how to become a maintainer); 181 | - xi. the process by which participants in the TDC may give up or be revoked 182 | of their roles (e.g. how to remove maintainers); the rules for decision 183 | making in the TDC; and 184 | - xii. any workflow or processes participants are expected to follow in 185 | making or merging contributions. 186 | - xiii. Attempting to harmonize the OCI Specifications with other proposed 187 | standards, including, but not limited to, the appc specification; 188 | - xiv. Ensuring that the scope of technologies promulgated and proposed as 189 | standard elements of OCI Projects (including the OCI Specification) are 190 | those that are sufficiently widespread and sufficiently mature and stable 191 | so as to warrant establishment in the specification; 192 | - xv. Referring to the Technical Oversight Board any issues that deal with 193 | failure to follow established technical governance, issues that impact 194 | multiple OCI Projects or specifications, or conflicts that cannot be 195 | resolved within the TDC. Issues shall be referred to the TOB according to 196 | the requirements in Section 6.; and 197 | - xvi. Any issues of non-compliance with the OCI IP Policy shall be 198 | immediately referred to The Linux Foundation. 199 | 200 | c. The maintainers and contributors shall set the technical direction of the 201 | OCI Projects, with minimal interference by the Technical Oversight Board; 202 | 203 | d. The TDC will only accept influence through contribution. The primary means 204 | for any organization to influence the technical direction of the OCI 205 | Projects is via contribution or service as maintainers. OCI Members 206 | specifically disclaim any right to influence technical direction either on 207 | the basis of their financial contributions or their existence as OCI 208 | Members; 209 | 210 | e. The maintainers of the TDC shall be those listed in the MAINTAINERS file in 211 | the project repository, available at 212 | (https://raw.githubusercontent.com/opencontainers/specs/master/MAINTAINERS). 213 | 214 | ## 6. Technical Oversight Board (TOB) 215 | 216 | a. The TOB is responsible for managing conflicts, violations of procedures or 217 | guidelines and any cross-project or high-level issues that cannot be 218 | resolved in the TDC for OCI Projects. The TOB shall also be responsible for 219 | adding, removing or reorganizing OCI Projects. The TOB shall not dictate or 220 | interfere with the day-to-day work of individual OCI Projects or their 221 | decisions. 222 | 223 | b. The TOB shall be responsible for adopting any policies related to the scope 224 | of the TOB and ensuring they are documented publicly. 225 | 226 | c. The TOB shall operate transparently with any discussions and mailing lists 227 | open to the community. The TOB may choose to set up a private discussion or 228 | mailing list if a situation warrants a private discussion (e.g. removing a 229 | TOB member, addressing a legal issue), but the general expectation is that 230 | the TOB’s discussions and decisions are open to the OCI Community. If a 231 | decision is made in private, the TOB must follow all quorum and voting 232 | requirements as normally required and shall be responsible for notifying the 233 | OCI Community of the decision and rationale. Any private meeting of the TOB 234 | shall also require a representative from The Linux Foundation to ensure this 235 | option is not being abused. 236 | 237 | d. While the initial TDC shall have one TDC, as the OCI evolves, the TOB may 238 | decide to establish a TDC per OCI Project, requiring contributors to earn 239 | maintainer status independently within each OCI Project in which they wish 240 | to participate. 241 | 242 | e. The TOB shall be composed of nine (9) individuals elected for their 243 | expertise, contribution to the advancement of container technologies and are 244 | considered to be thought leaders in the OCI ecosystem. Anyone may be elected 245 | to the TOB, regardless of whether the individual is an employee of an OCI 246 | Member, so long as they are an OCI TDC participant. A TOB member is elected 247 | as an individual and not as a representative of his or her employer. No more 248 | than two (2) TOB members may be employed by the same entity or its 249 | affiliates. Affiliates shall be defined as entities owning 50% or more of an 250 | entity, or owned by or under common ownership with each other. TOB members 251 | may not designate alternative representatives. 252 | 253 | f. TOB members shall be split into two (2) groups, serving for a term of two 254 | (2) years on a staggered basis, where one group is elected each year. The 255 | initial TOB will have four (4) TOB members who will only serve for a term of 256 | one year and five (5) TOB members that serve for a term of two (2) years. 257 | 258 | g. The initial TOB shall be established through a nomination and election 259 | process. The first group from which four (4) TOB members shall be elected, 260 | will be nominated and elected by the current TDC maintainers, initially 261 | identified in Section 4(e), and serve for a period of one (1) year. Each TDC 262 | maintainer may nominate up to two (2) candidates for election, except that 263 | only one (1) nominee may be employed by the TDC maintainer’s own company. 264 | The second group from which five (5) TOB members shall be elected, will be 265 | nominated and elected by the OCI Members and serve for a period of two (2) 266 | years. Each OCI Member may nominate one (1) candidate for election. 267 | 268 | h. Initial elections of TOB members shall be run using the Condorcet-IRV method 269 | through the Cornell online service (http://civs.cs.cornell.edu/). The TOB 270 | may change the methodology or service used in future elections via a 271 | two-thirds approval vote of the then-serving TOB. 272 | 273 | i. The TOB shall elect a TOB Chair. The nominee with the most votes from the 274 | TOB members shall win the Chair position for a term of one (1) year. In the 275 | event of a tie vote, a random selection process (e.g. coin toss) shall be 276 | used to determine the winner. The TOB Chair shall have the responsibility to 277 | call meetings of the TOB and set TOB meeting agendas with input from TOB 278 | members. 279 | 280 | j. The TOB shall meet on an as-needed basis, in a timely manner after issues 281 | are directed to the TOB from: 282 | 283 | - i. the TDC by a simple majority vote of the maintainers when there is an 284 | issue that needs the resolution to assist the TDC to move forward, 285 | - ii. as the TOB determines via vote of at least two-thirds of the TOB 286 | members 287 | - iii. the TOB Chair determines a meeting is necessary. 288 | 289 | k. TOB meetings may be held in-person or via telephone or electronic 290 | conferencing. 291 | 292 | l. Issues should be referred to the TOB sufficiently in advance of a meeting to 293 | provide an appropriate time for TOB members to evaluate the issues, and the 294 | positions of the TDC, the positions of users, as well as sufficient time to 295 | explore compromise solutions. It is expected an appropriate review should 296 | require at least a two-week review period, though it is recognized some 297 | timecritical circumstances may call for a shorter review (e.g. security 298 | issues). 299 | 300 | m. Quorum for holding meetings shall be established when two-thirds of TOB 301 | members are present. 302 | 303 | n. The intention is for the TOB to operate by consensus. However, if consensus 304 | cannot be achieved, the Trademark Board shall vote on a decision. All TOB 305 | Votes, either at TOB meetings, via email or electronic voting service, shall 306 | pass with a two-thirds vote of votes cast, on a one (1) vote per TOB member 307 | basis. An abstain vote equals not voting at all. 308 | 309 | o. Any issues that cannot be resolved by the TOB shall be referred to The Linux 310 | Foundation Executive Director for mediation, and, if necessary, for 311 | resolution by The Linux Foundation Board of Directors. 312 | 313 | p. OCI Working Groups. 314 | 315 | - i. The OCI may establish one or more working groups (each, an “OCI Working 316 | Group”) to experiment, validate, and define new OCI Specifications or 317 | major revisions to existing OCI Specifications. Each OCI Working Group 318 | shall have a defined scope of the OCI Working Group's intended activities 319 | and goals. The end result of the OCI Working Group's work product shall be 320 | either: 321 | - an update to an existing OCI Specification (for example, adding 322 | support for a new set of features); 323 | - a new OCI Specification (for example, creating an OCI Specification 324 | for a new topical area); or 325 | - a new OCI Project other than a Specification (for example, creating a 326 | reference implementation of an OCI Specification). 327 | 328 | - ii. Any participant in the OCI technical community may propose a working 329 | group to the TOB for consideration. The TOB shall maintain a public list 330 | of the information required to be included in a working group proposal. 331 | 332 | - iii. Approval of a new OCI Working Group requires a two-thirds vote of the 333 | TOB. The TOB will maintain a public list of all approved OCI Working 334 | Groups. 335 | 336 | - iv. Once an OCI Working Group determines that it has achieved its 337 | objectives, the OCI Working Group leaders shall present to the TOB the 338 | draft specification or other project, along with such other information as 339 | the TOB may require for evaluation of the draft specification or other 340 | project. The TOB shall maintain a public list of such required information. 341 | 342 | - v. Approval of the draft specification (to be released as an OCI 343 | Specification) or other draft project (to become an OCI Project) shall 344 | require a two-thirds vote of the TOB. For a draft specification, prior to 345 | such approval the OCI Working Group may not describe it as a released OCI 346 | Specification, and must designate it with a `-draft.#` suffix. 347 | 348 | - vi. Following TOB approval of a draft specification to be released as an 349 | OCI Specification, the OCI Specification's maintainers may determine the 350 | process for making subsequent releases, provided that (1) such process is 351 | subject to TOB review, approval and modification, and (2) following any 352 | release of a new version of an OCI Specification, OCI shall notify all 353 | Members as set forth in Section 8(d) of this Charter. 354 | 355 | - vii. The TOB may, by a two-thirds vote, approve requests from the owners 356 | of an OCI Working Group to (a) amend the OCI Working Group's governance 357 | document, or (b) adjust the composition of the owners or maintainers of 358 | that OCI Working Group. The TOB may also, by a two-thirds vote, elect to 359 | disband an OCI Working Group in its discretion, including if the TOB 360 | determines that the OCI Working Group has not made meaningful progress or 361 | has become inactive. 362 | 363 | ## 7. OCI Values. 364 | 365 | The TDC and TOB shall strive to reflect and adhere to the following values 366 | (“OCI Values”) for OCI Projects: 367 | 368 | a. Composable. All tools for downloading, installing, and running containers 369 | should be well integrated, but independent and composable. A container 370 | runtime should not be bound to clients, to higher-level frameworks, etc. 371 | 372 | b. Portable. The runtime standard should be usable across different hardware, 373 | operating systems, and cloud environments. 374 | 375 | c. Secure. Isolation should be pluggable, and the cryptographic primitives for 376 | strong trust, image auditing and application identity should be solid. 377 | 378 | d. Decentralized. Discovery of container images should be simple and facilitate 379 | a federated namespace and distributed retrieval. 380 | 381 | e. Open. The format and runtime should be well-specified and developed by a 382 | community. OCI encourages independent implementations of tools to be able to 383 | run the same container consistently. Within the OCI Community, code 384 | development leads specification development, rather than vice-versa. The OCI 385 | Community seeks rough consensus and running code. 386 | 387 | f. Minimalist. The OCI Specifications should aim to do a few things well, be 388 | minimal and stable, and enable innovation and experimentation above and 389 | around it. 390 | 391 | g. Backward compatible. The first version of the OCI Specification should 392 | strive to be backwards compatible with the initial container image format 393 | and runtime contribution. OCI Specifications and code should strive to be 394 | backward compatible with the prior releases of the OCI Specification. 395 | 396 | ## 8. OCI IP Policy. 397 | 398 | a. All new inbound contributions to OCI will be made under the Apache License, 399 | Version 2.0 (available at http://www.apache.org/licenses/LICENSE-2.0) 400 | accompanied by a Developer Certificate of Origin sign-off 401 | (http://developercertificate.org). All contributions by Member employees 402 | will bind their employers in accordance with this policy, including the 403 | patent and copyright license grants in the Apache License, Version 2.0. 404 | 405 | b. All outbound code and documentation will be made available under the Apache 406 | License, Version 2.0. 407 | 408 | c. If an alternative inbound or outbound license is required for compliance 409 | with the license for a leveraged open source project, is otherwise required 410 | to achieve OCI’s mission or is in the best interests of OCI, the TOB may 411 | approve the use of an alternative license for inbound or outbound 412 | contributions on an exception basis. Please email tob@opencontainers.org to 413 | obtain exception approval. 414 | 415 | d. Upon finalization and release of a new version of any OCI specification, OCI 416 | will notify all Members in writing using the contact information provided in 417 | Exhibit A. As set forth in Section 12 of this Charter, Members may resign 418 | from membership in OCI at any time within thirty (30) days following such 419 | notification to avoid undertaking further obligations with respect to such 420 | specification. All Members on the date thirty (30) days following such 421 | notification will, without further action, be subject to the obligations set 422 | forth in the Open Web Foundation Final Specification Agreement (OWFa 1.0) 423 | (Patent Only) with respect to such specification. 424 | https://www.openwebfoundation.org/the-agreements/the-owf-1-0-agreements-granted-claims/owfa-1-0-patent-only 425 | 426 | e. On the effective date of their membership, all Members will, without further 427 | action, be subject to the obligations set forth in the OWFa 1.0 (Patent 428 | Only) with respect to the current and one immediately prior version of all 429 | OCI specifications, a version being a numerically designated version of the 430 | specification formally released following the thirty day period provided for 431 | in (d) above. Each new version of the specification will be designated by a 432 | change in the number to the left of the decimal point (x in an x.y format 433 | where y designates interim update releases). 434 | 435 | ## 9. Antitrust Guidelines 436 | 437 | a. All Members shall abide by The Linux Foundation Antitrust Policy available 438 | at http://www.linuxfoundation.org/antitrust-policy. 439 | 440 | b. All Members shall encourage open participation from any organization able to 441 | meet the membership requirements, regardless of competitive interests. Put 442 | another way, the OCI shall not seek to exclude any entity or any individual 443 | from OCI membership or OCI Project participation based on any criteria, 444 | requirements or reasons other than reasonable and appropriate criteria and 445 | requirements approved under this Charter and applied in a nondiscriminatory 446 | fashion to all. 447 | 448 | ## 10. Budget 449 | 450 | a. The Trademark Board shall approve an annual budget and never commit to spend 451 | in excess of OCI membership and other OCI directed funds raised byThe Linux 452 | Foundation from all sources, including OCI membership fees. The budget and 453 | all OCI activities shall be consistent with the non-profit mission of The 454 | Linux Foundation. 455 | 456 | b. So long as funds are sufficient, the OCI Budget shall include funds for a 457 | parttime program manager, or at the Trademark Board’s discretion, an 458 | Executive Director, to assist OCI with project management, organizing 459 | meetings and assisting in driving initiatives of the Trademark Board, TDC or 460 | TOB. 461 | 462 | c. The Linux Foundation shall provide regular reports of spend levels against 463 | the budget. 464 | 465 | d. The Linux Foundation shall have custody of and final authority over the 466 | usage of all OCI fees, funds and other cash receipts. To the extent that OCI 467 | acquires ownership in any intellectual property, ownership shall reside in 468 | The Linux Foundation. 469 | 470 | ## 11. The Linux Foundation General Rules and Operations. 471 | 472 | The OCI, and as appropriate, its Members and participants, shall operate under 473 | such rules and policies as may from time to time be applicable to Linux 474 | Foundation hosted projects, and, in addition, shall: 475 | 476 | a. demonstrate plans and the means to coordinate with the TDC, including on 477 | topics such as branding, logos, and other collateral that will represent the 478 | OCI Community; 479 | 480 | b. engage in a professional manner consistent with maintaining a cohesive 481 | community, while also maintaining the goodwill and esteem of The Linux 482 | Foundation in the open source software community; 483 | 484 | c. respect the rights of all trademark owners, including any branding and usage 485 | guidelines; 486 | 487 | d. engage The Linux Foundation for all OCI press and analyst relations 488 | activities; 489 | 490 | e. upon request, provide information regarding OCI Project participation, 491 | including information regarding attendance, to The Linux Foundation; 492 | 493 | f. engage The Linux Foundation for creation and management of any websites 494 | relating directly to the OCI; and 495 | 496 | g. operate under such rules and procedures as may from time to time be approved 497 | by the OCI and confirmed by The Linux Foundation Board of Directors. 498 | 499 | ## 12. Amendments and Notice 500 | 501 | a. This Charter may be amended by a two thirds vote of the Technical Oversight 502 | Board, subject to veto by The Linux Foundation Board of Directors for 503 | reasonable cause, with thirty (30) days’ notice to the OCI Members before 504 | taking effect. 505 | 506 | b. A Member may resign within such thirty-day notice period, or within the 507 | period provided for in Section 8 (d) of this Charter, to avoid undertaking 508 | any obligations imposed by any such amendment, or further obligations with 509 | respect to a specification, on a going forward basis. Such resignation will 510 | not have any effect on commitments made by the OCI Member or participant 511 | during the term of membership. Resignation may be made by email to the 512 | Executive Director of the Linux Foundation. 513 | -------------------------------------------------------------------------------- /EMERITUS.md: -------------------------------------------------------------------------------- 1 | # OCI TOB Emeritus Members 2 | 3 | We would like to acknowledge previous OCI TOB members and their huge contributions to our collective success: 4 | 5 | * Taylor Brown [Microsoft] (term finished: 1/29/2020) 6 | * Stephen Day [Cruise] (term finished: 1/29/2020) 7 | * Mrunal Patel [Red Hat] (term finished: 1/29/2020) 8 | * Michael Crosby [Apple] (term finished: 1/29/2021) 9 | * Wei Fu [Alibaba] (term finished: 1/29/2022) 10 | * Steve Lasker [Microsoft] (term finished: 1/29/2022) 11 | * Tycho Anderson [Cisco] (term finished: 1/29/2023) 12 | * Josh Dolitsky [Chainguard] (term finished: 1/29/2024) 13 | * Jon Johnson [Chainguard] (term finished: 1/29/2024) 14 | * Nisha Kumar [Oracle] (term finished: 1/29/2024) 15 | * Vincent Batts [Microsoft] (term finished: 1/29/2025) 16 | * Derek McGowan [Docker] (term finished: 1/29/2025) 17 | 18 | We thank these members for their service to the OCI community. 19 | -------------------------------------------------------------------------------- /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 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Technical Oversight Board (TOB) 2 | 3 | The TOB is responsible for managing conflicts, violations of procedures or guidelines and any cross-project or high-level issues that cannot be resolved in the TDC for OCI Projects. The TOB shall also be responsible for adding, removing or reorganizing OCI Projects. 4 | 5 | ## Members 6 | 7 | * **Sajay Antony [Microsoft]** (term date: 1/29/2024 - 1/29/2026) 8 | * **Mike Brown [IBM]** (term date: 1/29/2025 - 1/29/2027) 9 | * **Ramkumar Chinchani [Cisco]** (term date: 1/29/2024 - 1/29/2026) 10 | * **Phil Estes [AWS]** (term date: 1/29/2022 - 1/29/2026) 11 | * **Tianon Gravi [Docker]** (term date: 1/29/2025 - 1/29/2027) 12 | * **Samuel Karp [Google]** (term date: 1/29/2022 - 1/29/2026) [Chair] 13 | * **Brandon Mitchell [Independent]** (term date: 1/29/2025 - 1/29/2027) 14 | * **Aleksa Sarai [SUSE]** (term date: 1/29/2025 - 1/29/2027) 15 | * **Giuseppe Scrivano [Red Hat]** (term date: 1/29/2024 - 1/29/2026) 16 | 17 | ## Contact 18 | 19 | ### Mailing-list 20 | 21 | 22 | 23 | ### Github team 24 | 25 | @opencontainers/tob 26 | 27 | ## Project Proposals 28 | 29 | * [Artifacts](proposals/artifacts.md) 30 | * [Digest](proposals/digest.md) 31 | * [Distribution Spec](proposals/distribution.md) 32 | * [Image Format Spec](proposals/image-format) 33 | * [SELinux](proposals/selinux.md) 34 | * [Tools](proposals/tools.md) 35 | * [umoci](proposals/umoci.md) 36 | 37 | ## Voting 38 | 39 | In various situations ([2.c, 6.h, 6.j, 6.n](https://github.com/opencontainers/tob/blob/master/CHARTER.md)) the TOB shall hold a vote. These votes can happen on the phone, email, or via a voting service, when appropriate. 40 | 41 | TOB members can either respond "agree, yes, +1", "disagree, no, -1", or "abstain". A vote passes with two-thirds vote of votes cast. An abstain vote equals not voting at all. 42 | 43 | ## Code of Conduct 44 | 45 | Participation in the OpenContainers community is governed by [OpenContainer's Code of Conduct][code-of-conduct]. 46 | 47 | ## Security 48 | 49 | If you find an issue, please follow the [security][security] protocol to report it. 50 | 51 | ## Meeting Minutes 52 | 53 | * [April 6th, 2020](https://hackmd.io/kKl1ECKnSLWhgk7dZ2WUFQ) 54 | * [Mar 2nd, 2020](https://hackmd.io/kKl1ECKnSLWhgk7dZ2WUFQ) 55 | * [Feb 23rd, 2016](https://docs.google.com/presentation/d/1thxH4PVmHZO3kWrrLL6H1jAhL4r31Zy8xn8wg1LCmjY/edit#slide=id.p3) 56 | * [Mar 4th, 2016](https://docs.google.com/presentation/d/1sHnTyM5S9IGt4jmdlI2D6dzl_8EBSIaRD0oNvmu7ILQ/edit?ts=56d86a8b#slide=id.p3) 57 | * [Mar 18th, 2016](https://docs.google.com/presentation/d/1tANha5hGnOiMh7DAfVhJ5fNwFLXd0iAqrYLGmPZu94I/edit#slide=id.g11f2d5d0f8_4_4) 58 | 59 | [security]: https://github.com/opencontainers/org/blob/master/security 60 | [code-of-conduct]: https://github.com/opencontainers/org/blob/master/CODE_OF_CONDUCT.md 61 | -------------------------------------------------------------------------------- /WG-INFO.md: -------------------------------------------------------------------------------- 1 | # OCI Working Groups 2 | 3 | ## List of current OCI Working Groups 4 | 5 | * [Auth](proposals/wg-auth.md) 6 | * [Image Compatibility](proposals/wg-image-compatibility.md) 7 | 8 | ## List of disbanded OCI Working Groups 9 | 10 | * [Reference types](proposals/wg-reference-types.md) delivered the following changes: 11 | * [image-spec PR #934](https://github.com/opencontainers/image-spec/pull/934) 12 | * [distribution-spec PR #335](https://github.com/opencontainers/distribution-spec/pull/335) 13 | 14 | ## Required information for OCI Working Group Proposals 15 | 16 | OCI Working Group proposals should contain the following information: 17 | 18 | 1. a clearly defined objective and scope of what the working groups aims to 19 | accomplish 20 | 1. a list of owners who have agreed to participate in the working group, review 21 | progress, report progress back to the OCI community, and present the results 22 | to the TOB once the working group has completed its objectives 23 | 1. a list of OCI Projects, non-OCI projects, or organizations sponsoring the 24 | working group and participating in the implementation and use case 25 | validation of the work done by the group 26 | 1. a set of project rules which govern how contributions to the working group 27 | will be handled and decisions will be made 28 | 1. a working agreement for making progress, which may include weekly meetings, 29 | dedicated channels for discussions, or a shared repository 30 | 1. a request for OCI resources, which may include recurring meetings in the OCI 31 | calendar, OCI hosted repository, or topic specific communication channels 32 | 33 | ## Required information for TOB Release Approval 34 | 35 | When an OCI Working Group determines that it has completed its initial work and 36 | is prepared to request TOB approval for the initial release of its outputs as 37 | an OCI Specification or other OCI Project, the OCI Working Group owners will 38 | present to the TOB the following: 39 | 40 | * the draft specification or project content 41 | * the validation work which demonstrates real world usability 42 | * the set of maintainers who have agreed to carry the specification forward 43 | 44 | There is no requirement that owners or contributors to the OCI Working Group 45 | will continue to be maintainers for an approved OCI Specification or other OCI 46 | Project after TOB approval and release. However, the TOB will consider it a 47 | requirement that any approved OCI Specification or other OCI Project has a dedicated 48 | and active group of maintainers to continue the work. 49 | -------------------------------------------------------------------------------- /WG-TEMPLATE.md: -------------------------------------------------------------------------------- 1 | # OCI Working Group Template 2 | 3 | The following is a template that the TOB and/or proposers of a new OCI Working Group may use to document the intended scope and activities of the OCI Working Group following its establishment. {Bracketed sections below} should be filled in with the Working Group's specific details. 4 | 5 | # {WG NAME} OCI Working Group - Governance Charter 6 | 7 | This document describes the basic governance principles for the {WG NAME} Working Group (the “WG”). 8 | 9 | The WG operates as an OCI Working Group under the [Open Container Initiative (OCI) Charter](https://github.com/opencontainers/tob/blob/master/CHARTER.md), which describes the responsibilities of the OCI Technical Oversight Board (the "TOB”). The WG is established by the TOB as an OCI Working Group pursuant to the OCI Charter. Accordingly, the WG will operate in accordance with the OCI Charter and OCI's other policies and procedures, supplemented by the details below. 10 | 11 | ## Purpose 12 | 13 | {Briefly describe the purpose of the WG.} 14 | 15 | ## Scope 16 | 17 | * {Describe the activities and work that are in scope for the WG.} 18 | 19 | ## Out of Scope 20 | 21 | * {Where helpful for clarity or to avoid confusion, describe any activities or topics that are out of scope for the WG.} 22 | 23 | ## Intended work product 24 | 25 | * {Describe the intended work product and outputs of the WG, particularly indicating whether they consist of specification(s) and/or other project(s).} 26 | 27 | ## Proposed Owners 28 | 29 | The following have agreed to participate in the working group, review progress, report progress back to the OCI community, and present the results to the TOB once the working group has completed its objectives. 30 | 31 | * {List proposed owners.} 32 | 33 | ## Stakeholders 34 | 35 | OCI Projects, non-OCI projects, or organizations sponsoring the working group and participating in the implementation and use case validation of the work done by the group. 36 | 37 | * {List proposed stakeholders.} 38 | 39 | ## Related Issues/PRs 40 | 41 | * {List any issues that would be resolved by this working group.} 42 | 43 | ## Governance 44 | 45 | * **Working Group**: 46 | * The TOB is establishing the WG as an OCI Working Group, pursuant to [section 6(p)](https://github.com/opencontainers/tob/blob/master/CHARTER.md#6-technical-oversight-board-tob) of the OCI Charter. 47 | * **Owners**: 48 | * The WG proposal to the TOB will specify one or more initial "owners" of the WG. 49 | * The current owners will be listed in the [OCI Working Group documentation](https://github.com/opencontainers/tob/blob/master/WG-INFO.md). 50 | * The owners shall be responsible for: 51 | * scheduling regular meetings of the WG community; 52 | * facilitating open discussion among WG community participants; 53 | * coordinating and managing the development of the WG work product and outputs; 54 | * recording decisions that are reached by the WG community; and 55 | * keeping the TOB regularly informed about the status of the WG’s efforts, including when the WG has readied the work product and outputs for TOB approval. 56 | * **Maintainers**: 57 | * If the WG owners request the TOB to approve a draft specification as a released OCI Specification, the request shall include a list of proposed "maintainers" of the OCI Specification. 58 | * The current maintainers will be listed in the [OCI Working Group documentation](https://github.com/opencontainers/tob/blob/master/WG-INFO.md). 59 | * The maintainers shall be responsible for continuing the work of overseeing updates, improvements and changes to a released OCI Specification on an ongoing basis. 60 | * **Meetings**: 61 | * Meetings of the WG shall be open to the public. 62 | * Participants in the meetings shall comply with the [OCI Code of Conduct](https://github.com/opencontainers/.github/blob/master/CODE_OF_CONDUCT.md) and all other policies of OCI and The Linux Foundation. 63 | * **TOB Approval**: 64 | * The WG shall operate pursuant to the procedures set forth in [section 6(p)](https://github.com/opencontainers/tob/blob/master/CHARTER.md#6-technical-oversight-board-tob) of the OCI Charter, with regards to obtaining TOB approval for initial release of the work product and outputs as an OCI Specification or other OCI Project, and for subsequent maintenance activities thereafter. 65 | * **Amendments**: 66 | * The owners of the WG may from time to time propose to the TOB (1) amendments to this WG Governance Document, and/or (2) changes to the composition of the owners or maintainers of the WG. 67 | * As set forth in the OCI Charter, the TOB may, in its discretion by a two-thirds vote, approve or reject the requested amendments or changes. 68 | * As set forth in the OCI Charter, the TOB may also disband the WG by a two-thirds vote. 69 | -------------------------------------------------------------------------------- /proposals/artifacts.md: -------------------------------------------------------------------------------- 1 | # OCI Artifacts Project Proposal 2 | 3 | ## Abstract 4 | 5 | Container registries, implementing the [OCI distribution-spec][distribution-spec], provide reliable, highly scalable, secured storage services for container images. Customers use cloud provider implementations, vendor implementations, and instances of the open source implementation of docker distribution. They configure security and networking to assure the images in the registry are locked down and accessible by the resources required. Cloud providers and vendors often provide additional value atop their registry implementations from security to productivity features. 6 | 7 | Applications and services typically require additional artifacts to deploy and manage container images, including [helm](https://helm.sh) charts for deployment and [Open Policy Agent (OPA) bundles](https://github.com/open-policy-agent/opa/issues/1413) for policy enforcement. 8 | 9 | Utilizing the [OCI manifest][image-manifest] and [OCI index][image-index] definitions, new artifact types can be stored and served using the [OCI distribution-spec][distribution-spec] without changing the actual distribution spec. This repository will provide a reference for artifact authors and registry implementors for supporting these new artifact types themselves with the existing implementations of distribution. 10 | 11 | By providing support for OCI artifact types over OCI distributions, the community can continue to innovate, focusing on new artifact types without having to build yet another storage solution (YASS). 12 | 13 | ## Proposal 14 | 15 | Under the [github.com/opencontainers](http://github.com/opencontainers) organization: 16 | 17 | - Create a new **artifacts** repository, named [github.com/opencontainers/artifacts](http://github.com/opencontainers/artifacts) 18 | - Update the [OCI distribution-spec][distribution-spec] to generically reference [OCI manifest][image-manifest] and [OCI index][image-index], with [OCI Image][image-spec] as one of many artifact types it can store. 19 | - Update the [OCI image-spec][image-spec] to reference images as an implementation of artifacts, using [OCI manifest][image-manifest] and [OCI index][image-index] 20 | 21 | ## Contents 22 | 23 | The repository will serve 3 primary goals: 24 | 25 | 1. **artifact authors** - guidance for authoring new artifact types. Including a clearing house for well known artifact types. 26 | 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 `media-type` filtering will not have to change. The artifact repo will provide context on how new `media-type`s can be used, and how `media-type`s can be associated with a type of artifact. 27 | 1. **clearing house for well known artifacts** - artifact authors can submit their artifact definitions, providing registry operators a list by which they can easily support. 28 | 29 | ### Process for Approving New Artifact Definitions 30 | 31 | 1. Proposals for new artifact types should be opened as pull requests on the artifact repository 32 | 1. The artifact project maintainers will review new proposals, ask clarifying questions, and choose or not to accept the suggested artifact type 33 | 1. Acceptance requires at least 2 +1s from the maintainers (currently 3 maintainers) 34 | 1. Where the submitter disagrees strongly with the decision they can bring to the issue to the TOB for a vote, under the current voting rules. 35 | 36 | ### Initial Maintainers 37 | 38 | Initial maintainers of the artifacts project would be : 39 | 40 | - Steve Lasker (@stevelasker) 41 | - Derek McGowan (@derekmcgowan) 42 | - Mike Brown (@mikebrow) 43 | - Stephen Day (@stevvooe) 44 | 45 | ### Code of Conduct 46 | 47 | This project would incorporate (by reference) the [OCI Code of Conduct][code-of-conduct]. 48 | 49 | ### Governance and Releases 50 | 51 | This project would further incorporate the Governance and Releases processes from the OCI project template: [github.com/opencontainers/project-template](https://github.com/opencontainers/project-template). 52 | 53 | ### Project Communications 54 | 55 | This project would continue to use existing channels in use by the [OCI developer community for communication](https://github.com/opencontainers/org#communications) 56 | 57 | ### Versioning / Roadmap 58 | 59 | This repository will not be versioned, but will be continuously updated with a list of versioned types with historical references. This repository will not have releases. 60 | 61 | Artifacts will reference specific [OCI distribution][distribution-spec], [OCI index][image-index] and [OCI manifest][image-manifest] versions in its examples and references for capabilities. 62 | 63 | ## Frequently Asked Questions (FAQ) 64 | 65 | **Q: Does this change the OCI Charter or Scope Table?** 66 | 67 | A: No. Artifacts are a prescriptive means of storing [OCI index][image-index] and [OCI manifest][image-manifest] within [OCI distribution][distribution-spec] implementations. 68 | 69 | [distribution-spec]: https://github.com/opencontainers/distribution-spec/ 70 | [image-spec]: https://github.com/opencontainers/image-spec/ 71 | [code-of-conduct]: https://github.com/opencontainers/org/blob/master/CODE_OF_CONDUCT.md 72 | [image-manifest]: https://github.com/opencontainers/image-spec/blob/master/manifest.md 73 | [image-index]: https://github.com/opencontainers/image-spec/blob/master/image-index.md 74 | -------------------------------------------------------------------------------- /proposals/cgroups.md: -------------------------------------------------------------------------------- 1 | # OCI cgroups project proposal 2 | 3 | ## Abstract 4 | Having a common cgroups management implementation in OCI for use in and outside 5 | of runc will ensure long lasting security and interoperability throughout the 6 | container ecosystem. 7 | 8 | ## Proposal 9 | 10 | Refactor and move cgroups packages out of runc into a separate project: 11 | 12 | https://github.com/opencontainers/runc/tree/master/libcontainer/cgroups 13 | 14 | The new project would live in the opencontainers github organization: 15 | 16 | https://github.com/opencontainers/cgroups 17 | 18 | A sample of how the project would look like is already here: 19 | 20 | https://github.com/kolyshkin/opencontainers-cgroups 21 | 22 | ### Initial Maintainers 23 | Initial maintainers of the cgroups project would be: 24 | 25 | * Akihiro Suda (@AkihiroSuda) 26 | * Aleksa Sarai (@cyphar) 27 | * Kir Kolyshkin (@kolyshkin) 28 | * Mrunal Patel (@mrunalp) 29 | * Sebastiaan van Stijn (@thaJeztah) 30 | * Odin Ugedal (@odinuge) 31 | * Peter Hunt (@haircommander) 32 | * Davanum Srinivas (@dims) 33 | 34 | ### Code of Conduct 35 | This project would incorporate (by reference) the OCI [Code of Conduct][code-of-conduct]. 36 | 37 | ### Governance and Releases 38 | This project would incorporate the Governance and Releases processes from the 39 | OCI project template: https://github.com/opencontainers/project-template. 40 | 41 | ### Project Communications 42 | The proposed project would continue to use existing channels in use by the OCI 43 | developer community for communication including: 44 | * GitHub for issues and pull requests 45 | * The dev@opencontainers.org email list 46 | * The weekly OCI developer community conference call 47 | * The #OpenContainers IRC channel 48 | 49 | ### Versioning / Roadmap 50 | 51 | We'll start with v0.x until everything is stabilized after the split. 52 | 53 | The plan is to have frequent releases to accommodate various users. 54 | 55 | ## Frequently Asked Questions (FAQ) 56 | *Q: Does this change the OCI Charter or Scope Table?* 57 | A: No. Nothing in this proposal is intended to amend the 58 | [OCI Charter](https://www.opencontainers.org/about/governance) or 59 | [OCI Scope Table](https://www.opencontainers.org/about/oci-scope-table). 60 | 61 | *Q: Why move this out of the runc project?* 62 | A: To be able to reuse this in different container projects, while avoiding 63 | code duplication and fragmentation. This involves adding functionality and 64 | cutting releases to accomodate existing users other than runc. 65 | 66 | Here's an example: kubernetes needs PSI stats from cgroups, and while the 67 | low-level functionality needed 68 | ([runc PR #3900](https://github.com/opencontainers/runc/pull/3900)) 69 | was merged in July 2023, it was only made available to kubernetes when runc 70 | v1.2.0 was tagged in October 2024. Such delays might result in using 71 | unversioned dependencies, or copying the code around and thus fragmentation. 72 | 73 | A longer term goal is make this set of packages even more modular, avoiding 74 | excessive third-party dependencies. 75 | 76 | *Q: Who are the other target users of these packages?* 77 | 78 | A: CRI-O, kubernetes, cadvisor. 79 | 80 | [code-of-conduct]: https://github.com/opencontainers/org/blob/master/CODE_OF_CONDUCT.md 81 | -------------------------------------------------------------------------------- /proposals/digest.md: -------------------------------------------------------------------------------- 1 | # OCI go-digest project proposal 2 | 3 | ## Abstract 4 | [image-spec#486][image-spec-486] introduces a dependency on a stable upstream implementation of https://github.com/docker/go-digest, which was recently broken out of the https://github.com/docker/distribution project. 5 | 6 | This package has been instrumental in providing a strong hash-identity implementation in Go and we will extend this to OCI. This will be supported by moving https://github.com/opencontainers/go-digest to OCI. While this package does support opencontainers/image-spec, it is broadly useful in other image formats or outside image formats. 7 | 8 | Having a solid, battle-proven, common digest implementation in OCI for use in and outside the image-spec will ensure long lasting security and interoperability throughout the container ecosystem. 9 | 10 | ## Proposal 11 | With repositories under the http://github.com/opencontainers organization: 12 | 13 | Rename (transfer) https://github.com/docker/go-digest would become https://github.com/opencontainers/go-digest. 14 | 15 | ### Initial Maintainers 16 | Initial maintainers of the go-digest project would be seeded from the image-spec project: 17 | * Brandon Philips (@philips) 18 | * Brendan Burns (@brendandburns) 19 | * Jason Bouzane (@jbouzane) 20 | * John Starks (@jstarks) 21 | * Jonathan Boulle (@jonboulle) 22 | * Stephen Day (@stevvooe) 23 | * Vincent Batts (@vbatts) 24 | 25 | ### Code of Conduct 26 | This project would incorporate (by reference) the OCI [Code of Conduct][code-of-conduct]. 27 | 28 | ### Governance and Releases 29 | This project would incorporate the Governance and Releases processes from the OCI project template: https://github.com/opencontainers/project-template. 30 | 31 | ### Project Communications 32 | Both of the proposed projects would continue to use existing channels in use by the OCI developer community for communication including: 33 | * GitHub for issues and pull requests 34 | * The dev@opencontainers.org email list 35 | * The weekly OCI developer community conference call 36 | * The #OpenContainers IRC channel 37 | 38 | ### Versioning / Roadmap 39 | We will probably minimize the releases of this project. 40 | 41 | It will provide digesting functionality for all present and future versions of the specification. 42 | 43 | ## Frequenty Asked Questions (FAQ) 44 | 45 | **Q: Does this change the OCI Charter or Scope Table?** 46 | 47 | A: No. Nothing in this proposal is intended to amend the OCI Charter (https://www.opencontainers.org/about/governance) or OCI Scope Table (https://www.opencontainers.org/about/oci-scope-table). 48 | 49 | [image-spec-486]: https://github.com/opencontainers/image-spec/pull/486 50 | [code-of-conduct]: https://github.com/opencontainers/org/blob/master/CODE_OF_CONDUCT.md 51 | -------------------------------------------------------------------------------- /proposals/distribution.md: -------------------------------------------------------------------------------- 1 | # Abstract 2 | 3 | The Docker registry protocol has become the defacto standard across the container registry world. 4 | 5 | In the OCI, having a solid, common distribution specification with conformance testing will ensure long lasting security and interoperability throughout the container ecosystem. 6 | 7 | ## Proposal 8 | 9 | TL;DR; Move [`api.md`][api.md] to a new [distribution-spec project](https://github.com/opencontainers/distribution-spec). 10 | 11 | This proposal covers the distribution API spec, and while it does not cover the code for the docker-registry, that implementation is considered the reference implementation. There are other implementations of this protocol, not all are open-source though (Google gcr.io, Amazon ECR, CoreOS Quay, Gitlab registry, JFrog Artifactory registry, Huawei Dockyard, etc). 12 | 13 | In the past when the topic of having an OCI specification around the distribution of container images was discussed, it was deferred as "let’s get the image format defined, meanwhile the industry will settle on a distribution standard". Fast forward, OCI image format is out and adopted, and the Registry v2 is the defacto standard. There is and will be use-cases for alternate methods and the future will likely hold creative ways to push, fetch and share container images, but right now this promotion serves to acknowledge by the OCI the current industry standard of distributing container images. 14 | This proposal also provides the container ecosystem with a means to discuss and schedule extensions to the distribution specification. 15 | 16 | There is polish that is needed e.g. broken links to storage-driver docs, as well as making sections more generic regarding the OCI descriptors and media-types, but on the whole this is a lateral move. 17 | 18 | ## Initial Maintainers 19 | 20 | * Stephen Day (@stevvooe) 21 | * Vincent Batts (@vbatts) 22 | * Derek McGowan (@dmcgowan) 23 | 24 | Additional Maintainers to consider: 25 | 26 | * Ahmet Alp Balkan (Google) 27 | * Matt Moore (Google) 28 | * Yuwa (MSFT) 29 | * Clayton Coleman (Red Hat) 30 | * Antonio Murdaca (@runcom) (Red Hat) 31 | * Samuel Karp (@samuelkarp) (AWS) 32 | * Mike Brown (IBM) 33 | * Jimmy Zelinskie jimmy@coreos.com (@jzelinskie) 34 | * Liu Genping <[liugenping@huawei.com](mailto:liugenping@huawei.com)> 35 | * Vanessa Sochat (@vsoch) (Stanford) 36 | * Eduardo Arango (@ArangoGutierrez) (Sylabs) 37 | 38 | ## Code of Conduct 39 | 40 | This project would incorporate (by reference) the OCI [Code of Conduct][code-of-conduct]. 41 | 42 | ## Governance and Releases 43 | 44 | This project would incorporate the Governance and Releases processes from the OCI project template: [https://github.com/opencontainers/project-template](https://github.com/opencontainers/project-template). 45 | 46 | ## Project Communications 47 | 48 | Both of the proposed projects would continue to use existing channels in use by the OCI developer community for communication including: 49 | 50 | * GitHub for issues and pull requests 51 | * The dev@opencontainers.org email list 52 | * The monthly OCI developer community conference call 53 | * The #OpenContainers freenode IRC channel 54 | 55 | ## Versioning / Roadmap 56 | 57 | The API spec is currently considered v2 and we will start the specification at v2.0. Fewer places to change and compare, and it would keep with it being a lateral move. 58 | 59 | ## Frequently Asked Questions (FAQ) 60 | 61 | **Q: Does this include the code of the docker-registry?** 62 | 63 | A: No. This is an API specification discussion. 64 | 65 | **Q: Does this change the OCI Charter or Scope Table?** 66 | 67 | A: Not the charter, but it does change the scope table. 68 | This project is scoped to specifying per-image client ↔ registry interaction with an [HTTP][rfc7230]-based protocol. 69 | The following scope entries should be removed from the [scope table][scope]: 70 | 71 | * “Use of Hash as Content Addressable name for immutable containers”. 72 | This entry is in scope for this project, and a more detailed entry will be added as described below. 73 | * “Creating Reference spec for optional DNS based naming & distribution”. 74 | This entry conflates naming and distribution, which will be separated by this proposal. 75 | * “Standardizing on a particular Distribution method”. 76 | This proposal will provide one (of possibly many) distribution specifications, so the old “There is no current agreement on how to distribute content” no longer applies. 77 | 78 | The following entries should be added to the [scope table][scope]: 79 | 80 | * "Specifying authentication and authorization schemes". 81 | Docker's current registry uses an [extension][token] of the [`Bearer`][rfc6750] [auth scheme][rfc7235-s2.1]. 82 | Work on specifying Docker's scheme will continue independently, and is orthogonal to the registry API. 83 | 84 | * What: Specifying authentication and authorization schemes 85 | * In/Out/Future: Out of scope 86 | * Status: N/A 87 | * Description: Defining protocols for authenticating and authorizing distribution access. 88 | * Why: As an HTTP-based protocol, clients and servers can negotiate authentication via HTTP's [challenge-response authentication framework][rfc7235-s2.1]. 89 | 90 | * "Creating a reference spec for optional DNS based naming and discovery". 91 | Discovery and registry protocols are completely separate and do not need to be added together. 92 | This entry replaces part of the previous “Creating Reference spec for optional DNS based naming & distribution” entry. 93 | 94 | * What: Creating a reference spec for optional DNS based naming and discovery 95 | * In/Out/Future: In scope for future specification 96 | * Status: Work not yet started 97 | * Description: Define a protocol for resolving an image name to retrieval information. 98 | When we address this, we will also allow for alternative name-to-image discovery protocols in parallel with the OCI-specified protocol. 99 | * Why: It is reasonable to provide a standardized way to use DNS based distribution in conjunction with OCI without requiring its use. 100 | There are many good use cases for DNS based distribution, but not all use cases support this. 101 | Furthermore, encoding the location of a bundle into the bundle can cause issues with downloads from alternate locations other than the origin specified in the name. 102 | 103 | * "Specifying a distribution method". 104 | This entry replaces part of the previous "Creating Reference spec for optional DNS based naming & distribution" and "Standardizing on a particular Distribution method" entries. 105 | 106 | Tag-listing (e.g. "What named manifests are in `library/busybox`?") endpoints are in scope and required for backwards compatibility with clients. 107 | An endpoint for listing image repository names within a registry is considered out of scope for this specification. 108 | 109 | Managing the grouping of image repository names is considered part of distribution policy or content management, which are out of scope. 110 | For example, "Which image repositories are under `library/`?" is out of scope for this project. 111 | 112 | * What: Specifying a distribution method 113 | * In/Out/Future: In scope 114 | * Status: In progress (see opencontainers/distribution-spec) 115 | * Description: Define a protocol for creating, retrieving, updating, and deleting content-addressable objects, such as those defined in the [image specification][image-spec]. 116 | * Why: This specification will provide one (of possibly many) distribution specifications. 117 | Alternative distribution specifications may be developed for uses cases not covered by this specification, but defining them is currently out of scope for the OCI. 118 | 119 | * "Retrieving image content by its content-addressable hash". 120 | Docker's registry API already provides [endpoints for fetching manifest objects by digest][get-manifest]. 121 | Docker's registry API does not currently provide endpoints for fetching [image-index][] objects by digest, but this is the project where that will happen. 122 | 123 | * What: Retrieving image content by its content-addressable hash 124 | * In/Out/Future: In scope 125 | * Status: In progress (see opencontainers/distribution-spec) 126 | * Description: Specify a protocol for retrieving an [image index][image-index], [manifest][], or other [image specification][image-spec] object from a distribution engine by its content-addressable hash. 127 | * Why: Using a hash as a name is a way to ensure a unique image name without relying on a particular naming authority or system. 128 | Using hashing for name is an acceptable addition as it does not encode any centralized namespace. 129 | 130 | The following entries should remain in the [scope table][scope] but not be addressed by this project: 131 | 132 | * "Specifying way to attach signatures". 133 | We don't need to address this as part of distribution, because all resources are content-addressable and can be signed in external systems. 134 | 135 | ## Related GitHub Issues 136 | 137 | * Simplifies tag listing: docker/distribution#2169 138 | * Allows listing of manifests: docker/distribution#2199 139 | 140 | [api.md]: https://github.com/docker/distribution/blob/5cb406d511b7b9163bff9b6439072e4892e5ae3b/docs/spec/api.md 141 | [catalog]: https://github.com/docker/distribution/blob/5cb406d511b7b9163bff9b6439072e4892e5ae3b/docs/spec/api.md#catalog 142 | [code-of-conduct]: https://github.com/opencontainers/org/blob/master/CODE_OF_CONDUCT.md 143 | [get-manifest]: https://github.com/docker/distribution/blob/5cb406d511b7b9163bff9b6439072e4892e5ae3b/docs/spec/api.md#pulling-an-image-manifest 144 | [image-spec]: https://github.com/opencontainers/image-spec/ 145 | [image-index]: https://github.com/opencontainers/image-spec/blob/v1.0.1/image-index.md 146 | [manifest]: https://github.com/opencontainers/image-spec/blob/v1.0.1/manifest.md 147 | [manifests]: https://github.com/opencontainers/image-spec/blame/v1.0.1/image-index.md#L23 148 | [rfc6750]: https://tools.ietf.org/html/rfc6750 149 | [rfc7230]: https://tools.ietf.org/html/rfc7230 150 | [rfc7235-s2.1]: https://tools.ietf.org/html/rfc7235#section-2.1 151 | [scope]: https://www.opencontainers.org/about/oci-scope-table 152 | [token]: https://github.com/docker/distribution/blob/5cb406d511b7b9163bff9b6439072e4892e5ae3b/docs/spec/auth/token.md 153 | -------------------------------------------------------------------------------- /proposals/image-format/README.md: -------------------------------------------------------------------------------- 1 | # OCI Image Format Spec Proposal 2 | 3 | The TOB will create a new OCI project tasked with creating a software shipping container image format spec (OCI Image Format) with security and naming as components. In addition the OCI TOB will establish a new set of maintainers for this new project with people who have expertise in image formats and package management. 4 | 5 | ## Initial Recommendation 6 | 7 | This new OCI project would be recommended to start with the Docker v2.2 specification, improve any remaining technical concerns, and create an OCI project and maintainers to develop and shepherd an OCI Image Fromat Spec. By starting from this project we intend to standardize and improve the understood properties of a container image format. This new project will have the objectives of: 8 | 9 | * A serialized image format (base layer) 10 | * A process of hashing the image format for integrity and content-addressing (base layer) 11 | * Signatures that are based on signing image content address (optional layer) 12 | * Naming that is federated based on DNS and can be delegated (optional layer) 13 | 14 | Initial Maintainers: to be brainstormed on a separate thread. 15 | 16 | ## Cooperation with OCI Runtime Project 17 | 18 | The OCI Runtime Specs project is working diligently to create a specification for the lifecycle of a running container. The OCI Image Format Spec project should work with the OCI Runtime Spec project so that the image can support the UX that users have come to expect from container engines like Docker and rkt: primarily, the ability to run an image with no additional arguments: 19 | 20 | * docker run example.com/org/app:v1.0.0 21 | * rkt run example.com/org/app,version=v1.0.0 22 | 23 | This implies that the OCI Image Format contain sufficient information to launch the application on the target platform e.g. command, arguments, environment variables, etc. 24 | 25 | ## FAQ 26 | 27 | **Q: Why doesn't this project mention distribution?** 28 | 29 | A: Distribution, for example using HTTP as both Docker v2.2 and AppC do today, is currently out of scope on the [OCI Scope Table](https://www.opencontainers.org/about/oci-scope-table). There has been [some discussion on the TOB mailing list]( https://groups.google.com/a/opencontainers.org/d/msg/tob/A3JnmI-D-6Y/tLuptPDHAgAJ) to make distribution an optional layer but this topic is a work in progress. 30 | 31 | **Q: Why a new project?** 32 | 33 | A: The first OCI spec centered around defining the run side of a container. This is generally seen to be an orthogonal concern to the shipping container component. As practical examples of this separation you see many organizations separating these concerns into different teams and organizations: the Docker Distribution project and the Docker containerd project; Amazon ECS and Amazon EC2 Container Registry, etc. 34 | 35 | **Q: Why start this work now?** 36 | 37 | A: We are seeing many independent implementations of container image handling including build systems, registries, and image analysis tools. As an organization we would like to encourage this growth and bring people together to ensure a technically correct and open specification continues to evolve reflecting the OCI values. 38 | 39 | **Q: What happens to AppC or Docker Image Formats?** 40 | 41 | A: Existing formats can continue to be a proving ground for technologies, as needed. The OCI Image Format project should strive to provide a dependable open specification that can be shared between different tools and be evolved for years or decades of compatibility; as the deb and rpm format have. 42 | 43 | ## Proposed Roadmap 44 | 45 | * March ?? v0.0.0 46 | * Import Docker v2.2 format 47 | * April ??? v0.1.0 48 | * Spec factored for top to bottom reading with three audiences in-mind: 49 | * Build system creators 50 | * Image registry creators 51 | * Container engine creators 52 | * May ??? v0.2.0 53 | * Release version of spec with improvements from two independent experimental implementations from OCI members e.g. Amazon Container Registry and rkt 54 | * June ??? v1.0.0 55 | * Release initial version of spec with two independent non-experimental implementations from OCI members 56 | -------------------------------------------------------------------------------- /proposals/selinux.md: -------------------------------------------------------------------------------- 1 | # OCI go-selinux project proposal 2 | 3 | ## Abstract 4 | Having a solid, battle-proven, common selinux implementation in OCI for use in and outside of runc will ensure long lasting security and interoperability throughout the container ecosystem. 5 | 6 | ## Proposal 7 | Refactor and move the selinux library out of runc into a separate project: 8 | 9 | https://github.com/opencontainers/runc/tree/master/libcontainer/selinux 10 | 11 | The new project would live in the opencontainers github organization: 12 | 13 | https://github.com/opencontainers/go-selinux 14 | 15 | A sample of how the project would look like is already here: 16 | 17 | https://github.com/runcom/go-selinux 18 | 19 | ### Initial Maintainers 20 | Initial maintainers of the go-selinux project would be: 21 | 22 | * Antonio Murdaca (@runcom) 23 | * Daniel J Walsh (@rhatdan) 24 | * Mrunal Patel (@mrunalp) 25 | * Stephen Smalley (@stephensmalley) 26 | 27 | ### Code of Conduct 28 | This project would incorporate (by reference) the OCI [Code of Conduct][code-of-conduct]. 29 | 30 | ### Governance and Releases 31 | This project would incorporate the Governance and Releases processes from the OCI project template: https://github.com/opencontainers/project-template. 32 | 33 | ### Project Communications 34 | The proposed project would continue to use existing channels in use by the OCI developer community for communication including: 35 | * GitHub for issues and pull requests 36 | * The dev@opencontainers.org email list 37 | * The weekly OCI developer community conference call 38 | * The #OpenContainers IRC channel 39 | 40 | ### Versioning / Roadmap 41 | We will probably minimize the releases of this project. 42 | 43 | ## Frequently Asked Questions (FAQ) 44 | Q: Does this change the OCI Charter or Scope Table? 45 | A: No. Nothing in this proposal is intended to amend the [OCI Charter](https://www.opencontainers.org/about/governance) or [OCI Scope Table](https://www.opencontainers.org/about/oci-scope-table). 46 | 47 | *Q: Why move this out of the runc project?* 48 | 49 | A: To be able to reuse this in different container projects as well as have dedicated maintainers for the SELinux library. Getting more exposure and others to use it would probably lead to completing lots of features that are missing from the libcontainer/selinux bindings. There are lots of bindings in libselinux that do not have native bindings yet. Getting other projects to use SELinux bindings would also lead to potential improvements in the bindings. 50 | 51 | *Q: Why is versioning this package with runc insufficient today? What issues have been encountered?* 52 | 53 | A: There's no versioning of selinux in run. For instance, we fixed something in selinux in runc because CRI-O needed it but at the same time we broke docker which was relying on it. Having fixed versions for selinux wouldn't have led to this issue since docker could have stuck to a previous version and carefully test the new version w/o pulling new changes as part of a libcontainer library bump. 54 | 55 | *Q: Who are the other target users of go-selinux?* 56 | 57 | A: docker, rkt, CRI-O, kubernetes, any other project out there requiring a dedicated selinux library. 58 | 59 | [code-of-conduct]: https://github.com/opencontainers/org/blob/master/CODE_OF_CONDUCT.md 60 | -------------------------------------------------------------------------------- /proposals/tools.md: -------------------------------------------------------------------------------- 1 | # OCI Runtime-Tools and Image-Tools Project Proposals 2 | 3 | ## Abstract 4 | The below proposal contemplates creation of two tools projects (runtime-tools and image-tools.) 5 | These would be associated with the OCI specification projects (runtime-spec and image-spec) and serve as repositories for testing tools. 6 | 7 | ## Background 8 | Testing tools have been organically developed by the OCI developer community. 9 | These include: 10 | * Runtime-spec test code in a OCITools repository 11 | * Image-spec test code in the image-spec repository 12 | 13 | On Monday, August 22nd, 2016, the OCI Certification Program WG designated Chris Aniszczyk and Rob Dolin to draft a proposal for formalizing approval of tools. 14 | 15 | On Wednesday, August 24th, 2016, the OCI Developer Community (TDC) met and recommended establishing a tools repository corresponding to each of the spec repositories. 16 | 17 | ## Proposal 18 | With repositories under the http://github.com/OpenContainers organization: 19 | * Rename the OCITools repository as runtime-tools 20 | * Create a new repository named image-tools and populate this with the files from: https://github.com/opencontainers/image-tools/tree/master/cmd/oci-image-tool 21 | 22 | ### Project Descriptions 23 | Below are brief draft project descriptions intended to serve as an initial abstract for each project: 24 | * Runtime-Tools: Tools for testing of container runtimes implementing the OCI runtime-spec. 25 | This includes code that tests a runtime's conformance to the OCI Container Runtime spec. 26 | * Image-Tools: Tools for testing of container images implementing the OCI image-spec. 27 | This includes code that validates a file's conformance to the OCI Container Image Format spec. 28 | 29 | ### Initial Maintainers 30 | Initial maintainers of the runtime-tools project: 31 | * Maintainers of the runtime-spec project 32 | 33 | Initial maintainers of the image-tools project shall be: 34 | * Maintainers of the image-spec project 35 | 36 | ### Code of Conduct 37 | Both of the proposed projects would incorporate (by reference) the OCI [Code of Conduct][code-of-conduct]. 38 | 39 | ### Governance and Releases 40 | Both of the proposed projects would incorporate the Governance and Releases processes from the OCI project template: https://github.com/opencontainers/project-template. 41 | 42 | ### Project Communications 43 | Both of the proposed projects would continue to use existing channels in use by the OCI developer community for communication including: 44 | * GitHub for issues and pull requests 45 | * The dev@opencontainers.org email list 46 | * The weekly OCI developer community conference call 47 | * The #OpenContainers IRC channel 48 | 49 | ### Versioning / Roadmap 50 | Released version numbers of the runtime-tools and image-tools projects should roughly align with released verions of the associated specs projects. 51 | 52 | It is expected that releases of the tools projects will follow releases of the specs projects by anywhere from a few days to a few months. 53 | 54 | ## Frequenty Asked Questions (FAQ) 55 | 56 | **Q: What about the runc project?** 57 | 58 | A: This proposal would not impact runc. 59 | Runc is a reference implementation of the runtime-spec and it lives in its own repo. 60 | 61 | **Q: What about schemas?** 62 | A: It would be up to the OCI developer community to determine if schemas fit best with the specs or tools projects. 63 | 64 | **Q: Why are the repo names plural (tools) instead of singular (tool)?** 65 | 66 | A: There may be multiple tools or a single tool with multiple functionalities. 67 | 68 | **Q: Why not prefix the repo names with "oci-" aligning to the CLI commands for invoking the tools?** 69 | 70 | A: The repos will be under the http://www.github.com/OpenContainers/ organization. 71 | 72 | **Q: Why two tools repos?** 73 | 74 | A: Having a tools repo for each spec repo allows for releasing a tools repo shortly after a spec stabilizes even if the other tools repo is in a state of flux. 75 | 76 | **Q: Why is contribution count used to identify potential maintainers?** 77 | 78 | A: Contribution count is not a great metric for the value of a contributor's contributions, but this seemed like a reasonable, rough way to identify additional potential maintainers beyond the spec maintainers. 79 | 80 | **Q: Can additional code/tools be added to the proposed tools repos beyond what is listed above?** 81 | 82 | A: Yes. If there is other code or functionality that a contributor believes would be relevant for runtime-related or image-related tools, it would be great if it is contributed. 83 | 84 | [code-of-conduct]: https://github.com/opencontainers/org/blob/master/CODE_OF_CONDUCT.md 85 | -------------------------------------------------------------------------------- /proposals/umoci.md: -------------------------------------------------------------------------------- 1 | # OCI umoci Project Proposal # 2 | 3 | ## Abstract ## 4 | The need for a "works out of the box" image tool that is supported by OCI has been clear for several years. 5 | umoci was initially developed to fulfil this requirement, and after several years of development and wide-spread production usage, we feel it is time to include it within the OCI. 6 | The following proposal outlines how this would be achieved. 7 | 8 | ## Background ## 9 | To quote the description of umoci from [the project website][umoci]: 10 | 11 | > umoci is a free software tool for manipulating and interacting with container 12 | > images in the standardised Open Container Initiative’s image format. It 13 | > provides one of the most flexible image management toolsets, requiring 14 | > neither a daemon nor any particular filesystem setup. It is already used in a 15 | > variety of different projects and by several companies. 16 | 17 | umoci is primarily used as a command-line tool, and can be used to perform fundamental operations on an OCI container image. 18 | An example session looks like 19 | 20 | ```ShellSession 21 | ## Unpack an existing image (image directory "opensuse" with tag "leap") into 22 | ## an OCI runtime-spec bundle in the directory "bundle". 23 | ## 24 | % umoci unpack --image opensuse:leap bundle 25 | 26 | ## Start the container in "bundle" using the default generated configuration 27 | ## and make some changes to the container filesystem. Note that is not 28 | ## necessary to use containers in order to change the filesystem, umoci doesn't 29 | ## care how you modify the rootfs. 30 | ## 31 | ## Note that only modifications in "bundle/rootfs" will have any effect on 32 | ## "umoci repack". Of particular note is that you can only change the image 33 | ## configuration through "umoci config" and not by modifying 34 | ## "bundle/config.json". 35 | ## 36 | % runc run -b bundle ctr 37 | ctr# zypper in -y foobarbaz 38 | ctr# exit 39 | % echo foo > bundle/rootfs/README 40 | 41 | ## Based on the changes made above, build a new layer on top of the original 42 | ## image and replace "opensuse:leap" with the new image. If you wish to create 43 | ## a new image tag and leave the old one alone, pass a different value to 44 | ## --image here (though it must be in the same image directory "opensuse"). 45 | ## 46 | % umoci repack --image opensuse:new-leap bundle 47 | 48 | ## Modify the configuration of the image to specify a new author. 49 | ## 50 | % umoci config --image opensuse:leap \ 51 | > --author="Aleksa Sarai " \ 52 | > --config.workingdir="/var/www" 53 | 54 | ## Garbage-collect any unreferenced blobs in the image (directory "opensuse"). 55 | ## umoci does not do this automatically, so users should do this after 56 | ## completing all operations on an image. 57 | ## 58 | $ umoci gc --layout opensuse 59 | ``` 60 | 61 | umoci has a fairly minimal feature set, and was intended from the outset to implement all of the key features which are needed from a reference implementation of the OCI Image Specifications. 62 | The help page for the latest version of `umoci` (`0.4.5` at the time of writing) is provided below: 63 | 64 | ``` 65 | NAME: 66 | umoci - umoci modifies Open Container images 67 | 68 | USAGE: 69 | umoci [global options] command [command options] [arguments...] 70 | 71 | VERSION: 72 | 0.4.5 73 | 74 | AUTHOR: 75 | Aleksa Sarai 76 | 77 | COMMANDS: 78 | raw advanced internal image tooling 79 | help, h Shows a list of commands or help for one command 80 | 81 | image: 82 | config modifies the image configuration of an OCI image 83 | unpack unpacks a reference into an OCI runtime bundle 84 | repack repacks an OCI runtime bundle into a reference 85 | new creates a blank tagged OCI image 86 | tag creates a new tag in an OCI image 87 | remove, rm removes a tag from an OCI image 88 | stat displays status information of an image manifest 89 | insert insert content into an OCI image 90 | 91 | layout: 92 | gc garbage-collects an OCI image's blobs 93 | init create a new OCI layout 94 | list, ls lists the set of tags in an OCI layout 95 | 96 | GLOBAL OPTIONS: 97 | --verbose alias for --log=info 98 | --log value set the log level (debug, info, [warn], error, fatal) (default: "warn") 99 | --help, -h show help 100 | --version, -v print the version 101 | ``` 102 | 103 | For a more detailed explanation of umoci, see the [project website's guide][umoci-guide]. 104 | 105 | [umoci]: https://umo.ci/ 106 | [umoci-guide]: https://umo.ci/quick-start/ 107 | 108 | ## Proposal ## 109 | Change the ownership of the existing umoci project from openSUSE: 110 | 111 | https://github.com/openSUSE/umoci 112 | 113 | And move it inside the `opencontainers` organisation: 114 | 115 | https://github.com/opencontainers/umoci 116 | 117 | The import paths will correspondingly be "github.com/opencontainers/umoci" (umoci does have some Go API users, but since the project will be renamed -- and GitHub will add a redirect -- there will be no significant downstream impact of the change). 118 | In the future we may opt to use vanity imports (such as "umo.ci/cmd/umoci"). 119 | 120 | The project's domain "umo.ci" will also be transferred to the Linux Foundation so that it can be managed by someone other than the maintainers (though maintainers must maintain the necessary administrative access to maintain the website). 121 | 122 | ### Initial Maintainers ### 123 | Initial maintainers of the umoci project would be: 124 | 125 | * Aleksa Sarai (@cyphar) 126 | * Tycho Andersen (@tych0) 127 | * Vincent Batts (@vbatts) 128 | 129 | ### Code of Conduct ### 130 | This project would incorporate (by reference) the OCI [Code of Conduct][code-of-conduct]. 131 | 132 | [code-of-conduct]: https://github.com/opencontainers/org/blob/master/CODE_OF_CONDUCT.md 133 | 134 | ### Governance and Releases ### 135 | This project would initially incorporate the Governance and Release processes from [the OCI project template][oci-template], with two modifications: 136 | 137 | * Self-LGTMs are permitted. 138 | * Minor (`1.y`), point (`1.2.z`), and release candidate (`1.2.3~rcN`) releases only require 2 LGTMs. 139 | 140 | The motivation for these changes is that the set of maintainers is rather small, so many of the [OCI project template rules][oci-template] will require unanimous votes which is an unfair burden on merging code changes. 141 | 142 | [oci-template]: https://github.com/opencontainers/project-template 143 | 144 | ### Project Communications ### 145 | The proposed project would continue to use existing channels in use by the OCI developer community for communication including: 146 | 147 | * GitHub for issues and pull requests. 148 | * The [`dev@opencontainers.org`][oci-ml] email list. 149 | * The weekly OCI developer community conference call. 150 | * The `#opencontainers` IRC channel on Freenode. 151 | * The [OCI Slack workspace][oci-slack]. 152 | * The [OCI Matrix Room][oci-matrix]. 153 | 154 | [oci-ml]: mailto:dev@opencontainers.org 155 | [oci-slack]: https://opencontainers.slack.com/ 156 | [oci-matrix]: https://matrix.to/#/#opencontainers:matrix.org 157 | 158 | ### Roadmap ### 159 | umoci still has a fairly ambitious scope of work (much of it outside the scope of the OCI Image Specification), and this work would continue under OCI. 160 | Examples of such work include: 161 | 162 | * Security hardening by porting umoci to [libpathrs][libpathrs]. 163 | * Re-thinking the method by which images are referenced in the command-line. 164 | * Expanded support for configuring descriptor annotations in arbitrarily-structured OCI metadata trees. 165 | * Committing to a stable Go API and releasing a version 1.0 of the project. 166 | * Experimental design work for [a new OCI Image Specification layer format (code-named "OCIv2")][ociv2]. 167 | * Hookable execution to allow for custom "storage drivers" to be defined by users (to avoid the maintenance overhead of supporting such drivers within umoci). 168 | This would effectively allow for higher-level tools to implement both image-build caching (by skipping the extraction of layers which are already available) and overlay filesystem support (by injecting `mount(8)` operations between layer extractions). 169 | 170 | [libpathrs]: https://github.com/openSUSE/libpathrs 171 | [ociv2]: https://hackmd.io/@cyphar/ociv2-brainstorm 172 | 173 | ## Frequently Asked Questions (FAQ) 174 | > *Does this proposal change the OCI Charter?* 175 | 176 | This proposal does not intend to amend the [OCI Charter][oci-charter]. 177 | 178 | [oci-charter]: https://github.com/opencontainers/tob/blob/master/CHARTER.md 179 | 180 | > *Where does umoci fit into the OCI suite of projects?* 181 | 182 | umoci is intended to be a *reference implementation of the OCI Image Specification* as a "works out of the box" image manipulation tool, which provides a minimally abstracted set of operations to avoid users having to implement the OCI Image Specification themselves. 183 | It is intended to fill a similar role to runc within the OCI Runtime Specification -- that is, being a "boring container infrastructure tool" which larger systems can leverage. 184 | 185 | Note that this proposal should not be interpreted as being intended to make the OCI prescribe the use of umoci for existing or new projects to use instead of their own OCI Image Specification implementation. 186 | This proposal for umoci's inclusion is intended to make it easier for users who do not wish to implement the OCI Image Specification themselves to have a basic building block they can use for whatever system they are developing. 187 | While umoci is usable on its own, it is expected that the vast majority of umoci's users will be consuming it as part of a larger build system which uses umoci internally to abstract away the specifics of the OCI Image Specification. 188 | 189 | > *What about image-tools?* 190 | 191 | The original intention of umoci was to be a wrapper around the OCI image-tools and slowly upstream the work. 192 | Unfortunately, in the past 4 years, the image-tools project has not developed at a consistent pace -- and umoci works today and is fairly widely used. 193 | It is far more important that the OCI provide a solid "works out of the box" image manipulation tool, and umoci is (in our view) the best candidate for this role. 194 | 195 | In a future proposal, we may decide to sub-tree merge the OCI image-tools project into umoci (and archive the original project) in order to maintain the legacy of the work done by previous contributors and maintainers. 196 | Alternatively we may decide to split out the validation code from the OCI image-tools project and place it inside an OCI conformance project. 197 | However, we believe that these decisions should be considered a separate topic to the question of umoci's inclusion in the OCI. 198 | 199 | > *Why bless umoci over other alternative tools?* 200 | 201 | umoci is the only OCI image manipulation tool which was designed to be usable as a component to build other image-building tools. 202 | This has proven to be a practical benefit, with several tools ([KIWI][kiwi], [stacker][stacker], and several others) being built on top of umoci. 203 | In addition, umoci has been used by the [LXC project][lxc-oci] to support OCI-based images from *outside* the OCI ecosystem, something that was only reasonable because of umoci's unopinionated stance on images. 204 | umoci has seen production usage for several years as part of the [Open Build Project][obs]'s build system, building container images using [kiwi][kiwi]. 205 | 206 | [kiwi]: https://osinside.github.io/kiwi/building/build_docker_container.html 207 | [stacker]: https://github.com/anuvu/stacker 208 | [lxc-oci]: https://github.com/lxc/lxc/blob/lxc-4.0.2/templates/lxc-oci.in 209 | [obs]: https://openbuildservice.org/ 210 | 211 | > *How do we avoid the runc issue with implementation-specific quirks becoming a de-facto standard?* 212 | 213 | When developing new features in umoci (which are within the scope of the OCI Image Specification), a strong effort will be made to include those features in the upstream specification. 214 | In addition, any new features that are in the scope of the OCI Image Specification will be marked as strictly experimental and unsupported, to ensure that users do not depend on their stability until the relevant feature (or an equivalent feature) is included in the OCI Image Specification. 215 | The scope of the OCI Image Specification is thankfully smaller than the OCI Runtime Specification, so this should not be as much of a concern as with runc. 216 | However, the maintainers will be mindful of the issue and will make use of their experiences working on runc and the OCI Runtime Specification to avoid this situation occurring with umoci and the OCI Image Specification. 217 | 218 | For the avoidance of doubt, any such features will require explcit user action to enable such that the user is made clearly aware that they are using an unsupported feature. 219 | Examples include requiring the user to: 220 | 221 | * Specify a scary-sounding build tag during compilation to enable the feature (`go build -tag 'EXCEPTIONALLY-UNSTABLE--featureXYZ'`); or 222 | * Pass a scary-sounding flag (such as `--seriously-do-not-depend-on-this-feature`); or 223 | * Use a scary function name (such as `VeryUnstableFeature_FuncXyz`). 224 | 225 | And all of the above requirements will be documented with an explicit warning that explains to the user why this policy is important. 226 | 227 | > *Who are the other target users of umoci?* 228 | 229 | End-users who want a simple tool to deal with OCI images, and developers of image-building tools that want a tried and tested implementation of the OCI image format. 230 | -------------------------------------------------------------------------------- /proposals/wg-auth.md: -------------------------------------------------------------------------------- 1 | # OCI Working Group Proposal: Authentication and Authorization 2 | 3 | Proposal created from [OCI WG template](https://github.com/opencontainers/tob/blob/master/WG-TEMPLATE.md). 4 | 5 | ## Auth OCI Working Group - Governance Charter 6 | 7 | This document describes the basic governance principles for the Auth Working Group (the “WG”). 8 | 9 | The WG operates as an OCI Working Group under the [Open Container Initiative (OCI) Charter](https://github.com/opencontainers/tob/blob/master/CHARTER.md), which describes the responsibilities of the OCI Technical Oversight Board (the "TOB”). 10 | The WG is established by the TOB as an OCI Working Group pursuant to the OCI Charter. 11 | Accordingly, the WG will operate in accordance with the OCI Charter and OCI's other policies and procedures, supplemented by the details below. 12 | 13 | ## Purpose 14 | 15 | Authentication and authorization are a key requirement for registries to control access. 16 | Implementations of this in registries and clients have roughly followed standards set by Docker and have mostly focused on compatibility with specific implementations of registries or clients. 17 | This working group will define a standard to be supported by OCI compatible registries and clients when support for authentication and authorization is required. 18 | 19 | ## Scope 20 | 21 | * Define registry responses to unauthenticated requests. 22 | * Define supported authentication methods (e.g. basic and bearer authentication). 23 | * Specify how clients negotiate access a repository and different types of access to that repository (e.g. pull and push). 24 | * Specify how clients negotiate access to multiple repositories for actions like a cross-repository blob mount. 25 | * Specify how clients and registries should renegotiate access for a request with expired or insufficient authorization. 26 | * Specify expected lifetime of registry credentials. 27 | * Avoid specifications that would prevent future extensibility (e.g. fine grain access control). 28 | * The authentication methods defined as supported should include OSS solution(s) that avoid picking/choosing a limited set of specific authentication providers as the default / winner. 29 | * Specify how clients and registries should be extensible/pluggable with respect to supported authentication methods. 30 | 31 | ## Out of Scope 32 | 33 | * Registries and clients that do not require authentication and authorization support should be unaffected by these changes. 34 | * How clients store and access credentials, including credential helpers, will remain undefined. 35 | * Significant new functionality, not implemented by existing registries and clients, should not be created. 36 | 37 | ## Intended work product 38 | 39 | * The result of this WG should be a PR to the distribution-spec. 40 | * Effort should be made to avoid breaking changes to existing registries and clients. 41 | * Effort should be made to utilize existing IETF standards when appropriate. 42 | 43 | ## Proposed Owners 44 | 45 | The following have agreed to participate in the working group, review progress, report progress back to the OCI community, and present the results to the TOB once the working group has completed its objectives. 46 | 47 | * Brandon Mitchell (@sudo-bmitch) 48 | * Jason Hall (@imjasonh) 49 | * Jeff Carter (@jcarter3) 50 | * Mike Brown (@mikebrow) 51 | * Ramkumar Chinchani (@rchincha) 52 | * Toddy Mladenov (@toddysm) 53 | 54 | ## Stakeholders 55 | 56 | OCI Projects, non-OCI projects, or organizations sponsoring the working group and participating in the implementation and use case validation of the work done by the group. 57 | 58 | * [ACR CLI][acr-cli] 59 | * [Docker Hub][docker-hub] 60 | * [notation][notation] 61 | * [OCI distribution-spec][distribution-spec] 62 | * [oras][oras] 63 | * [regclient][regclient] 64 | * [zot][zot] 65 | 66 | ## Related Issues/PRs 67 | 68 | * 69 | * 70 | 71 | ## Governance 72 | 73 | * **Working Group**: 74 | * The TOB is establishing the WG as an OCI Working Group, pursuant to [section 6(p)](https://github.com/opencontainers/tob/blob/master/CHARTER.md#6-technical-oversight-board-tob) of the OCI Charter. 75 | * **Owners**: 76 | * The WG proposal to the TOB will specify one or more initial "owners" of the WG. 77 | * The current owners will be listed in the [OCI Working Group documentation](https://github.com/opencontainers/tob/blob/master/WG-INFO.md). 78 | * The owners shall be responsible for: 79 | * scheduling regular meetings of the WG community; 80 | * facilitating open discussion among WG community participants; 81 | * coordinating and managing the development of the WG work product and outputs; 82 | * recording decisions that are reached by the WG community; and 83 | * keeping the TOB regularly informed about the status of the WG’s efforts, including when the WG has readied the work product and outputs for TOB approval. 84 | * **Maintainers**: 85 | * If the WG owners request the TOB to approve a draft specification as a released OCI Specification, the request shall include a list of proposed "maintainers" of the OCI Specification. 86 | * The current maintainers will be listed in the [OCI Working Group documentation](https://github.com/opencontainers/tob/blob/master/WG-INFO.md). 87 | * The maintainers shall be responsible for continuing the work of overseeing updates, improvements and changes to a released OCI Specification on an ongoing basis. 88 | * **Meetings**: 89 | * Meetings of the WG shall be open to the public. 90 | * Participants in the meetings shall comply with the [OCI Code of Conduct](https://github.com/opencontainers/.github/blob/master/CODE_OF_CONDUCT.md) and all other policies of OCI and The Linux Foundation. 91 | * **TOB Approval**: 92 | * The WG shall operate pursuant to the procedures set forth in [section 6(p)](https://github.com/opencontainers/tob/blob/master/CHARTER.md#6-technical-oversight-board-tob) of the OCI Charter, with regards to obtaining TOB approval for initial release of the work product and outputs as an OCI Specification or other OCI Project, and for subsequent maintenance activities thereafter. 93 | * **Amendments**: 94 | * The owners of the WG may from time to time propose to the TOB (1) amendments to this WG Governance Document, and/or (2) changes to the composition of the owners or maintainers of the WG. 95 | * As set forth in the OCI Charter, the TOB may, in its discretion by a two-thirds vote, approve or reject the requested amendments or changes. 96 | * As set forth in the OCI Charter, the TOB may also disband the WG by a two-thirds vote. 97 | 98 | [acr-cli]: https://github.com/Azure/acr-cli 99 | [distribution-spec]: https://github.com/opencontainers/distribution-spec/ 100 | [docker-hub]: https://hub.docker.com/ 101 | [notation]: https://github.com/notaryproject/notation/ 102 | [oras]: https://github.com/oras-project/oras 103 | [regclient]: https://github.com/regclient/regclient 104 | [zot]: https://zotregistry.io/ 105 | -------------------------------------------------------------------------------- /proposals/wg-freebsd-runtime.md: -------------------------------------------------------------------------------- 1 | # Working Group Proposal: FreeBSD Runtime 2 | 3 | Proposal created from [OCI WG template](https://github.com/opencontainers/tob/blob/master/WG-TEMPLATE.md). 4 | 5 | # FreeBSD Runtime OCI Working Group - Governance Charter 6 | 7 | This document describes the basic governance principles for the FreeBSD Runtime Spec Working Group Working Group (the “WG”). 8 | 9 | The WG operates as an OCI Working Group under the [Open Container Initiative (OCI) Charter](https://github.com/opencontainers/tob/blob/master/CHARTER.md), which describes the responsibilities of the OCI Technical Oversight Board (the "TOB”). The WG is established by the TOB as an OCI Working Group pursuant to the OCI Charter. Accordingly, the WG will operate in accordance with the OCI Charter and OCI's other policies and procedures, supplemented by the details below. 10 | 11 | ## Purpose 12 | 13 | With two working OCI runtimes for FreeBSD 14 | ([runj](https://github.com/samuelkarp/runj), 15 | [ocijail](https://github.com/dfr/ocijail)) and several container engines 16 | including containerd, podman and cri-o, there is a need to define a 17 | FreeBSD-specific section of the runtime-spec to allow support for platform 18 | features such as resource limits and fine-grained jail permissions. This will 19 | help to ensure runtime compatibility and build a consensus for the best way to 20 | support FreeBSD container runtimes. 21 | 22 | ## Scope 23 | 24 | * Define a FreeBSD extension to the runtime-spec similar in scope to the 25 | existing extensions for linux, solaris, windows etc. 26 | * Identify platform features which should be part of the FreeBSD spec. 27 | * Build consensus on how to represent these features clearly. 28 | 29 | ## Out of Scope 30 | 31 | * Changes to non-FreeBSD platform-specific sections. 32 | * Addition of any new FreeBSD-specific features to the generic sections of `config.json` unless those sections are already structured to include platform-specific information (such as Mounts). 33 | 34 | ## Intended work product 35 | 36 | * Add config-freebsd.md to the runtime-spec repository along with suitable tests 37 | and support in specs-go. 38 | 39 | ## Proposed Owners 40 | 41 | * Doug Rabson (@dfr) 42 | * Samuel Karp (@samuelkarp) 43 | * Ed Maste (@emaste) 44 | * Dave Cottlehuber (@dch) 45 | 46 | ## Related issues/PRs 47 | 48 | * https://github.com/samuelkarp/runj/issues/4 49 | * https://github.com/samuelkarp/runj/issues/8 50 | * https://github.com/samuelkarp/runj/issues/19 51 | * https://github.com/samuelkarp/runj/issues/20 52 | * https://github.com/samuelkarp/runj/pull/11 53 | 54 | ## Governance 55 | 56 | * **Working Group**: 57 | * The TOB is establishing the WG as an OCI Working Group, pursuant to [section 6(p)](https://github.com/opencontainers/tob/blob/master/CHARTER.md#6-technical-oversight-board-tob) of the OCI Charter. 58 | * **Owners**: 59 | * The WG proposal to the TOB will specify one or more initial "owners" of the WG. 60 | * The current owners will be listed in the [OCI Working Group documentation](https://github.com/opencontainers/tob/blob/master/WG-INFO.md). 61 | * The owners shall be responsible for: 62 | * scheduling regular meetings of the WG community; 63 | * facilitating open discussion among WG community participants; 64 | * coordinating and managing the development of the WG work product and outputs; 65 | * recording decisions that are reached by the WG community; and 66 | * keeping the TOB regularly informed about the status of the WG’s efforts, including when the WG has readied the work product and outputs for TOB approval. 67 | * **Maintainers**: 68 | * If the WG owners request the TOB to approve a draft specification as a released OCI Specification, the request shall include a list of proposed "maintainers" of the OCI Specification. 69 | * The current maintainers will be listed in the [OCI Working Group documentation](https://github.com/opencontainers/tob/blob/master/WG-INFO.md). 70 | * The maintainers shall be responsible for continuing the work of overseeing updates, improvements and changes to a released OCI Specification on an ongoing basis. 71 | * **Meetings**: 72 | * Meetings of the WG shall be open to the public. 73 | * Participants in the meetings shall comply with the [OCI Code of Conduct](https://github.com/opencontainers/.github/blob/master/CODE_OF_CONDUCT.md) and all other policies of OCI and The Linux Foundation. 74 | * **TOB Approval**: 75 | * The WG shall operate pursuant to the procedures set forth in [section 6(p)](https://github.com/opencontainers/tob/blob/master/CHARTER.md#6-technical-oversight-board-tob) of the OCI Charter, with regards to obtaining TOB approval for initial release of the work product and outputs as an OCI Specification or other OCI Project, and for subsequent maintenance activities thereafter. 76 | * **Amendments**: 77 | * The owners of the WG may from time to time propose to the TOB (1) amendments to this WG Governance Document, and/or (2) changes to the composition of the owners or maintainers of the WG. 78 | * As set forth in the OCI Charter, the TOB may, in its discretion by a two-thirds vote, approve or reject the requested amendments or changes. 79 | * As set forth in the OCI Charter, the TOB may also disband the WG by a two-thirds vote. 80 | -------------------------------------------------------------------------------- /proposals/wg-image-compatibility.md: -------------------------------------------------------------------------------- 1 | # OCI Working Group Proposal: Image Compatibility 2 | 3 | Proposal created from [OCI WG template](https://github.com/opencontainers/tob/blob/master/WG-TEMPLATE.md). 4 | 5 | ## Image Compatibility OCI Working Group - Governance Charter 6 | 7 | This document describes the basic governance principles for the Image Compatibility Working Group (the “WG”). 8 | 9 | The WG operates as an OCI Working Group under the [Open Container Initiative (OCI) Charter](https://github.com/opencontainers/tob/blob/master/CHARTER.md), which describes the responsibilities of the OCI Technical Oversight Board (the "TOB”). 10 | The WG is established by the TOB as an OCI Working Group pursuant to the OCI Charter. 11 | Accordingly, the WG will operate in accordance with the OCI Charter and OCI's other policies and procedures, supplemented by the details below. 12 | 13 | ## Purpose 14 | 15 | In mission-critical industries, applications often require special features provided by host operating systems. 16 | These are usually described in the release notes or installation guides. 17 | We believe we have identified the missing puzzle in the OCI standard, the image compatibility, which is a key feature that describes the requirements of special containerized applications that have hard requirements for specific kernel versions, configurations, modules, or out-of-tree drivers. 18 | 19 | For example, a container application free5GC UPF requiring the gtp5g kernel module will only be compatible with kernel 5.0.0-23-generic or 5.4.x due to the module's hard kernel version requirements - https://free5gc.org/guide/3-install-free5gc/. 20 | If SR-IOV or GPU is required by the container, other requirements have to be specified against the host OS. 21 | Kata Containers use cases are the best example: https://github.com/kata-containers/kata-containers/tree/main/docs/use-cases. 22 | 23 | The described incompatibility issue applies to all use cases where specific host configuration is required, from bare-metal (e.g. high-performance computing) to distributed systems, from non-kubernetes to kubernetes orchestrated applications. 24 | 25 | In multi-cloud or hybrid cloud scenarios, one containerized cloud-native application will need to run on different Kubernetes distributions that use different host operating systems on worker nodes. 26 | 27 | For bare-metal and cloud operating systems can use different kernel versions with different configurations. 28 | Different operating system distributions may integrate different devices and their corresponding drivers, even for the same device different versions of drivers may be used. 29 | Therefore, different operating system distributions are not identical. 30 | Even within the same OS distro, different releases are also not identical. 31 | 32 | An image compatibility would help container image authors describe compatibility requirements in a standard way. 33 | The specification will be uploaded with the image to the image registry. 34 | This makes hard container compatibility requirements discoverable, programmable, and will support different consumers and cover use cases where the application requires a specific compatible environment. 35 | 36 | For further reference please follow: 37 | * [OCI Image Compatibility - the spec reasoning](https://docs.google.com/presentation/d/1F9GnCm2sULuyTJ5BEFZlL8Qjab81DK7g9Oy6qBfe5Qs/edit?usp=sharing) 38 | * [Revisit container and host OS compatibility](https://docs.google.com/document/d/1lzwh8DGMu5vXXHwJmnewYIMffkcOEvH8owX4UYjRcw0/edit#heading=h.fcxt9vheg92c) 39 | 40 | ## Scope 41 | 42 | * Define image compatibility that describes special host OS requirements of containerized application. 43 | * The compatibility should describe container requirements for Linux, illumos and Windows. 44 | * The final list of supported fields (like kernel modules, configuration, out-of-tree drivers etc.) is to be determined by the working group for each supported OS. 45 | * An appropriate solution for expressing compatibility should be determined by the working group. 46 | 47 | ## Out of Scope 48 | 49 | * Change images build or container execution flow. 50 | * Introduce a new hard requirement to build images or run containers. 51 | * Cover applications ABI compatibility. 52 | 53 | ## Intended work product 54 | 55 | * The result of this WG should be extended or a new OCI specification that allows containers to describe host OS requirements. 56 | * The specification will provide a much better experience for users to find out about container requirements against host OS, if those exist. 57 | * The specification will provide programmatic data for various OS operators that could influence configuration of nodes. 58 | 59 | ## Proposed Owners 60 | 61 | The following have agreed to participate in the working group, review progress, report progress back to the OCI community, and present the results to the TOB once the working group has completed its objectives. 62 | 63 | * Marcin Franczyk (@mfranczy) 64 | * Joe Huang (@chaoyihuang) 65 | * Zvonko Kaiser (@zvonkok) 66 | * Till Wegmüller (@toasterson) 67 | * Toru Komatsu (@utam0k) 68 | * B. Dewayne Branch (@GeoEducator) 69 | * Samuel McGraw (@smcgrawDotNet) 70 | * Vanessa Sochat (@vsoch) 71 | * Brandon Mitchell (@sudo-bmitch) 72 | * Aleksa Sarai (@cyphar) 73 | * Jason Du (@xdu31) 74 | * Dirk Mueller (@dirkmueller) 75 | * Christian Kniep (@ChristianKniep) 76 | * Bjorn Neergaard (@neersighted) 77 | 78 | ## Stakeholders 79 | 80 | OCI Projects, non-OCI projects, or organizations sponsoring the working group and participating in the implementation and use case validation of the work done by the group. 81 | 82 | * Huawei 83 | * NVIDIA 84 | * illumos 85 | * OKD 86 | * Intel 87 | * SUSE 88 | * HPC Container Advisory Council 89 | * Docker, Inc. 90 | 91 | ## Related Issues/PRs 92 | 93 | ## Governance 94 | 95 | * **Working Group**: 96 | * The TOB is establishing the WG as an OCI Working Group, pursuant to [section 6(p)](https://github.com/opencontainers/tob/blob/master/CHARTER.md#6-technical-oversight-board-tob) of the OCI Charter. 97 | * **Owners**: 98 | * The WG proposal to the TOB will specify one or more initial "owners" of the WG. 99 | * The current owners will be listed in the [OCI Working Group documentation](https://github.com/opencontainers/tob/blob/master/WG-INFO.md). 100 | * The owners shall be responsible for: 101 | * scheduling regular meetings of the WG community; 102 | * facilitating open discussion among WG community participants; 103 | * coordinating and managing the development of the WG work product and outputs; 104 | * recording decisions that are reached by the WG community; and 105 | * keeping the TOB regularly informed about the status of the WG’s efforts, including when the WG has readied the work product and outputs for TOB approval. 106 | * **Maintainers**: 107 | * If the WG owners request the TOB to approve a draft specification as a released OCI Specification, the request shall include a list of proposed "maintainers" of the OCI Specification. 108 | * The current maintainers will be listed in the [OCI Working Group documentation](https://github.com/opencontainers/tob/blob/master/WG-INFO.md). 109 | * The maintainers shall be responsible for continuing the work of overseeing updates, improvements and changes to a released OCI Specification on an ongoing basis. 110 | * **Meetings**: 111 | * Meetings of the WG shall be open to the public. 112 | * Participants in the meetings shall comply with the [OCI Code of Conduct](https://github.com/opencontainers/.github/blob/master/CODE_OF_CONDUCT.md) and all other policies of OCI and The Linux Foundation. 113 | * **TOB Approval**: 114 | * The WG shall operate pursuant to the procedures set forth in [section 6(p)](https://github.com/opencontainers/tob/blob/master/CHARTER.md#6-technical-oversight-board-tob) of the OCI Charter, with regards to obtaining TOB approval for initial release of the work product and outputs as an OCI Specification or other OCI Project, and for subsequent maintenance activities thereafter. 115 | * **Amendments**: 116 | * The owners of the WG may from time to time propose to the TOB (1) amendments to this WG Governance Document, and/or (2) changes to the composition of the owners or maintainers of the WG. 117 | * As set forth in the OCI Charter, the TOB may, in its discretion by a two-thirds vote, approve or reject the requested amendments or changes. 118 | * As set forth in the OCI Charter, the TOB may also disband the WG by a two-thirds vote. 119 | -------------------------------------------------------------------------------- /proposals/wg-reference-types.md: -------------------------------------------------------------------------------- 1 | # Working Group Proposal: Reference Types 2 | 3 | Proposal created from [OCI WG template](https://github.com/opencontainers/tob/blob/master/WG-TEMPLATE.md). 4 | 5 | Proposal copied from [Proposal: Working Group for Reference Types #96](https://github.com/opencontainers/tob/issues/96). 6 | 7 | ## Reference Types OCI Working Group - Governance Charter 8 | 9 | This document describes the basic governance principles for the Reference Types Working Group (the “WG”). 10 | 11 | The WG operates as an OCI Working Group under the [Open Container Initiative (OCI) Charter](https://github.com/opencontainers/tob/blob/master/CHARTER.md), which describes the responsibilities of the OCI Technical Oversight Board (the "TOB”). The WG is established by the TOB as an OCI Working Group pursuant to the OCI Charter. Accordingly, the WG will operate in accordance with the OCI Charter and OCI's other policies and procedures, supplemented by the details below. 12 | 13 | ## Purpose 14 | 15 | As cloud native development continues to grow, there is increased interest in evolving registries to natively store, discover, and pull a graph of content associated with specific container images in a registry. 16 | Use cases for said associated artifacts include but are not limited to Software Bill of Materials (SBoM), security scan results, and signing. 17 | Having a native way to store and discover artifacts associated with other artifacts enables end-users to answer the question of: “What SBOMs or signatures are associated with this container image?” 18 | 19 | ## Scope 20 | 21 | * Define and deliver the capability to push, discover, and pull a graph of artifacts within OCI distribution compliant registries. These set of capabilities have been commonly known as "reference types" or "references". 22 | * Define supported use cases 23 | * Document impact to existing implementations 24 | * Define the method for creating, distributing, discovering, and traversing a graph of referenced objects 25 | * Document user expectations for promoting an artifact and its references between registries 26 | * Document onboarding process for registries and user-facing tools to adopt reference types 27 | * Define expectations for artifact reference lifecycle management 28 | * Deliver a reference implementation of the reference types proposal 29 | 30 | ## Out of Scope 31 | 32 | * Identified out of scope items will be listed here as WG progresses. 33 | 34 | ## Intended work product 35 | 36 | * Referrers API specification that provides the ability to discover references to existing container images. These include listing signatures, SBoMs, security scan results that refer to the digest of a manifest. The referrers API specification will sit within or along side the Distribution specification. 37 | * Identify, and document the pros and cons for versioning the existing manifests, compared with creating a new manifest to support reference types. 38 | * Proposal to extend existing manifests or create a new manifest to support reference types. 39 | 40 | ## Proposed Owners 41 | 42 | * Lachlan Evenson (@lachie83) 43 | * Justin Cormack (@justincormack) 44 | * Michael Brown (@michaelb990) 45 | * Derek McGowan (@dmcgowan) 46 | * Jon Johnson (@jonjohnsonjr) 47 | 48 | ## Stakeholders 49 | 50 | * Microsoft 51 | * AWS 52 | * Docker 53 | 54 | ## Related issues/PRs 55 | 56 | * https://github.com/opencontainers/tob/issues/96 57 | * https://github.com/opencontainers/artifacts/pull/27 58 | * https://github.com/opencontainers/artifacts/pull/29 59 | * https://github.com/opencontainers/artifacts/pull/37 60 | * https://github.com/opencontainers/image-spec/issues/827 61 | * https://github.com/opencontainers/image-spec/pull/828 62 | * https://github.com/oras-project/artifacts-spec/ 63 | 64 | ## Governance 65 | 66 | * **Working Group**: 67 | * The TOB is establishing the WG as an OCI Working Group, pursuant to [section 6(p)](https://github.com/opencontainers/tob/blob/master/CHARTER.md#6-technical-oversight-board-tob) of the OCI Charter. 68 | * **Owners**: 69 | * The WG proposal to the TOB will specify one or more initial "owners" of the WG. 70 | * The current owners will be listed in the [OCI Working Group documentation](https://github.com/opencontainers/tob/blob/master/WG-INFO.md). 71 | * The owners shall be responsible for: 72 | * scheduling regular meetings of the WG community; 73 | * facilitating open discussion among WG community participants; 74 | * coordinating and managing the development of the WG work product and outputs; 75 | * recording decisions that are reached by the WG community; and 76 | * keeping the TOB regularly informed about the status of the WG’s efforts, including when the WG has readied the work product and outputs for TOB approval. 77 | * **Maintainers**: 78 | * If the WG owners request the TOB to approve a draft specification as a released OCI Specification, the request shall include a list of proposed "maintainers" of the OCI Specification. 79 | * The current maintainers will be listed in the [OCI Working Group documentation](https://github.com/opencontainers/tob/blob/master/WG-INFO.md). 80 | * The maintainers shall be responsible for continuing the work of overseeing updates, improvements and changes to a released OCI Specification on an ongoing basis. 81 | * **Meetings**: 82 | * Meetings of the WG shall be open to the public. 83 | * Participants in the meetings shall comply with the [OCI Code of Conduct](https://github.com/opencontainers/.github/blob/master/CODE_OF_CONDUCT.md) and all other policies of OCI and The Linux Foundation. 84 | * **TOB Approval**: 85 | * The WG shall operate pursuant to the procedures set forth in [section 6(p)](https://github.com/opencontainers/tob/blob/master/CHARTER.md#6-technical-oversight-board-tob) of the OCI Charter, with regards to obtaining TOB approval for initial release of the work product and outputs as an OCI Specification or other OCI Project, and for subsequent maintenance activities thereafter. 86 | * **Amendments**: 87 | * The owners of the WG may from time to time propose to the TOB (1) amendments to this WG Governance Document, and/or (2) changes to the composition of the owners or maintainers of the WG. 88 | * As set forth in the OCI Charter, the TOB may, in its discretion by a two-thirds vote, approve or reject the requested amendments or changes. 89 | * As set forth in the OCI Charter, the TOB may also disband the WG by a two-thirds vote. --------------------------------------------------------------------------------