# CNAB Community Meeting **Meeting time:** Every other Wednesday 9:00 AM - 10:00 AM US Pacific Time **Zoom Link:** https://zoom.us/j/653255416 **GitHub Repo:** https://github.com/deislabs/cnab-spec **Group slack channel:** #cnab @ cloud-native.slack.com (Get an invite from: https://slack.cncf.io) **Mailing list:** https://groups.google.com/a/opencontainers.org/forum/#!forum/dev **Document Link:** https://aka.ms/cnab/meeting **YouTube:** https://www.youtube.com/playlist?list=PLL6BzOBDywQeaaKFZkdt10JTZr5BxjQvQ ## Meeting Minutes and Agenda ## July 8th - General Meeting | | | | -------- | -------- | | Recording | | | Attending | Thomas Hane, Carolyn Van Slyck, Radu Matei, Chris Crone, Mohamed Chorfa, Trishank Kuppusamy, Vauhn Dice, Ralph Squillace | | Note Taker | Vaughn Dice | ### Agenda * Welcome new CNABBERS! πŸ¦€ * (carolynvs) Rename master branch to main? * Carolyn: Porter did this last week; very straightforward. Will require CI fixes/updates. Also the GH branch protection rule. After the next successful PR, deleted master. Note: be wary of source links that reference master in the URL. * Radu: Friendly reminder to use permalinks * Radu: What about the GH pattern of redirecting URLs? * Chris: docker -> moby rename benefitted from this GH forwarding * Radu: What about 'go get'? * Carolyn: I'll re-check; don't usually rec 'go get' * Radu: Is anyone opposed to renaming the branches in the cnabio org? * Radu: Will open an issue in the community repo to gain consensus. * (carolynvs) Can we drop the -beta1 prerelease metadata? * Closer to semver to use it only as we stabilize before an important release, e.g. v1.0.0-alpha, v1.0.0-beta.1, v1.0.0-rc1, v1.0.0-rc2, leading to v1.0.0 * v0 means unstable, we don't also need the beta on everything * When we dropped it on Porter's releases, we got all positive feedback from users. Some said that the -beta was hurting their ability to use it (scrutiny over something labeled beta vs pre 1.0 software was increased). * Carolyn: -betaX suffix actually preventing adoption in some cases * Ralph: Proposal is to only use the -beta/-alpha/etc. suffix during stabilization period for major releases? * Carolyn: Yes * Will anything break if we do this? * Radu: Not on signy * cnab-to-oci did use -beta.1 on releases but shouldn't break anything if process is changed * Demo parameter sets * Oops, no screen share this session; delayed until next time * More peeps w/ Zoom mtg host rights?! * Ralph: will pursue * Please review initial draft for registry spec - [`cnab-spec#362`](https://github.com/cnabio/cnab-spec/pull/362) * Radu: I've addressed feedback and/or created follow-up issues; needs 1 more LGTM. * Call out the July 1st CNAB Security Meeting * Ralph: Huge undertaking by Trishank and Radu (and others) :clap: :tada: * Radu: Santiago also a big help! * Any updates to signy per the spec? * Radu: Getting closer, have some items to work on. Signy is tested and working properly. Next area is verification in-container and on a host. * Rust CNAB lib could use some contributions to any/all that are interested * https://github.com/cnabio/cnab-rs * Radu: Yay! We have two opts for canonical JSON in Rust! * Trishank: Do they both output the same thing? * Radu: Yes! ## July 1st - Security and Registry Meeting | | | | -------- | -------- | | Recording | https://youtu.be/fWrwDHQbAN0 | | Attending | Radu Matei, Trishank Kuppusamy, Jinoo Jain | | Note Taker | | ### Agenda * Welcome new CNABBERS! πŸ¦€ * Jinoo Jain (Nightingale Security) * short introduction to the CNAB specs, and how they fit in together * CNAB Spec 1.0 has been voted by all spec maintainers πŸŽ‰ * Reviewing [`signy#80`](https://github.com/cnabio/signy/pull/80) * verify unique links - not necessarily required for now * verfy layout and pubkeys from targets * walk the delegation tree - if there is a targets/releases role, get the TUF hashes. If in-toto, also get custom metadata. * get root layout from target and public keys * Prepare for Notary v2 presentation on Signy ## June 24th - General Meeting | | | | -------- | -------- | | Recording | https://youtu.be/IbsqUcTpVAU | | Attending | Chris Crone, Carolyn Van Slyck, Radu Matei, Jacob LeGrone, Trishank Kuppusamy, Ralph Squillace, Tom Haney | | Note Taker | Carolyn Van Slyck | ### Agenda * Welcome new CNABBERS! πŸ¦€ * [according to the meeting notes from April 29th](https://hackmd.io/TfLYtyRnS8Kfx4ekgLwWLg?both#April-29th---General-Meeting), @carolynvs is also a spec maintainer, but the OWNERS file has not been updated. * [PR to add Carolyn to the OWNERS file](https://github.com/cnabio/cnab-spec/pull/377) * is the [OWNERS](https://github.com/cnabio/cnab-spec/blob/master/OWNERS) file up-to-date? * **Radu** will submit a PR to remove Simon from the owners file since he is working on other things and Silvin is taking his place for now * [CNAB Security 1.0 GA vote](https://github.com/cnabio/cnab-spec/pull/376) * according to the [process document: ](https://github.com/cnabio/cnab-spec/blob/master/901-process.md#appendix-a-the-process-of-developing-the-specification) * > GA: Working Group Approval indicates that this version has been accepted by the maintainers, but not accepted by the Executive Directors. In practice, this marker MUST only be used internally for testing, and never for production. * does it need 2/3 supermajority? * Crone - to be safe we can go with 2/3 * Ralph wants everyone to sign off, or go on record with their objection. Ralph volunteers as whip. * THANK YOU TRISHANK!!! πŸŽ‰β€οΈ * Ralph - longer term let's have the EA team fix the docs to be more clear * **Carolyn** will review with her new magic codeowner abilities * Ralph will set up working example repos in github so that people can try this out, in collaboration with the Microsoft CDA team and GitHub's developer evangelism team * [CNAB Registry draft](https://github.com/cnabio/cnab-spec/pull/362) * needs review - addressed feedback, rebased * **Carolyn** will review * Just need 2 LGTMs so we can merge a draft and keep iterating. * PR review(s) requested: * https://github.com/cnabio/cnab-go/pull/219 * This lets parameters have the same set of features as credentials: mapped from env vars, files, secrets, etc. * Ralph - next 6 months is working on showing all the different ways that we can use CNAB in open source * β€œConvincing people to sign commits, or other impossible tasks. ” * [Update delegations in Signy](https://github.com/cnabio/signy/pull/80) * Brings signy in line with the GA version of the security spec * Ralph will be the first user and find all the bugs ## June 17th - Security and Registry Meeting | | | | -------- | -------- | | Recording | https://youtu.be/S-K4G9oMrmA | | Attending | Trishank Kuppusamy, Radu Matei | | Note Taker | | ### Agenda * Welcome new CNABBERS! πŸ¦€ * [Review CNAB-Sec #369](https://github.com/cnabio/cnab-spec/issues/369) * [Discuss airgapped environments #370](https://github.com/cnabio/cnab-spec/pull/370) * Radu to ask one more spec maintainer to review. * it needs one more spec approver * Radu: write about registries which support Signy * This is no longer urgent needed for the spec, since it will be part of the non-normative section of the spec. * [Move known implementations to non-normative section](https://github.com/cnabio/cnab-spec/pull/375) * ~~typo in file weight (805/806).~~ * it needs one more spec approver. * Open PR to call for final vote on CNAB-Sec 1.0 * [Delegate to targets/releases per extended MVP #80](https://github.com/cnabio/signy/pull/80) * help with the verification part * add Signy delegations work to Notary v2 meeting ## June 10th - General Meeting | | | | -------- | -------- | | Recording | https://youtu.be/yW3jUycyHsc | | Attending | Trishank Kuppusamy, Jeff Benson, Chris Crone, Vaughn Dice, Matt Butcher, Radu Matei | | Note Taker | Radu Matei | ### Agenda * Welcome new CNABBERS! πŸ¦€ * CNAB Security * review final addition (to non-normative section) [`cnab-spec#370`](https://github.com/cnabio/cnab-spec/pull/370) * this adds some more information about airgapped environments to the non-normative sections * process for calling a vote (later in the week) (branching, tagging, PR) * we think the security spec is in a state where we can call for a vote, as both the TUF and in-toto use cases have been tested, so we think it is time to call for a vote. * the process: PR with the official final wording (CNAB-Spec-1.0); [this document](https://github.com/cnabio/cnab-spec/blob/master/901-process.md#git-release-flow) describes the process - after the PR, we have a branch that we will later use for errata changes. If there are JSON specs for the spec. * a super-majority has to approve the PR, a branch is cut, then Chris Crone and Matt Butcher are the final approvers (tag the commit that becomes the final version of the spec) * Radu: how do we handle non-normative sections? (there is a part in the security spec that talks about known implementations - we expect that to change over time, without necessarily having actual change) * Chris: we should add a note of how maintainers handle non-normative sections. * Matt: I would move that section to the non-normative part of the spec. * CNAB Registry * addressed initial feedback and rebased the PR for the registry spec, please re-review [`cnab-spec#362`](https://github.com/cnabio/cnab-spec/pull/362) * Chris: should we think about how we store image in airgapped scenarios? * Radu: * Chris: OCI has a way of describing local images (the layout), so we did not reimplement this. * Jeff: when we push a bundle into an airgapped registry, we try to find the most non-intrusive way to do that. * Community bundle for Harbor v2 (with registry and Notary) * no updates here yet * Walk through giant claim PR of doom [`cnab-go#212`](https://github.com/cnabio/cnab-go/pull/212) * Duffle * Matt: it was originally the reference implementation, but as we pulled out most functionality into `cnab-go` * Chris: all the useful bits are in `cnab-go`. * Matt: the only action item is to open a PR to clarify on the top of the readme. ### Notes ## June 3rd - Security and Registry Meeting | | | | -------- | -------- | | Recording | https://youtu.be/4gpaGRdi_XU | | Attending | Trishank Kuppusamy, Chris Crone, Radu Matei | | Note Taker | | ### Agenda * review [`signy#75`](https://github.com/cnabio/signy/pull/75) * LGTM * discuss airgapped scenario addition to the spec * there is a non-normative 805 section in the specificatin that talks about disconnected scenarios - we could add a section about signing and verifying bundles here, and point to it from the security specification. * final review for security spec draft * review [`cnab-spec#362`](https://github.com/cnabio/cnab-spec/pull/362) and approval for the registry spec draft to get merged? ## May 27th - General Meeting | | | | -------- | -------- | | Recording | https://youtu.be/yuh4SuECb6Q | | Attending | Carolyn Van Slyck, Vaughn Dice, Trishank Kuppusamy, Jacob LeGrone | | Note Taker | Radu Matei | ### Agenda * Welcome new CNABBERS πŸ¦€ * claims specification status (Carolyn) * Carolyn has been implementing all the changes in `cnab-go` and Porter. It is a very big change, since it changes how runtimes use claims, as well as the persistence. PRs should come through the end of the week. * More of the logic for dealing with claims should be pulled out of individual tools and moved to `cnab-go`. * [security specification](https://github.com/cnabio/cnab-spec/blob/master/300-CNAB-security.md) - final reviews before calling a vote for 1.0 (Trishank, Radu) * Trishank: we think the specification is ready, it has been in a draft for a while. The only thing we should look into again is into the airgapped environments. * Radu: we want to call a vote two weeks from now. * Trishank: please take a look with a critical eye. * https://github.com/cnabio/cnab-spec/issues/369 * [image relocation and registries discussion](https://github.com/deislabs/porter/pull/1047) (Carolyn, Radu) * Carolyn: Porter has two commands - `publish` (moving across airgapped environemnts and publish again) and `copy` (take a bundle a copy it to a registry without an airgapped network). It turns out the two commands have different behaviours wrt the repositories where the images are pushed. * Radu: * Ralph: is there a particular scenario that is currently blocked by leaving the current commands? The problem seems to be the user experience. * Carolyn: the issue is with understanding where the images can be found after publishing / pushing a bundle. I started writing documentation for how the relocation works, and realized it is inconsistent. * Carolyn: maybe adding tags to images pushed with bundles in `cnab-to-oci` might help? * Ralph: I think this is a transparency problem. * Carolyn: you end up with multiple repositories. * Ralph: what I think the more immediate taks would be transparency. The way the UX in Porter works, it feels like the two commands should be doing the same thing, but they don't. So users now have to understand the difference in how the two commands work. Having a consistent behaviour in the end is a good goal - but given these serve two different purposes, people mostly want to understand where the images are pushed. * Carolyn: this is less about something being broken, but more about making sure people understand what is happening. * Carolyn: I will fix the bug in Porter and document the behaviour. * community maintained Harbor bundle for registry and signer (Radu) * bundle that configures: harbor, registry, notary * there is a helm chart for harbor2 * wants persistence, https and integration with reverse dns THIS IS SPARTA!!! err real world installation * need help from harbor to configure it correctly on a live cluster * Ralph: will follow-up with harbor PMs ## May 13th - General Meeting | | | | -------- | -------- | | Recording | https://youtu.be/D0fb43OUOm0 | | Attending | Trishank Karthik Kuppusamy, Carolyn van Slyck, Silvin Lubecki, Vaughn Dice, Aditya Sirish, Ralph Squillace | | Note Taker | TKK | ### Agenda * Welcome new CNABBERS πŸ¦€ * ***Please*** review: * known implementations for security spec - [`cnab-spec#288`](https://github.com/cnabio/cnab-spec/pull/288) * Trishank: it's good to go * Carolyn will take a look * initial draft for registry spec - [`cnab-spec#362`](https://github.com/cnabio/cnab-spec/pull/362) * Pushed to next week's agenda * clarify how to verify and inspect in-toto metadata - [`cnab-spec#364`](https://github.com/cnabio/cnab-spec/pull/364) * Trishank: very quick fix, should be easy * Carolyn will take a look * add parameter sources custom extension - [`cnab-spec#365`](https://github.com/cnabio/cnab-spec/pull/365) * Carolyn: still WIP * fix ULID generation - [`cnab-go#207`](https://github.com/cnabio/cnab-go/pull/207) * Carolyn: this was fun! * Carolyn: if you were generating ULIDs in high volume, they stop being sortable in increasing order, so this PR fixes that * Silvin looked at it * Basically adds a lot of mutexes to ULID generation * If anyone has a better implementation, that would be great! * This PR fixes the issue for now * Carolyn ~~challenges~~ throws down the gauntlet for fixing this w/o locks * minimal supply chain example - [`signy#74`](https://github.com/cnabio/signy/pull/74) * Trishank: quickly finish some gaps and finalize it * Carolyn: why was this in signy? * Trishank: because we want signy to instantiate in-toto software supply chains for the user * verify in-toto metadata in OS or container - [`signy#75`](https://github.com/cnabio/signy/pull/75) * Trishank: need to sort the broken docker integration test with Radu * Carolyn: will this continue to work with containers? * Ralph: yes, containers will be default, with OS being an option * CNAB Registry support updates * The Harbor container registry now has CNAB support (Radu / Ralph) * Ralph: Harbor said go ahead and test CNAB against them * It works locally, even if a little flaky * CNAB icon is now next to bundles! * Works on DigitalOcean 50% of the time * GitHub Registry expected to move to Docker distribution * Carolyn would like to move a demo from Porter to CNAB website * People can then send PRs * Question from Slack: CNAB support on Nexus and Artifactory registries * Carolyn: has anyone tried this? * Ralph: Artifactory _was_ very popular, but he doesn't run into them anymore * Carolyn: which aspects of the [OCI compliance report](https://github.com/bloodorangeio/oci-conformance/tree/master/distribution-spec) are critical for `cnab-to-oci` to work? ## May 6th - Security and Registry Meeting | | | | -------- | -------- | | Recording | | | Attending | | | Note Taker | | ### Agenda * ~~Welcome new CNABBERS πŸ¦€~~ * ~~[Discuss Registry PR](https://github.com/cnabio/cnab-spec/pull/362#pullrequestreview-404372943)~~ * ~~Known implementations [`cnab-spec`#288](https://github.com/cnabio/cnab-spec/pull/288)~~ * ~~Clarify how to verify & inspect in-toto metadata [`cnab-spec`#364](https://github.com/cnabio/cnab-spec/pull/364)~~ * ~~Option to verify in-toto metadata on OS or container [`signy`#73](https://github.com/cnabio/signy/pull/73)~~ * ~~Minimal example of a software supply chain [`signy`#74](https://github.com/cnabio/signy/pull/74)~~ * Postponed ## April 29th - General Meeting | | | | -------- | -------- | | Recording | https://youtu.be/a7lt2o5jUPU | | Attending | Trishank Karthik Kuppusamy, Aditya Sirish, Chris Crone, Radu Matei, Matt Butcher, Carolyn Van Slyck, Vaughn Dice, Jacob LeGrone, Ralph Squillace, MChorfa | | Note Taker | | ### Agenda * Welcome new CNABBERS πŸ¦€ * New Associate Maintainer: Carolyn Van Slyck (Butcher) * Add parameter sources custom extension [`cnab-spec`#365](https://github.com/cnabio/cnab-spec/pull/365) (Carolyn) * Carolyn: This change backfills a gap we had in the spec when claims were previously changed - the contents of the output were in the claim itself, and it made it possible for one action to pass data into the next action. However, this didn't work well, since outputs can be large, and it did not make sense to embed output in claims. We pulled out output from claims, and this change adds parameter sources. The author can use custom extensions to specify how runtimes may connect outputs back to parameters. * Carolyn: this is a very early change, so please provide feedback on this PR. * Carolyn: I see Jacob already had some thoughts. * Jacob: do we want to support multiple parameter sources for the same parameter? * Carolyn: this is a great idea, particularly for multiple environments (dev, prod). I don't see a problem having this option. * Vaughn: how does this interact with default parameter values? i.e for parameters with sources and default values. * Carolyn: implementations might have additional sources (?) available. This change does not ratify the definitive source / order for retrieving paramter values, other tooling can make different choices (hierarchy) - we think that a default value might be the last source. * Jacob: runtimes could return an error if there is no source, and no default value set for a parameter. * Carolyn: did you add this as a comment already? This should be. * Chris: why not MUST? * Carolyn: this might depend on whether it is a required parameter or not. * Jacob: this is also an extension to the spec, so maybe runtimes that implement this extension MUST return an error. * Carolyn: we should think some more about this, I don't want to back all implementations into a corner, but have this more of a guidance. * Chris: if it is an extension -> MAY, and we have a requirement behind it -> MUST, this may be confusing. * Carolyn: this is also why I didn't want to * Chris: at runtime it must return an error if the parameter value is not specified, right? * Jacob: maybe we could have a map of parameter sources with well-known keys (output source being one), and runtimes that don't implement the ability to resolve them could skip when resolving parameter sources. If they cannot resolve any source, they should return an error. * Initial draft for registry specification [`cnab-spec`#362](https://github.com/cnabio/cnab-spec/pull/362) * Radu: please review * Claims spec: * Matt: do we think we are on track to put the claims spec on vote at the end of May? * Jacob, Ralph: Yes. * Chris: is anything blocking it? * Ralph: not sure. * Jacob: it would be nice to get an implementation into cnab-go before we vote on it. * Canonical JSON and Helm values file (Jacob) * Jacob: trying to come up with a workable example for this, this might still be an underlying issue with the Helm values files. * Jacob: we are unmarhaling multiple YAML files, merging their values together (as Helm does), and we get a map[string]interface which we want to marshal back to JSON -> canonical JSON. * Radu: are there any characters not supported in the canonical JSON spec * Jacob: yes, this might be the issue. * Carolyn: So you have a YAML file and you want it to be in bundle.json? * Jacob: this might be included in a claim at some point, and we want to have it canonicalized, so we can digest it later. * Carolyn: Porter added a custom parameter type that only Porter understands, which is file, and we base64 encode it. This is how we manage to avoid canonical JSON and decode it at runtime. * Jacob: we also have a JSON schema, which we want to enforce, and we want to allow users to change this at runtime. * Carolyn: I hate canonical JSON. * Radu: there is a basic test we've been doing with another Rust implementation - there might be an issue where the new change allows invalid canonical JSON. * [Discussion of CNAB dependencies](https://github.com/cnabio/cnab-spec/issues/361) (MChorfa) * Security * Known implementations [`cnab-spec`#288](https://github.com/cnabio/cnab-spec/pull/288) * Radu: still in draft status, already discussed, needs one more LGTM before merging. * Ralph: let me know if you need help in getting people to review this. * Clarify how to verify & inspect in-toto metadata [`cnab-spec`#364](https://github.com/cnabio/cnab-spec/pull/364) * Radu: PR is ready, has been discussion, needs one more LGTM from a spec maintainer. * Option to verify in-toto metadata on OS or container [`signy`#73](https://github.com/cnabio/signy/pull/73) * Review required (Radu) * Docker Hub credentials for GitHub Action (Vaughn) * Image tagging strategy (version, commit hash). * Trishank: we have arbitrary commands that can run as part of inspections. Where do we run those? * Trishank: * Vaughn: I can see why we wouldn't want to have tags for each PR. * Radu: we can have a tag for each release, and have an 'edge' or 'latest' tag. * Ralph: and it's the responsibility of the verifier to have control over their verification steps. a container is merely an enabler here.
flexibility is important, but 95% will use the container provided.
 * Minimal example of a software supply chain [`signy`#74](https://github.com/cnabio/signy/pull/74) * Explain what it does. * Trishank and Aditya to show demo of root layout and link metadata. * Trishank: we think we have an idea of what an minimal supply chain template would look like. * Trishank: this change would give you a default supply chain template, and this is one example. It generates layout keys, and generates a root layout, and allows you to update the rules. * Aditya: this uses [in-toto ITE 4](https://github.com/in-toto/ITE/tree/master/ITE/4). We use the in-toto-run command to generate link attestations. * Trishank: this is what a developer would have to do as part of a git hook, for example. * Aditya: DEMO * Ralph: Discuss dev side basic usage of in-toto in GH as an example * Ralph: we are getting close to being able to enable a real workflow, and I'm starting to think about the basic materials needed for supply chain. We are going to have to have developers at least sign their commits. I wanted to let people know that I'm going to chat with Microsoft and GitHub about helping to make signed commits by default easier. ## April 22nd - Security and Registry Meeting | | | | -------- | -------- | | Recording | | | Attending | Trishank Karthik Kuppusamy, Radu Matei | | Note Taker | | ### Agenda * Welcome new CNABBERS * Discuss where `signy` should verify in-toto metadata * OS? * Container: user-specified or bundle-developer-specified? Why not bundle-developer-specified? Discuss infinite regress of in-toto metadata verification. * Discuss [`signy#73`](https://github.com/cnabio/signy/pull/73), a PR that provides both OS or container verification * Jacob: would like to see a declarative API/DSL for well-known inspections * Radu: would like to see better UX for signy to OS/container verify * Jacob & Radu: inspections, just like invocation images, do open up some security issues about resource consumption for invocation and verification images * Discuss simple in-toto software supply chains aka root layouts * ABC example * Datadog example * Collect CNAB uses cases users would like to see * CNAB use case: two steps * Image use case: also two steps * Jacob & Radu would like to support out-of-the-box signing for both bundles and images * Trishank: need to fix `signy` to verify images referred to in bundles, will be off by default, but people like Jacob can turn it on * Radu: `signy` can check signatures on bundles copied to a different registry, even with a different GUN, unlike Notary-v1 * Please review: * [`cnab-spec#288`](https://github.com/cnabio/cnab-spec/pull/288) * [`cnab-spec#364`](https://github.com/cnabio/cnab-spec/pull/364) ## April 15th - General Meeting | | | | -------- | -------- | | Recording | https://youtu.be/XGZSAcgbdaA | | Attending | Chris Crone, Carolyn Van Slyck, Tom Haney, Trishank Karthik Kuppusamy, Silvin Lubecki, Ralph Squillace, Radu Matei, Matt Butcher, Jacob LeGrone | | Note Taker | Radu Matei | ### Agenda * Welcome new CNABBERS * Welcome Jacob as spec maintainer * Reviews: * Split claim and result into separate documents - anything else before merging? ([#349](https://github.com/cnabio/cnab-spec/pull/349#issuecomment-612207901)) (Carolyn, Jacob) * Carolyn: recently updated this PR, waiting for final review from Jacob * Jacob: almost finished the last review, submitted some comments - it is looking really good, thanks, Carolyn! Just a couple of superficial comments left. * Butcher: we are very close to finalizing the claims spec, right? * Jacob: I agree. The larger change is that outputs are no longer parts of the claim, so runtime implementors should review this PR. * Butcher: thank you for pushing through this change! * Carolyn: we introduced an identifier for claims, and we're using it to reference results back to claims. Please review! * Carolyn: Demo - Josh Dolitsky and Vaughn added plumbing in Porter to allow necessary configuration for accessing the Docker daemon on the host (and potentially privileged containers). This is off by default, but allow people to run Docker Compose. * Carolyn: this improves Porter UX around Docker Compose with a new mixin (interested in making the experience much better in Porter, and the new Compose spec!) * Carolyn: demo of the new Docker Compose mixin. Please give feedback in the Porter repo. https://github.com/deislabs/porter/ * Establishing trust for multiple registries - just needs a rebase ([#332](https://github.com/cnabio/cnab-spec/pull/332)) * Radu: just needs a final rebase. * Trishank: rebasing right now, so we can mege. * Initial draft for the registry specification ([#362](https://github.com/cnabio/cnab-spec/pull/362)) (Radu) * Chris: we can leave sections as TODOs until we have clear direction. Looking at what we have so far, the annotations part is still left, as well as storing non-container components. * Chris: updates are also happening in OCI Artifacts. We should also add a few examples. * Radu: should we have a known implementations section, similar to the CNAB security spec? * Chris: yes, that makes sense. * [Signy v0.0.3 release draft](https://github.com/cnabio/signy/releases/tag/untagged-00ed798ca223bbe46852) (reuse TUF root and targets, update to Go modules) (Radu) * CNAB Security known implementations ([#288](https://github.com/cnabio/cnab-spec/pull/288)) (Radu) * Trishank: looks good, the original review, there was one more review item, but we could merge as a draft. * Radu: the main review item left is around transparently verifying for in-toto metadata. * Should in-toto verification image be a CNAB component? (Radu) * Radu: Verifications work by running the in-toto CLI to perform verification (thus CLI is required, along with other utilities). Those may be highly specific versions/os/arch, etc. So we can't make the decision at layout building time what tools need to be used. So we can run them in a container image. Right now, you have to run the verification inside of a container that you create. * How does a bundle author define and distribute the verification image (and can it be part of the invocation image)? * Trishank: The in-toto checks the entire supply chain for creating the tools used in the image. We want to bundle the verification so that it can be run by users. How do we distribute it. We could distribute the verification as easily as we distribute any other images. * Radu: Two questions: * Can client tooling override a verification image * Trishank: The verification image is hard-coded as part of the software supply chain. If this can be overridden, why bother with the SSC verification in the first place? * Radu: In in-toto, you still rely on the client environment for running the verification, and that can be different. So in-toto itself does not give you this exact reproducibility. But my org might have specific requirements (such as logging the results of the verification). So I might have an image that supplies this functionality for running a given verificatin. * Trishank: Yeah, that makes sense. You might want to root it in your own environment (image?). This is slightly different than the in-toto spec right now * Radu: Signy allows you to supplier your own verification image. As long as it has in-toto. It has the minimum requirement that in-toto states that it requires. * Trishank: Though in-toto does not do this by default, we should standardize on this. We should consider the wishes of the original supply-chain provider. But I don't see why we couldn't... * Ralph: Two roles: Producer creates the verification to _project_ the reliability. The consumer wants to _protect_ themselves from various liabilities. But we have to balance the needs of these two while acknowledging that there is an "out of band" agreement that this is a process to follow. So we will have usecases that will benefit from the shared image, and others where consumers will prefer to use their own. But this is probably always going to be an out-of-band organizational choice. * Trishank: When in-toto says to run an inspection, it does not tell you which host to run it on. One thing we could do is fool in-toto into running in a different environment. * The notetaker is lost * Radu: There are two kinds of verification:... There is no guarantee (in the spec) that the host is configured correctly, identally to the original producer. So we get around this by using a container image. * Should verification be part of bundle.json, or is it generic enough that we don't add it to bundle.json, and have conventions to allow fetching.? * Trishank: I think it should be ABOUT bundle.json. So it should be separate. So just like we distribute keys, we should distribute the verification * Radu: It can also be a convention of client tooling to find which verification to use * Trishank: TUF metadata could tell us everything we need to know about getting and running the verification * Demo of docker and docker compose functionality in Porter (carolynvs) ## April 1st - General Meeting | | | | -------- | -------- | | Recording | https://youtu.be/xSEsQwjXRK8 | | Attending | Chris Crone, Carolyn Van Slyck, Ben Whiting, Glyn Normington, Ralph Squillace, Matt Butcher, Radu Matei, Karen Chu, Trishank Karthik Kuppusamy, Jacob LeGrone, Vaughn Dice | | Note Taker | Radu Matei | ### Agenda * Welcome new CNABBERS πŸ¦€ * Declarative installation support (Glyn) - [#358](https://github.com/cnabio/cnab-spec/pull/358) * Glyn: we discussed making invocation images optional, and the implications it would have on the spec - decided it would have too big an impact on the spec, and so we are dropping this issue for now. This means VMware will not use CNAB for the Kubernetes use case. * Chris: Thanks for the work here, we are curious to see what you end up using for this specific use case. * Ralph: Thank you for working on this issue, helping us understand this how this could work. Hopefully we make enough progress to get back to working on this in the future. * Chris: This also kicked off a bunch of interesting ideas in this space. * Glyn: VMware is experimenting with some other options, such as [sheaf](https://github.com/bryanl/sheaf) and [kbld](https://get-kbld.io/). See, for instance, Spring Cloud Dataflow's [spike](https://github.com/spring-cloud/spring-cloud-dataflow/issues/3858) to explore packaging options. * Needs review: * split claim and result into separate documents - [#349](https://github.com/cnabio/cnab-spec/pull/349) * Carolyn: this change has been out for a while - depending on whether the action modified or not, the revision wasn't bumped. The main change in this PR is that every time an action is executed, the runtimes have the option to update the revision. Tools that want to keep every action result are now enabled to do that with this change in the spec. The last commit in the linked PR has the relevant changes. * Chris: I see there are 3 LGTMs already. * Jacob: I didn't see the last update, I would like the chance to review this before it gets merged. We are building something that doesn't update the revision, but still allows the tracking of all actions. * Carolyn: Sure - this is an optional change. * add schema validation in `cnab-go` - [#188](https://github.com/cnabio/cnab-go/pull/188) * Vaughn: simple implementation of schema validation, now that CI generates schema. It is ready for a re-review now. * Chris: if you need another review, feel free to ping Silvin. * Update active checks required for merging -`validation` and `cnab-spec-validate` (Radu) * Radu: * Vaughn: older PRs that were created before #340 - once they are rebased against `master`, they will only require `cnab-spec-validate`. * Radu: if you have an open PR for CNAB spec, please rebase against `master`. * Registry * Chris: we are still updating the document - other than the on-disk representation, which we don't currently support. * Radu: will open a draft PR with the changes in the HackMD document ## Mar. 25th - Security and Registry Meeting | | | | -------- | -------- | | Recording | https://youtu.be/wn2-oWx4qDw | | Attending | Radu Matei, Trishank Karthik Kuppusamy, Chris Crone, Matt Butcher | | Note Taker | Trishank Karthik Kuppusamy | ### Agenda - Please review - [cnab-spec/356](https://github.com/cnabio/cnab-spec/pull/356) - [signy/59](https://github.com/cnabio/signy/pull/59) - Notary v2 delegations model issue - [working document](https://hackmd.io/@radu/By3G7Ni7L) - Trishank to write primer about delegations - preparing the security spec for final reviews and feedback - [cnab-spec/356](https://github.com/cnabio/cnab-spec/pull/356) - `signy` - open issues for implementing the delegations model for in-toto root layout key and templates - introduce root layout templates to make in-toto easy to use - will include basics like checking git commits and simple inspections - we need the community to contribute use cases so that we can build the right templates for them - registry spec update - [working document](https://hackmd.io/@ccrone/HySy-hQEI/edit) - Radu and Chris need to figure out how to handle differences in how real-world registries handle images and the OCI spec ## Mar. 18th - General Meeting | | | | -------- | -------- | | Recording | https://youtu.be/vOzXPrDcang | | Attending | Ben Whiting, Carolyn Can Slyck, Tazin Progga, Silvin Lubecki, Glyn Normington, Ralph Squillace, Trishank Kuppusamy, Radu Matei, Karen Chu, Jacob LeGrone, Vaugh Dice | | Note Taker | | ### Agenda * Welcome new CNABBERS πŸ¦€ * Optional invocation images - [#352](https://github.com/cnabio/cnab-spec/issues/352) (Glyn) * Glyn: declarative installation support, and there is a proposal to exctend the metadata to "please" the K8s community, which is neverous about invocation images, hence the proposal. There is an open pull request, and the idea is to make invocation images optional - it means the runtime must understand the specifics of the bundle, meaning the bundles are not compatible with one another. * Glyn: just making the invocation image optional is part of the solution, but other things might fall out of the spec - parameters, credentials, and outputs are mapped in the invocation image, so my first attempt was to leave all of them out. * Carolyn: if one of the credentials your runtimes wanted was a kubeconfig, and we are not handling credentials anymore, how are you passing that? * Glyn: this is the job of the tool / runtime - the bundle does not need to specify that, it is * Carolyn: have you looked at Jacob's proposals? * Glyn: yes, that is a good step in the right direction, but not enough to capture VMWare's use cases * Ralph: if we walk back to the ongoing conversations (the gradient of bundles - arbitrary invocation images, runtimes swapping to known invocation images and temp credentials, and a purely declarative approach) - the abstract issue is the attempt to have confidence in the execution process. The second model, which passes known invocation images, lets us have confidence in what gets executed. But in the course of the conversation, it seems like the proposal in place aims to a specific implementation, rather than to a goal - which meets the juddgement of the implementation, rather than the other way around. * Ralph: if we had a known invocation image, and we have a way of restricting credentials used, it might meet the abstract goal set in place (rather than an implementation goal). If we go forward, I am not clear how any runtime can do anything else with a bundle other than the default action. Other than grabbing the loction of the mainfest, and the runtime executing what is doing, is there any way the runtime can do anything else. * Glyn: image relocation would continue to work, security supply chain would still work. * Ralph: if a runtime examines the bundle, and doesn't see the optional declarative approach, it could work. * Glyn: another way to put it is we create a k8s specific declarative-only "corner" of the spec. I could accept that we might now want to do that. * Jacob: is VMWare working on a runtime that implements this? * Glyn: we shared the sheaf prototype, which is inspired by CNAB - if we can get the declarative approach, I want sheaf to produce bundles * Ralph: I have a concern that if we like this idea, there may be confusion around the features CNAB advertises to users. It is important for us to decide if we enable the CNAB bundle format only. * Radu: is there anything else other than an image list left in the proposed version of the bundle? * Glyn: no, but there are things like the think format, and the other specs that we could leverage. * Ralph: image mapping, security information related to images, and the thick bundle format. * Carolyn: there is one thing we didn't talk through - compatibility across tools - a bundle made in Porter / Duffle / Docker app - there always was the expectation that a bundle can works across tools - I have the impression that this is a feature that only one implementation is interested in. * Carolyn: if we put this in the spec, we could lose the compatibility guarantee. We would end up with a tool that would only work with its bundles - Porter could never run a Sheaf bundle, and we should be aware this could happen. * Ralph: I am very concerned about the question of the gradient. It's one thing to have a clear path wrt gradient, and another to have a runtime that only works with a bunndle type. * Ralph: there has always been the option to run custom extensions - how is this different? * Carolyn: current custom extensions are optional. For example, if the outputs custom extension is not there, the bundle execution stops, so this particular example falls in the same category. * Ralph: given the objective of the proposal, it is difficult * Jacob: if the objective is to force the bundle not to support invocation image, just omit it from the bundle - if you want to be non-normative from the bundle, it is not crazy to omit the invocation image. Why not use a different "type"? And it would be * Glyn: just missing the invocation image, * Jacob: parameters, outputs, they are totally optional. Why specify they have to be ignored? * Glyn: thinking about having a separate "type" of the invocation image. If we could say the type is "declarative", it would be great. But the current spec is quite biased towards a representation of a file system. * Ralph: how about a WASM runtime? * Radu: this does not prevent us from doing it necessarily, but we can do file mapping. * Ralph: then I am interested in trying around to see how we could do this with the spec. * Jacob: WASM is a great exampe to consider. * Ralph: we should have a TODO issue associated with the other issues. * Radu: there is a feeling that the current changes requested to the spec are very tied into a specific implementation. Is that useful to any other env? * Ralph: * Glyn: just omitting the invocation image is not biased to k8s necessarily * Ralph: I don't have a use case for running WASM, but it could be. * Ralph: leading the TODOs about WASM and processes. * Remove outdated reference to `bundle.cnab` in published spec [#353](https://github.com/cnabio/cnab-spec/pull/353) (Radu) * Trishank: we had this issue in TUF as well, where we introduced a fetured that was never implemented, then took them back from the spec. * Vaughn: +1 on 1.0.2 ; perhaps add a that proposal (w reasons mentioned here) to the issue in comment form and we can vote on it? * Carolyn: I vote for a patch * Ben: my first reaction was to ignore it as well. * Quick fix for broken link in security spec [#355](https://github.com/cnabio/cnab-spec/pull/355) (please review) (Trishank * this just needs one more approval, really easy spec. * Establish trust for multiple registries - (anything else before merging?) [#332](https://github.com/cnabio/cnab-spec/pull/332) (Radu * Glyn: we ended up with some caveats, which is what I was looking for - I think we have enough hints there. * Update on key delegations for in-toto [#356](https://github.com/cnabio/cnab-spec/pull/356) (Trishank, Radu) * Trishank: Ralph organized a meeting with Justin, and talked about whether we could do the key delegations for the in-toto root key. * Trishank: we want a target key that should sign the root layout, and machine keys to sign anything else. * Trishank: https://github.com/cnabio/cnab-spec/blob/28cde2c6d27668f216e52aad0d4787bb4dc75452/301-metadata-repositories.md * Trishank: we had some options (forking Notary, making changes upstream, or have a default key delegation scheme) - we decided to have the default key delegation schema, at least for the current implementation. * Trishank: the other update is that Radu, I, and the NYU team met last week about the in-toto security guarantees. * Trishank: tooling could give you an example. We are trying to make TUF easy to use, we should do the same for in-toto. We want to have some templates that you can reuse, which would hopefully work for most use cases. * Radu: * Trishank: not only your pipeline should be immutable, but only something in your pipeline signed by humans. * Radu: * Glyn: you mentioned signing git commits - are there any other examples you could give that would make in-toto more approachable? * Trishank: https://www.datadoghq.com/blog/engineering/secure-publication-of-datadog-agent-integrations-with-tuf-and-in-toto/ * Radu: https://in-toto.engineering.nyu.edu/ * Ralph: everyone take care of yourselves! ## Mar. 11th - Security and Registry Meeting | | | | -------- | -------- | | Recording | https://youtu.be/cBThLt6ifK0 | | Attending | Chris Crone, Glyn Normington, Silvin Lubecki, Matt Butcher, Justin Cormack, Carolyn Van Slyck, Radu Matei, Jacob LeGrone, Trishank Kuppusamy, Jeremy Rickard, Ralph Squillace, Matt Fisher, Alex Xu | | Note Taker | Jeremy Rickard | ### Agenda - declarative installation support - [#285](https://github.com/cnabio/cnab-spec/issues/285) (Glyn, Ralph) - Glyn: Pivotal used CNAB for Alpha Software prior to VMware - Glyn:After VMware acquisition, some objections to CNAB - VMw likes the image list (bundle.json) - VMw dislikes the executable invocation image + opaque use of credentials - Ralph: Understand sensitivity and background of ActiveX - Mitigiation to ActiveX trust was digital signing - Nobody ever really checked those / trusted them - Some trust roots later discovered false - A CNAB bundle could do anything if you allow it - Difference is technology here is all open / inspectable - Containers + Binaries could be inspected - Mount file system, extract it, compare hash, etc - We should scope to ability to inspect contents in container is high enough and if shelling out is sufficient - Justin: suspicious of inspectability given nature of modern software - Working out what modern software is doing is very hard - Ralph: there are no production cloud native apps that know / validate all modules/libs they use - When you get into a distributed graph of vetting we don't do it - Trishank: notes that k8s binary is not even currently signed - Ralph: even if it were signed, that only helps you know it's what k8s says it is, people assume kubernetes is doing all the vetting (assumed trusted, nobody vetting) - Glyn: the point of introspecting a container really falls apart at examining a binary - Wouldn't satisfy VMw use case, want purely declarative installers - Ralph: want to see what can be done, but need to examine problems. - Jacob: minimum is image sig validation. Static analysis is a non-starter - Opened a couple of follow up issues (extensions) : - https://github.com/cnabio/cnab-spec/issues/337 - https://github.com/cnabio/cnab-spec/issues/338 - A new layer - address how credentials are being used and what doing - A third layer - a dry run like approach to render what will be applied to a cluster for validation and compute what permissions are actually required for a stateful action next time around and create kubeconfig with exact permissions (down to the resource name level) - highest level of security - Chris: could use ephemeral credentials as well and track exactly what happened. Need to decide what to mitigate against, what vectors are and layers become super important - Jacob: extensions designed to not require spec changes but provide progressive enhancements - Glyn: those are good building blocks, Joe Beda's comment in the issue summarizes the kind of tool VMware is looking for. Top of the spectrum is no invocation image, just metadata packaged with the bundle. Tool can inspect metadata and do what it wants. Next layer down is well defined invocation image, can be trusted via sha (next best thing), then the opaque invocation image. VMw desireability is the first two, invocation image being necessary part is a sticking point. If invocation image is optional then it becomes more attractive - Jacob: that's in one of the extensions. Doesn't really see a difference between k8s cli and trusted invocation image with the bundle. If we have a standard way of referencing manifests via an OCI artifact, can swap out the invocation image - Glyn: That's the middle spectrum that Joe laid out. - Jacob: Runtimes could do the talking to k8s cluster or an invocation image could be used, basically the same. - Glyn: Not quite the same because you're allowing executable things into the bundle vs a purely declarative tool - Ralph: what Jacob is saying: nothing preventing a runtime from identifying manifest resources based on annotation and swapping out to a trusted invocation process - JAcob: yes if we have this custom extension that identifies how to pull the manifests that will be applied, they can handle anyway they see fit (use an invocation image they build themselves, other trusted thing) - Ralph: process is key part, could be in container or could be on local machine. Concern: wish to have our flexibility to modify the specification but i don't think it's necessary to modify spec to obtain same gurantees. Middle point in Joe's spectrum is in scope of current spec - Glyn: point about the spectrum - middle point is probably applicable to some part of community, top of the spectrum (purely declarative) is probably more applicable - Roundup : we will work through the two issues in up above and iterate to see how we can get to the point that works for everything - CNAB Registries spec update (Radu, Chris) - CNAB Security - delegations update (Trishank) - TUF specification supports delegation - Does Notary V1 support out of box? - What are minimum set of changes needed for notary v1 so delgation can work - Matt: Notary is not interested in upstream commit to fix thing for v1 - Point raised for V2 - Ralph: will arrange conversation with Justin to confirm - One thing we could do instead of forking notary, we could hard code how delegation done - Not ideal, ok for MVP - Radu: suspect we could change behavior outside notary alltogether - Matt: either way we have to tell people how to do it, forking notary seems least desirable unless we have to change bundle format. Skeptical layering on a external security model will be good - Radu: not external model, just picking what key - Matt: but still another tool and need to pick keys for different scenarios - Matt: taking over a big part of what notary does if we build our own tool - Trishank: yes proposing a tool w/in our reference impl that expects delegations to be sorted out in a specific way, any other way will break or may not work. 3rd option is upstreaming but has to be backward compatible with how notary works - Radu: the tool would be signy - Matt: largely a client side process that sounds more palatable - Trishank: We are OK with forking notary, but we prefer not to - Trishank: Docker restricts you to using the targets and delegation role (delgation +1) in practice. ## Mar. 4th - General Meeting | | | | -------- | -------- | | Recording | https://youtu.be/q4DT-6IJKQg | | Attending | Carolyn Van Slyck, Chris Crone, Silvin Lubecki, Radu M, Matt Butcher, Karen Chu, Jacob LeGrone, Tom Hane | | Note Taker | Chris Crone | ### Agenda * Welcome new CNABBERS πŸ¦€ * CNAB Core 1.0.1 [#335](https://github.com/cnabio/cnab-spec/pull/335) * Review/Merge Needed: * [Split claim into execution inputs and results #339](https://github.com/cnabio/cnab-spec/pull/339) * [Clarify pending status, introduce running #340](https://github.com/cnabio/cnab-spec/pull/340) * [Add common community documents #24](https://github.com/cnabio/community/pull/24) * (Chris) CNAB registry spec update ([working document](https://hackmd.io/@UttpSA1cSfWU-VNqaNJATw/HySy-hQEI/edit)) * (Jacob) Declarative credential scoping [#337](https://github.com/cnabio/cnab-spec/issues/337) and declarative installers for Kubernetes [#338](https://github.com/cnabio/cnab-spec/issues/338) * Offline chema validation in `cnab-go` (and other implementations) (example - [#188](https://github.com/cnabio/cnab-go/pull/188)) * Should cnabio/community have a CODEOWNERS file? Who should be in it? ### Notes - CNAB 1.0.1 is ready to be released (Matt) - Subminor/patch releases only include minor fixes and clarifications - [PR](https://github.com/cnabio/cnab-spec/pull/335) has been LGTM'd by all maintainers and CNAB project leads so is validated - We will merge the PR after this meeting - [Spec PR #339](https://github.com/cnabio/cnab-spec/pull/339) (Carolyn) - Claims specification is actively being worked on so that tools are interoperable - Separation of claims and outputs as outputs can be big - Shuffle around fields so that we don't need to store all outputs as part of the claim - Chris would be for merging this and asking for improvements - 400 part of the spec is unstable so fine to merge and ask for improvements - [Spec PR #340](https://github.com/cnabio/cnab-spec/pull/340) - Clarify pending state - Add running state to indicate when the invocation image is currently running - Make visible that there is an operation in progress - Jacob would like that we standardize on noun/verb and suggests we add a cancel state - [Community PR 24](https://github.com/cnabio/community/pull/24) - Adds common documents to community repo: contributing guide and governance - Ready to merge and will follow up with PR to match what we say with what we do - Unclear who owns repo - Chris thinks anyone should be able to contribute except on some files - Carolyn will put up PR - Working document for CNAB Registries - Chris: we have a structure in place - anyone who wants to contribute is invited to, Chris will start to document how `cnab-to-oci` works right now - Chris: do we have a process of ratifying other specs? - Matt: we have the same process as for the core spec, vote has to be unanimous. - Chris: it may be worth having external people review the security document (Justin Cormack) - Jacob's work on [#285](https://github.com/cnabio/cnab-spec/issues/285) - Please take a look at these! - Show complexity of making bundle internals visible even if you know the target - [Spec PR #337](https://github.com/cnabio/cnab-spec/issues/337) - Declarative credential scoping - Builds on extensions work done by Simon and Silvin - Can add this as non-core spec - Carolyn: Is idea that bundle says these are the credentials the bundle needs and that the expectation is that the runtime creates user/service config with these? - Jacob: Idea is to pass admin credentials and have them down privileged - Unfortunately this isn't practically easy to do - Carolyn: Where would the code that does this live, CNAB Go? - Matt: This would be non-normative so could be implemented in an external tool - Jacob: For CNAB Go, we could have an interface for multiple credential providers and that spits out credential sets - Carolyn: Wondering how portable bundles like this would be - Jacob: Goal is to have something portable and avoid having bundles only be able to be installed by one tool - Carolyn: Tool that understands this extension has better security, naive tool still works - [Spec PR #338](https://github.com/cnabio/cnab-spec/issues/338) - Declarative installers for Kubernetes - Radu: Feels like using OCI manifests to share Kubernetes YAML has suddenly come up - Not sure that CNAB is the right place to solve this - Jacob: Don't have this use case but wanted to show that it could be done - Matt: Need to work out if this is an issue impacting enough users - [CNAB Go #188](https://github.com/cnabio/cnab-go/pull/188) - Validate schema offline - Schemas currently live online (cnab.io/), we currently fetch the schema to do validation - This doesn't work for airgapped scenarios - Docker has done this in docker/cli for Compose - Radu doesn't want to copy paste the schema in a Go file - Bin packer? gobuffalo/packr - Jacob: Would be good to embed schemas for their parameters - Radu: We could bundle the schema in thick bundles - Matt: Means we'd be asking bundle if it's valid - #285 meeting? - Glyn is going to plan this - Will aim to do something morning time Pacific - Microsoft are using CNAB and have made some blog posts about them - https://blogs.endjin.com/2020/03/introducing-the-azure-cnab-quickstarts-library/ ## Feb. 26th - Security and Registry Meeting | | | | -------- | -------- | | Recording | https://youtu.be/TSG4DF9gf_0 | | Attending | Radu Matei, Chris Crone, Silvin Lubecki, Trishank Karthik Kuppusamy | | Note Taker | Trishank Karthik Kuppusamy | ### Agenda - CNAB registry spec (Chris Crone/Docker, Radu) - [working document](https://hackmd.io/@UttpSA1cSfWU-VNqaNJATw/HySy-hQEI/edit) - Chris, Silvin, Radu, and Trishank will discuss and collaborate over Slack - [establishing trust for multiple registries (`cnab-spec #332`)](https://github.com/cnabio/cnab-spec/pull/332) (Trishank, Glyn) - Radu and Trishank agreed that this is something that should be discussed in general terms in the Security spec, but for which the spec should not propose any restrictive opinion. However, bundle runtimes are free to be opinionated on this mater. - present the CNAB [scenarios document](https://hackmd.io/@radu/By3G7Ni7L) for Notary v2 (Trishank, Radu) - Radu and Trishank attending the meeting - We will file an issue on the Notary v2 about key management, especially delegations - [the media type used doesn't meet the OCI artifact spec (`cnab-to-oci`#100)](https://github.com/cnabio/cnab-to-oci/issues/100) - Radu: this is technically correct - Matt thinks we should make it `application/vnd.cnab.cnab.config.v1+json` - Silvin: should it be `cnab` or `cnab.io`? Radu doesn't have a strong opinion this. Silvin is good with Matt's proposition. - initial CODEOWNERS for Signy ([signy #69](https://github.com/cnabio/signy/pull/69)) (Radu) - Silvin has no objections - clarify contentDigest meaning for docker/OCI images[`cnab-spec#287`](https://github.com/cnabio/cnab-spec/issues/287) (Radu) - Radu: this is a long-running issue. It is also a tooling issue, confirmed by Justin Cormack at the Notary v2 meeting, who said that `containerd` issues reliable digests that works across registries. - Silvin: this is something that we can try with `cnab-to-oci`, especially with registries that support CNAB. - updates on key management in `signy` - push `snapshot` key to Notary - reuse `targets` key across bundles - working on delegations - Radu: biggest concern I have is on whether we can achieve the delegations we need for in-toto w/ Notary v1, or whether we need to fork in-toto and / or Notary. - Radu: another option is to refer to `pysigny`, which uses `python-tuf`, to make this work. - Trishank to figure this out before next Security meeting. - Radu: this and 304 are the only things blocking Security spec right now. If we are clear enough on delegations, we can call for a vote in a month's time. ## Feb. 19th - General Meeting | | | | -------- | -------- | | Recording | https://youtu.be/7NwRgeLlshs | | Attending | Silvin Lubecki, Carolyn Van Slyck, Radu Matei, Chris Crone, Jacob LeGrone, Vaughn Dice, Ben Whiting, Ralph Squillace, thomhane, Karen Chu, Trishank Karthik Kuppusamy | | Note Taker | Carolyn Cnabby Van Slyck | ### Agenda - Welcome new CNABBERS πŸ¦€ - (delayed as no butcher is here) Vote on [cnabby the crab](https://cloud-native.slack.com/archives/CEX1W7WMD/p1581531593127100) as our official autocompletion mascot - CNAB registry spec (Chris Crone/Docker) - CNAB Security (Radu M) - moved Signy to [`github.com/cnabio/signy`](https://github.com/cnabio/signy) - need formal core maintainers - ongoing Notary v2 discussion - gathering requirements in [this repo](https://github.com/notaryproject/requirements) - (carolynvs) Question: When we bump the spec, e.g. 1.0.1, what is the expected behavior for a tool, maybe an older version of a tool, when it loads a bundle that targets 1.0.1 and the tool was written for 1.0.0? Or other variations? - Governance: - Factorize or add template of the governance description at organization level - Update rules to better fit with the current process - Standard governance, contribution guidelines, (maybe developer guide?), code of conduct reference for all repositories (Radu M) - re-upping [#285](https://github.com/cnabio/cnab-spec/issues/285) to think about where that is - cnab-spec PR reviews: - https://github.com/cnabio/cnab-spec/pull/331 (vadice) - https://github.com/cnabio/cnab-spec/pull/330 (vadice) - add'l: https://github.com/cnabio/cnab-spec/pulls (handful from Butcher) - example bundles in duffle repo: https://github.com/cnabio/duffle/pull/888 - CNAB to OCI call for maintainers (Chris/Silvin) - KubeCon EU (Chris) - Action field to top level in claims: https://github.com/cnabio/cnab-spec/issues/328 (Jacob) ### Notes * delayed vote on cnabby because Butcher is sick * Chris: write down as part of the spec how we store bundles using cnab-to-oci, looking for volunteers. Will discuss further on the off-week meeting (registry/security) with help from Radu and DataDog. * Radu: How do we want to propose the work for the new media type? It's been proposed by Radu to OCI months back and pushed back on. (ded πŸ¦€) Ralph will help revive with a hammer. * CNAB Security (Radu M) * Moved signy to cnabio πŸŽ‰ * Looking for more maintainers/codeowners, even if you are new to the security spec. Radu will help mentor. * We need to write docs, and Radu has been identifying other low-hanging fruit. * Open discussion/issue with registries about notary v2, gathering requirements especially around airgapped scenarios. Want to present to them what we need for CNAB. * Pause to make fun of Ralph. * Should tools that targeted older patch versions of CNAB support newer patch versions of CNAB? * (carolynvs) We should open an issue to discuss forward and backward compatibility behavior and update the spec to clarify. https://github.com/cnabio/cnab-spec/blob/master/901-process.md#versioning * We have noticed drift in some of our governance and community docs that we copy between all of our repos. Instead of copying between all of them, let's get a common copy that it is up to date in the community repo, and link to them. Then open a PR to discuss changing them to match how we really operate today. carolyn (make issues), radu, silvin to follow-up (rubber-stamp brigade) * Declartive Installation Support (https://github.com/cnabio/cnab-spec/issues/285) Zombie Issue πŸ§Ÿβ€β™‚οΈ * Ralph will schedule a one-off meeting with interested people to discuss this further and split off issues from it since it's pretty far ranging. * Please review * https://github.com/cnabio/cnab-spec/pull/331 - Use https in our schema refs * https://github.com/cnabio/cnab-spec/pull/330 - Use regex that works with go * https://github.com/cnabio/duffle/pull/888 - Move example bundles from separate repo into duffle * After 888 is merged, we will deprecate the example-bundles repo. * Discussed consumers of the example bundles and agreed that they are useful for us, people who work on the spec and tools that work with the spec. They aren't targeted for people who are learning how to write bundles. Ralph will write up text that explains this so that people don't stumble on them and are confused. * cnab-to-oci is also looking for contributors and maintainers! 😎 * (Ralph) We should look at Josh Dolitski's work with the OCI registry validator to think about if this could work well for CNAB to also check if registries are CNAB (cnab-to-oci) compatible. * https://github.com/opencontainers/distribution-spec/tree/master/conformance * https://oci-distribution-conformance-results.s3.amazonaws.com/dockerhub.html * Chris has a talk at KubeKHAAAAAAAAN! Let him know if you have cool CNAB stuff that should be mentioned * There will be meetings about notary and oci. * We want to setup a cnab meeting, Ralph will help figure out how to get a room. * https://github.com/cnabio/cnab-spec/issues/328 - move action to a top level claim * Radu, Jacob and Carolyn will make a draft for splitting result from claim and make sure we are happy with how we are representing claims (this is all related to perhaps using claims to do too much) ## Feb. 13th - Security and Registry Meeting | | | | -------- | -------- | | Recording | https://youtu.be/JV6y-18LHN4 | | Attending | Radu Matei, Trishank Karthik Kuppusamy, Jacob LeGrone | | Note Taker | Trishank Karthik Kuppusamy | ### Agenda - Trishank - Busy hax0r1ng signy to improve default key management - Radu: yes, there's room for improvement in the Notary v1 model, but we need to be cognizant of being able to reuse Docker Content Trust keys for those who want that. - Radu - Moving signy to cnabio this week - Jacob - Have you seen [this issue](https://github.com/cnabio/cnab-spec/issues/285)? - What is the plan for maintaining a list of blessed (say, invocation) images? - Radu: Notary supports [pinning roots of trust](https://docs.docker.com/engine/security/trust/content_trust/#enabling-dct-within-the-docker-enterprise-engine), so we can choose to trust only these images. We can either distribute these roots of trust in GitHub (Trishank), or maintain a separate OCI index where we update them using an indirect root of trust. - Jacob: what's the plan for verifying images in an unsigned bundle? (Radu and Trishank: we can use Docker Content Trust for that.) We will need multiple layers of verification, especially when CNAB workflows enter the picture (workflows->bundles->images). Might want an optional paranoid mode where we must verify signatures on bundles and/or images (Trishank). - Jacob: what about airgapped environments? How do we transmit signed bundles? Maybe a thick bundle shipped along with signatures in a tarball? Radu: maybe you can maintain separate Notary and Registry services in each environments, and sync state every once in a while in a trusted manner. Trishank: Notary supports [ignoring expiration](https://docs.docker.com/engine/security/trust/content_trust/#using-dct-in-an-offline-environment) in offline environments. - Next steps: - Radu will take a lot at signy issues end of this week or early next week (especially the Registry self-signed TLS root cert issue) - Jacob and Trishank will pair-program and hax0r signy, they will get back with issues, lessons, and recommendations ## Feb. 5th - General Meeting | | | | -------- | -------- | | Recording | https://youtu.be/O7x4Y-heWZo | | Attending | Carolyn, Matt Butcher, Vaughn Dice, Ralph, Nuno, Silvin, Karen Chu, Radu, Somansh, Jacob LeGrone | | Note Taker | Radu Matei | ### Agenda - Welcome new CNABBERS πŸ¦€ - (carolynvs) Demo Porter saving host environment remotely and injecting secrets from Azure Key Vault - Registry and Security updates - `cnab-to-oci` moved under the [`github.com/cnabio/cnab-to-oci`](https://github.com/cnabio/cnab-to-oci) GitHub organization πŸŽ‰ - security spec drafts merged into `master` 😎 - feedback welcome - Go implementation for the security spec (`signy`) PR to move under `github.com/cnabio` ([PR](https://github.com/engineerd/signy/pull/42)) - [spec issue #319](https://github.com/cnabio/cnab-spec/issues/319) - Standardize spec version layout and use versioning per described process - CNAB Core 1.0.1 discussion (and possible vote) - Do we hold until this is fixed? https://github.com/cnabio/cnab-spec/issues/316 ### Notes - Introductions (again) - Nuno - Carolyn demos Porter - saving host environment remotely and injecting secrets from Azure Key Vault - Porter and `cnab-go` changes required to make this work - Radu: How difficult is it to add a different source for storage and secrets? - in Go it is pretty simple, used quickstarts for various clouds - the CRUD store interfaces are already defined in `cnab-go`, so in Go you have to implement the interfaces to read/write to/from your source - ideally, we could work the plugins generically enough so any CNAB implementation would use them - for other languages, implement RPC (not gRPC) - look into examples from Hashcorp plugin-go - make a binary / executable that implements the Go RPC interface - Matt Butcher: are plugins long-running? (external plugins) - Carolyn: no, there is a connection that is closed after the one operation is performed, but you can manually specify the connection to be kept open - Butcher: are there any concurrency issues if you are running multiple Porter instances that read/write to the same store (storage container)? - Carolyn: you do have to have something that is capable of acquiring a lock on a given resource so you don't concurrently try to change the same resource - Jacob: there is an opportunity to add X providers (secrets, paramters) into `cnab-go` so implementations could retrieve them directly from `cnab-go` - Carolyn: next step is to use the same model for paramters - Jacob - do we need a separate interface for retrieving paramters? (more complex validations, for example) - Ralph: let's create some concrete user stories to really understand how much more complex the paramter validations are for this scenario - Carolyn: since we have this issue both in Porter and at DataDog, I think this is a real problem - Jacob: I already have an interface for this, I could share it and see if it needs any modifications - Carolyn: Great, share it! - Jacob: it makes sense to have interfaces for getting credentials, paramters, claims. There is an issue with the driver interface where if you instantiate multiple driver instances, the driver has to recreate the claim from the operation object, which might need refactoring. Right now I have an API that is backed by the Kubernetes driver, so I have to reconstruct the claim on the API before talking to the actual Kubernetes driver implementation - Moving `cnab-to-oci` to `cnabio` - Silvin: yesterday we transferred the ownership of `cnab-to-oci` from Docker to `cnabio`. We asked JDF the requirements - only a few commits that were not signed off, we added a DCO bot to the repository. - Matt Butcher: great news! - Radu: we want to move `signy` as well - Butcher: also ask Chris Chrone - Possible vote for CNAB Core 1.0.1 - there is one issue (316) that could result in uncertainty - we should hold off on voting until after this issue is resolved - issue 319 - 3 parts to the request - explain how the documents in the spec repo relate to each other - bring the state of the files in the repo up to date with ^^ - standardize the way we represent versions - Ralph: the context is that a larger org is looking into understanding the spec, and they don't - Matt: even formatting change will have to be formalized - next week - more interfaces into cnab-go and other language libraries - hopefully call a vote for core ## Jan. 29th - Security and Registry Meeting | | | | -------- | -------- | | Recording | | | Attending | | | Note Taker | | ### Agenda - security spec - merged [draft PR](https://github.com/cnabio/cnab-spec/pull/280) for section 303 (verification workflows) - drafts PRs for sections [301](https://github.com/cnabio/cnab-spec/pull/281) and [302](https://github.com/cnabio/cnab-spec/pull/282) need rebasing - move [`signy`](https://github.com/engineerd/signy/pull/42) and [`pysigny`](https://github.com/engineerd/pysigny/pull/13) to `github.com/cnabio` ## Jan. 22nd - General Meeting | | | | -------- | -------- | | Recording | https://youtu.be/88fBb78H_oU | | Attending | Jacob LeGrone, Matt Butcher, Radu Matei, Ralph Squillace, Carolyn Van Slyck, Vaughn Dice, Chris Crone | | Note Taker | Carolyn Van Slyck | ### Agenda - Add Silvin as core maintainer for the spec - https://github.com/cnabio/cnab-spec/pull/315 - Formalize Claim fields - https://github.com/cnabio/cnab-spec/pull/309 (Matt) - Clarify contentDigest - https://github.com/cnabio/cnab-spec/issues/287 (Jeremy) - Mounting the previous bundle on upgrade actions (Silvin) - https://github.com/cnabio/cnab-spec/issues/296 - Store a claim when an action has state (Carolyn) - https://github.com/cnabio/cnab-spec/issues/312 - Call to vote on new version of CNAB Core 1.0.1 ### Notes * Approved Silvin as a spec maintainer * Discussed claims comments on the PR * Do we store state (e.g. terraform state) in the claim? In custom? Next to the claim? * Jacob suggested that bundles can specify which outputs they want mounted inside the bundle for upgrade and not be stored in the claim anymore. * Carolyn add non-normative section to use outputs as state as well (instead of custom). * Jacob: Can we remove the rest of non-declarative info from the claim so that we can make an index on the claim? Hard to do that now properly because of previous action, underway status, etc. * Yes! πŸ’― * Jacob will open PR to move outputs of claims * Carolyn will open PR to split claim into claim (declarative) + audit log with the result of previous actions * Mounting the previous bundle on upgrade actions * Mount a directory of claims/revision by uuid? * Last sucessful claim mounted only is easiest for now until we have a use case * Is there value in being able to restart an action using the last failed claim, e.g. repeating a failed upgrade and getting back the state/claim from that failed upgrade so that it can start from where it left off or clean up? * Possible answer is that tools solve this and can pass in a different claim. * Call to vote on new version of CNAB Core 1.0.1 * This would be a patch bump of the spec * Errata is for spelling and grammar * master is a draft, a pit for us to review not an immediate version bump - so say we all ## Jan. 15 - Security and Registry Meeting | | | | -------- | -------- | | Recording | https://youtu.be/VwwJ8lYVIFM | | Attending | Radu Matei, Matt Butcher, Chris Crone, Trishank Karthik Kuppusamy, Karen Chu | | Note Taker | Trishank Karthik Kuppusamy | ### Agenda - Bundle formats as part of the core spec and relationship to registries and security (https://github.com/cnabio/cnab-spec/blob/master/104-bundle-formats.md) - Notary V2 scenarios and requirements (https://github.com/SteveLasker/notary) - Walkthrough of security spec PRs: [#301](https://github.com/cnabio/cnab-spec/pull/281), [#302](https://github.com/cnabio/cnab-spec/pull/282), and [#303](https://github.com/cnabio/cnab-spec/pull/280) - Moving security implementations into `github.com/cnabio` and discuss next steps ### Notes - Bundle formats - Radu: clarify in Slack - Matt: can we have a formal process where someone like myself can verify and vouch that CNAB-Sec is compliant with CNAB-Core? - We can keep the process light by nominating one person in a team to make sure their changes are interoperable with other teams - PRs - Let's get 301-304 reviewed and merged as first _working draft_ - Trishank will circle back to 300 later - Matt, Chris, and others will review in the next 1-2 weeks - Radu and Trishank should make as much progress as possible with 300 in the same time frame - People are not likely to read external specs, so let's try to explain as much as possible - Notary v2 - Radu will track their work to see how it will impact us in the future - CNAB-Sec 1.0 will target Notary v1 - CNAB-Sec 2.0 might target Notary v2 - Trishank: add uses cases to Notary v2 (note to self) - Implementations - Can we vote to move signy (Go) and pysigny (Python) to cnabio? - Chris: we should merge them so that they are visible - Radu: Go version is more advanced than Python right now, and the README makes clearly we are still in WD - Action items: we should start testing whether signy works with duffle / cnab-go - Transfer knowledge of Datadog use cases to signy and also Notary v2 ## Jan. 8 - General Meeting | | | | -------- | -------- | | Recording | https://youtu.be/bsDOqRCzhzM | | Attending | Ralph Squillace, Radu Matei, Matt Butcher, Chris Crone, Trishank Karthik Kuppusamy, Carolyn Van Slyck, Silvin Lubecki, Jacob LeGrone, Vaughn Dice | | Note Taker | Radu M | ### Agenda - Add Silvin as maintainer on Spec repo (Matt Butcher) - _Stable_ working draft for CNAB Security and Distribution (when ready) vs. 1.0, considering upcoming changes with OCI Artifacts and Notary v2 (Radu M) - Move other repositories (e.g. `signy`, `cnab-to-oci`) under github.com/cnabio (Radu M) - Please review the latest PRs on the security and claim specifications (https://github.com/cnabio/cnab-spec/pulls) (Radu M) - Common repository for `cnab-to-oci` C bindings? (Rust and Python bindings in progress) (Radu M) - Claims spec process to completion (Matt Butcher) - Update on MS usage of CNAB and Porter (Matt Butcher) - Should we parse digest from the `image` field? https://github.com/cnabio/cnab-go/pull/166 (Jacob) -- see also https://github.com/cnabio/cnab-spec/issues/287 - Anyone working on a distributed claim store? (Chris) ### Notes - Add Silvin as maintainer on Spec repo - we voted last November to add him, but the configuration to the repo was not added - Stable draft vs. 1.0 for security and registry - Chris: if we wait for registries to support new versions, it might take a long time. Notary work is unknown at this point. - Trishank: not sure if there will be incompatible changes for Notary, so we don't know at this point. We should release a 1.0 with the stable draft, then update if / when new versions are supported. - Matt: do we anticipate changes to the core spec? - Radu: we could end up with different versions - Chris: I worry that if we don't cut versions, people trying to adopt will be deterred because they will think we don't have stable versions. - move other repos to `cnabio` - Matt: switch to DCO for all repos (JDF) - Chris: `cnab-to-oci` has to go through legal first, but it needs to vetted first - Matt: we should also move `signy` to have an _official_ implementation for security as well - there might be a change to the core spec that would require an errata - claims spec - Matt: I would like to push the claims spec to completion spec, as multiple tools use it already - Matt: there is an outstanding requirement to change `name` to `installation` that might break existing tools. - Matt: strive to have the claims spec in a stable draft by end of February - Ralph: does the spec have any statement that would prevent storing state in claims, or does it need changes? - Matt: we have a statement that would allow an opaque data storage for systems like Terraform - Carolyn: have we been thinking about tracking the actions that have been performed on a bundle besides the last one, like an audit operation? - Matt: I don't think there is anything specific on it, I will look at it carefully - but because a claim has a name and revision ID, it should be trivial to retrieve all claims related to a bundle - Carolyn: distinction between something we implement vs. something required of all tools - Jacob: I have been working on an API that queries all claims for a specific bundle - Chris: Jacob, could you share that API? It is something that Docker App also needs to solve - Jacob: I would like to switch the API to protobuf and at least share the proto - I want to open source it, it might take some time - Carolyn: is it for claim storage? - Jacob: the API handles installations and internal workflows, for storing, querying, distributing instalations - Carolyn: I've been working on a plugin for claims backends for tools (Porter, Duffle) to use and store claims in backends - it would be nice to collaborate - Jacob: I could do a demo (add as agenda) - Matt: if there are changes required in the claim spec to enable distributed claim stores, please - Jacob: add an identity to claims for audit purposes - we explicitly stated that we don't handle this in claims right now, but this might be required, as we're currently storing that outside the claim - Matt: could you open an issue for this? This will end up being required most probably. - update on MSFT usage of CNAB and Azure examples - Ralph was supposed to present this (existing Azure examples have been migrated to CNAB, and the Azure Docs team started implemented bundles) - Should we parse digest from the `image` field? https://github.com/cnabio/cnab-go/pull/166 (Jacob) - Jacob: context in PR linked above, more opinions are very helpful here. The PR introduces a `Digest()` function for images - should the method return the content digest, return it only if it was added in the bundle, or return it from the image - Jacob: there is also a question of what the content digest is in the context of Docker images - please check the discussion and comment. - Matt: we should re-document and add this again on the agenda for next time. ## Dec. 11 Agenda - General Meeting | | | | -------- | -------- | | Recording | https://www.youtube.com/watch?v=947TG3yDogw | | Attending | Matt Butcher, Radu Matei, Silvin Lubecki, Glyn Normington, Vaughn Dice, Karen Chu, Jacob LeGrone, Chris G, Ralph Squillace | | Note Taker | Matt Butcher | ### Agenda - Intros and Announcements - Demos - Status on Claims spec (Butcher) - This needs one more review: https://github.com/cnabio/cnab-spec/pull/295 - A claim should have a reference to the bundle https://github.com/cnabio/cnab-spec/issues/297 - Upgrade action should mount the previous bundle https://github.com/cnabio/cnab-spec/issues/296 - Clarify terminology: https://github.com/cnabio/cnab-spec/issues/298 - Status on Security and Registry specs - Coordination: Are there any release announcements in the next 2 months? (Butcher) - Holiday Schedule ### Notes: - Demos - Notes: Radu shows generating Rust bindings for OCI registries pulls by bridging Go (via CGO) and Rust (via bindgen) and dynamically loading the library. His demo showed pulling a CNAB bundle.json from Rust using this. - Q (Jacob): Did we talk about storing the bundle.json itself instead of a pointer to a blob? - A (Radu): I think CNAB-to-OCI used to do this, but we lost the content digest when we did that because we don't know how the registry will store it - Q (Glyn): It may be worth wrapping the unsafe, bindgen-generated interface to cnab-go in rich Rust types. - A (Radu): Yes, this demo was just getting a simple case working. - Q (Glyn): Is the Go runtime loaded each time? - A (Radu): Not sure, but probably - Q (Jacov): do people want to see a demo of how we use bazel to construct the digests prior to pushing? - A (Glyn): it's likely that you have an unintentional expectation that docker compression will remain the same, so look out for that - A (Radu): love to see Jacob's demo however - Q (Radu): How do we package shared objects in binary releases? - A (): - Status of Claims Spec - #295 needs another lgtm - #296, #297 Butcher to take another pass at them - Some verbiage still needs clarification - Next meeting would be great to lock this small spec area down; really only tidying is required - Anything else should be in here? - Q (jacob): what is your definition of a release? - A: an installation of a claim; an ugrade is a "release" of an installation, but releases aren't tracked in the spec but installations are. The language got muddied; perhaps we just eliminate one term altogether. Jacob: I think we just need "installation" and not release. Agreement: Butcher/Glyn. don't want confusion with things like helm, too. - Jacob: PR for cnab-go that just needs a review: #165 - Radu: Do we want to change the import paths for cnab-go and duffle? - A: Jacob: I updated for cnab-go - A: Go ahead and upgrade duffle - Status of security spec - Ralph: Trishank is still strongly motivated to move it to completion - Radu: There is a Go implementation with CNAB-to-OCI and Notary. Started a Python implementation. The FFI work might also work with Python sharing with Rust(?). Technically, all the pieces are there and functional - Status of registry spec - OCI blocking issue #1: Index has no concept of a config object. No way to add a type to an index (e.g. a CNAB type) - OCI blocking issue #2: All images referenced in an index must be part of the same registry as the index. No way to include references to remote objects (e.g. like part of a different repo) - Issue is really storing multiple types in the same repository, not necessarily referencing external artifacts. The conversation in OCI is all wrapped up together. We don't need the external references, though... just multiple types in the same registry. - Discussion about cyclic dependencies, garbage collection re: external references - Any upcomming announcements? - No big ones - Holiday Schedule - Next meeting will be January 8, 2020 - Renaming libcnab-rust repo to cnab.rs - Add Jacob Legrone as a maintainer (Radu) - Create issues for the next three: - Then we can do the GitHub rename - Cut some releases - Add GitHub action for running tests ## **Nov. 13 Agenda - General Meeting** | | | | -------- | -------- | | Recording | https://youtu.be/aagxX3Qq1WI | | Attending | Matt Butcher, Carolyn Van Slyck, Jacob LeGrone, Karen Chu, Glyn Normington, Andrew Stringer, Radu Matei, Ralph Squillace, Vaughn Dice | | Note Taker | Carolyn | ### Agenda - Intros and Announcements - Demos? - The State of the Claims spec (Butcher) - libcnab-rust (Butcher) - [Make status.json a CNAB Output](https://github.com/deislabs/cnab-spec/pull/290) - CNAB Registries and CNAB Security (Radu M) ### Notes - The State of the Claims spec (Butcher) - Butcher takes the lead on getting the claims spec going again. - Sufficiently vague so that the tools can move around their home dirs without hating on the spec - libcnab-rust (Butcher) - restarted work on the Rust library - anyone opposed to having a full runtime in Rust? - Suggestion to split out library and client/runtime so that people can consume it like we do cnab-go - Ruffles repo! - Need integration tests across both to ensure we have the same outputs - [Make status.json a CNAB Output](https://github.com/deislabs/cnab-spec/pull/290) - Hearty πŸ‘ all around - Security Spec Update - Spec: working on recommendations - Need people who know python to help with implementation