owned this note
owned this note
Published
Linked with GitHub
# Tekton Software Supply Chain Security (s3c) Working Group
Facilitator rotation:
* Apr 4, 2023: Yongxuan Zhang
* Apr 18, 2023: Prakash Jagatheesan
* May 2, 2023: Billy Lynch
* May 16, 2023: Chuang Wang
* May 30, 2023: Yongxuan Zhang
* June 13, 2023: Prakash Jagatheesan
* June 27, 2023: Chuang Wang
* July 11, 2023: Billy Lynch
* July 25, 2023: Yongxuan Zhang
* August 8, 2023: Prakash Jagatheesan
* August 22, 2023: Billy Lynch
* September 5, 2023: Chuang Wang
* September 19, 2023: Yongxuan Zhang
### Facilitators:
- Billy Lynch
- Yongxuan Zhang
- Prakash Jagatheesan
- Chuang Wang
## Facilitator instructions
_Note that recording will start automatically._
1. Share your screen. It is helpful for the facilitator to open this document and share their screen so that everyone can follow along.
1. Introduce yourself. Not all of the attendees (or folks watching the recording) may know you, so say a few words about who you are, for example: your name, [your pronouns](https://www.amnestyusa.org/pdfs/AIUSA_Pride2015Pronouns.pdf), the company you work for.
1. Invite everyone to fill in the attendee list. This is completely optional but can be useful in getting a sense of who is invested in what, and makes it easier to address other attendees in the meeting.
<!-- TEMPLATE
## DATE
### Attendees
Please sign yourselves in:
* < Name, [pronouns](https://www.amnestyusa.org/pdfs/AIUSA_Pride2015Pronouns.pdf), company, timezone>
### Agenda:
-
---
-->
## July 25, 2023 (Cancelled)
## July 11, 2023 (Cancelled)
## June 27, 2023 (Cancelled)
### Attendees
Please sign yourselves in:
* < Name, [pronouns](https://www.amnestyusa.org/pdfs/AIUSA_Pride2015Pronouns.pdf), company, timezone>
---
## May 16, 2023
### Attendees
Please sign yourselves in:
* < Name, [pronouns](https://www.amnestyusa.org/pdfs/AIUSA_Pride2015Pronouns.pdf), company, timezone>
* Chitrang Patel, he/him, Google, EST
* Chuang Wang, he/him, Google, EST
* Luiz Carvalho, he/him, Red Hat, EST
### Agenda:
- (Chitrang) Discuss [Build Type](https://docs.google.com/document/d/1ewqtPXyg_y3MmU6Tc6l1X8nfzjt0AJHlP6VOnFsGNpQ/edit?pli=1#)
- Resolve naming of resolved dependencies.
- Ability to identify where the top level config (pipeline.yaml/task.yaml) came from. (@chitrang)
- original thought: config/pipeline, config/task. The reason is that there are other types of artifacts other than config i.e. images
- the importance of the name: ability to identify which one is the top level config.
- billy: stay in line with Tekton API path name i.e. remove `config/` prefix?
- Ability to identify which step used which image? (@luiz??) -- This will create multiple resolved dependencies for same images used in multiple steps but that should be ok.
- one entry if two images have same uri and same digest even if they are used in different steps.
- two entries if two images are resolved to different digests.
- Add top level pipelineSpec/taskSpec if fetch from remote resolution into resolved dependencies like we do with results in byproducts. (@luiz??)
- xx
- (Luiz) Use Case I
Verify an image was built from a PipelineRun that included the task buildah.
A. The task came from a Tekton Bundle.
B. The Tekton Bundle used came from a certain OCI repository.
C. The image used in the steps of the task came from a certain OCI repository.
D. The task was called with the expected parameters.
E. The task emitted the expected result. Why? Because I want to ensure the image digest
matches the image I'm verifying. This prevents an impostor task.
In v0.2, this can all be verified via the .predicate.buildConfig.tasks attribute. Simply
find the task that has the .ref.name set to "buildah".
In the proposed v1.0, the information is scattered across different attributes and external services.
Assuming the in-lined pipeline spec:
To fulfill A,
- find the buildah task in the pipeline definition under .predicate.buildDefinition.externalParameters.configSpec
To fulfill B,
- find the buildah task in the pipeline definition under .predicate.buildDefinition.externalParameters.configSpec
- find the tekton bundle used by the buildah task
To fulfill C,
- Find the buildah entry in resolvedDependencies[] - is this possible? deterministic?
- Match the .uri attribute of the resolved dependency with expected OCI registry
To fulfill D,
- find the buildah task in the pipeline definition under .predicate.buildDefinition.externalParameters.configSpec
- find the params used for the buildah task. NOTE: If it's a default parameter, additional work is needed.
To fulfill E,
- not possible
- workaround: surface results to the pipelinerun then look for them in .predicate.runDetails.byproducts.
Pipeline definition must be consulted to ensure the result came from the expected task - and not an impostor.
NOTE: If an in-lined pipeline spec is not provided, then it must be fetched provided the reference in
configRef.
---
## May 2, 2023
### Attendees
Please sign yourselves in:
* < Name, [pronouns](https://www.amnestyusa.org/pdfs/AIUSA_Pride2015Pronouns.pdf), company, timezone>
* Billy Lynch, he/him, Chainguard, EST
* Vincent Demeester, he/him, Red Hat, CEST
### Agenda:
- (Chitrang) Discuss [Build Type](https://docs.google.com/document/d/1ewqtPXyg_y3MmU6Tc6l1X8nfzjt0AJHlP6VOnFsGNpQ/edit?pli=1#)
- Go through the comments to wrap up discussion and agree upon the build type (if we can do that today :) )
- Internal vs External parameters
- Billy: would prefer if we didn't make a distinction, since we are acting on the Tekton API, and we don't know about layers on top of it. If providers want to enforce those restrictions then they should probably be enforced on the Pipeline API (i.e. via admission controller)
- Vincent: Use case for incl service account name?
- Completeness + reproducability
- Billy: Should we just have a single spec field?
- Chitrang: SGTM
- Do we include volume information?
- Billy: Sounds similar to provenance, may be able to put it in run metadata?
- Type annotations in resolved dependencies?
- Billy: not sure if we need it right now. probably omit it for now and can add it later
- Other approaches before have been to use the resolved dependencies as a k/v map
- e.g. find pipeline in spec, match to resolved deps.
- Chitrang: can we prepend pipeline / task to the names
- SGTM
- Adding fields to RunMetadata?
- Billy: I think we can add to anything - SLSA spec is more minimum requirements, and we can add fields as we need.
- Vincent: What are inputs?
- Chitrang: Input provenance, based on type hinting (and probably additional provenance/artifact data in pipelines in the future).
---
## Apr 18, 2023
### Attendees
Please sign yourselves in:
* < Name, [pronouns](https://www.amnestyusa.org/pdfs/AIUSA_Pride2015Pronouns.pdf), company, timezone>
* Billy Lynch, he/him, Chainguard, EST
* Al Huizenga, he/him, Google, EST
* Chitrang Patel, he/him, Google, EST
* Chuang Wang, he/him, Google, EST
### Agenda:
- (Billy) https://github.com/tektoncd/pipeline/pull/6539#discussion_r1167045120
- Current assumption is Spire requires use of hostPath or privileged.
- Prevents usage of restricted pod security standards, possibly sandboxing.
- [Reached out to Spire slack for help](https://spiffe.slack.com/archives/CBNCC2V17/p1681827980132159).
- Contingencies?
- Billy talking to the SPIRE folks on how we can run the agents in non-privileged mode w/o hostpath.
-
- (Al) Chains Beta announcement?
- Going to Beta for CDCon in a month's time
- Backwards compatibility of libraries before GA/Beta.
- Billy needs assistance to resolve the compatibility issues before Beta/GA.
-
---
## Apr 4, 2023
### Attendees
Please sign yourselves in:
* < Name, [pronouns](https://www.amnestyusa.org/pdfs/AIUSA_Pride2015Pronouns.pdf), company, timezone>
### Agenda:
* CANCELLED - NO AGENDA
## Mar 21, 2023
### Attendees
Please sign yourselves in:
* < Name, [pronouns](https://www.amnestyusa.org/pdfs/AIUSA_Pride2015Pronouns.pdf), company, timezone>
* Christie Warwick, she/her, Google, PST
* Billy Lynch, he/him, Chainguard, EST
* Chuang Wang, he/him, Google, EST
### Agenda:
- [christie] [Secure Supply Chain slides](https://docs.google.com/presentation/d/158xZuJibd77wwVmpA8GeuvaBvuAf3EJHQeVE_HtZLiM/edit#slide=id.g2192a55f614_0_51) (presented to [CDF TOC](https://docs.google.com/document/d/1uBHar55fTInWF9Li4t0lyG3tTC8BRLU0FfBfsgk_Jrs/edit#bookmark=id.5c48bo9a5zeb))
- [CDF TOC Meeting - March 14, 2023 recording](https://www.youtube.com/watch?v=QFZPKoHgtDw)
- [billy] open questions around artifacts and addressing gaps around type hinting
- [Feature: Task provenance output #6326](https://github.com/tektoncd/pipeline/issues/6326)
- Artifacts dicussions: what are inputs/outputs, how do we define them
- Can do something less invasive and easier to ship in the short term
- Provenance section in status in TaskRun/PipelineRun
- use this field for other structured status information
- Results today: write to a pre-defined path, same mechanism for structured provenance
- user that wants to use the Task doesn't need to worry about it
- Issues with current type hinting:
- Variable number of artifacts with type hinting (doesnt support )
- User needs to know
- Users don't need to do any extra actions?
- Task authors need to know about this
- How would this work at the pipeline level?
- Would users need to wire together values?
- Pipelines controller or Chains controller could take care of this?
- Pipelines controller would populate taskrun status in the same mechanism as results (? Christie thinks)
- e.g. Pipeline w/ git clone and kaniko
- git clone taskrun: would declare params, results, and provenance
- [christie] example could really help, pipeline with clone and build
- Action: Billy to create example
- [Yongxuan] If we import a library, and according to the license it needs to copy code into third_party folder. What should we do if it breaks our ci?
- For example, currently we don't force the update of vendor licenses. And in thie PR https://github.com/tektoncd/pipeline/pull/6342 Lee tries to add the check. However, we got CodeQL errors.
- Some background: https://github.com/tektoncd/pipeline/issues/6015
- Is third_party used for anything besides licenses?
- vendor folder still contains this information and is included in image, should meet license requirements
- including the vendor folder would impact image size (only 11 mb) <-- we do this already anyway
- Action: Yongxuan to bring up in Pipelines working group
- [billy] [Imposter Git commits can be fetched via authenticated remote resolution #6315](https://github.com/tektoncd/pipeline/issues/6315)
---
## Mar 7, 2023
### Attendees
Please sign yourselves in:
* < Name, [pronouns](https://www.amnestyusa.org/pdfs/AIUSA_Pride2015Pronouns.pdf), company, timezone>
* Billy Lynch, he/him, Chainguard, EST
* Andrea Frittoli, he/him, IBM, UTC
* Chitrang Patel, he/him, Google, EST
### Agenda:
- [Chuang]: SLSA v1 release candidate: https://slsa.dev/blog/2023/02/slsa-v1-rc
- Billy: I think we're mostly okay (no blockers).
- Luiz raised a concern about result values, but it seemed like SLSA team seemed okay with adding values - https://github.com/slsa-framework/slsa/issues/649
- Chitrang - How do we capture Run specs that don't use refs?
- Probably worth bringing out with SLSA team.
- Worst case we don't *have* to generate provenance if no config ref is given.
- Chitrang to raise an issue on the SLSA repo.
- https://github.com/slsa-framework/slsa/issues/669
- [Yongxuan]:
- https://github.com/tektoncd/community/pull/949 discussions and alignments
- Background: this PR mainly proposes 3 changes we have discussed before:
- Add a `mode` field into verification policy, value can be set to warn or enforce, controls whether we fail the run or not when fails verification
- Add condition with reason,message when the verification passes or fails
- Billy: Might want to call out what happens to ConditionSucceed for causing Runs to fail, but otherwise LGTM!
- Andrea: NIT, maybe call the condition "Verification" instead of "ConditionVerification"
- Yongxuan: Sure! I can update the tep
- Change the feature flag to `verification-no-match-policy`, can be set to allow, warn, deny. This controls the behaviour of the case when no matching policies for a resource.
- Billy: LGTM. We should follow up with Christie and maybe set up a one-off to figure out naming.
- Condition sample:
```go
// pass verification
apis.Condition{
Type: ConditionVerification,
Status: corev1.ConditionTrue,
Reason: podconvert.ReasonResourceVerificationSuccess
Message: "Trusted resource verification passed",
}
// fail verification
apis.Condition{
Type: ConditionVerification,
Status: corev1.ConditionFalse,
Reason: podconvert.ReasonResourceVerificationFailed
Message: "", //filled with error message,
}
```
- chuang: (if time allows) any feedback on the provenance field in run status
- https://github.com/tektoncd/pipeline/issues/6309
- We're already using this in chains and it's a backwards compatible change. Let's do it!
---
## Feb 21, 2023
### Attendees
Please sign yourselves in:
* < Name, [pronouns](https://www.amnestyusa.org/pdfs/AIUSA_Pride2015Pronouns.pdf), company, timezone>
* Christie Warwick, she/her, Google, PST
* Billy Lynch, he/him, Chainguard, EST
* Prakash Jagatheesan, he/him, Google, EST
* Chitrang Patel, he/him, Google, EST
### Agenda:
- [Yongxuan] Trusted Resources feature flag and policy Discussion (https://github.com/tektoncd/community/pull/949#issuecomment-1435240228)
Background: currently if no polices matched for a task, it will fail. We want to allow a case which users could use a mixed of signeds tasks and unsigned tasks.
1. adding a mode field to VerificationPolicy to control allow/warn behavior rather than having a global config map value.
2. Modifying `resources-verification-mode` to specify the action to take if no policy matches (we may rename this to make the behavior clearer). For example, policy controller names it as `no-match-policy`
- Currently our feature flag basicaly decides whether we enable this feature or not. Maybe we could have a feature flag to set it on/off, and another configmap to set the 'no-match-policy'.
* Similar to pod security policies, so should be easier for users to understand. (Billy)
* Currently it is enforce, warn modes, would we need skip? Warn logs, should we add status (Yongxuan)
* Kubernetes status for storing the verification(warn/ enforce) status - Billy
* alt - k8s events https://kubernetes.io/docs/reference/kubernetes-api/cluster-resources/event-v1/
* (Christie) - Add just warn and enforce and we can decide on skip later.
* (billy) - Policy controller can have and/or. And individual policies and or the results?
* https://github.com/sigstore/policy-controller#admission-of-images
* Changing existing flag
* [technically need 1 release of notice](https://github.com/tektoncd/pipeline/blob/main/api_compatibility_policy.md#alpha-features)
## Jan 24, 2023
### Attendees
Please sign yourselves in:
* < Name, [pronouns](https://www.amnestyusa.org/pdfs/AIUSA_Pride2015Pronouns.pdf), company, timezone>
* Christie Warwick (Wilson), she/her, Google, PST
* Andrea Frittoli, he/him, IBM, UTC
* Yongxuan Zhang, he/him, Google, EST
* Prakash Jagatheesan, he/him, Google, EST
### Agenda:
* [Yongxuan] Discuss trusted resources future work:
* https://github.com/tektoncd/pipeline/issues/5980
* Taskrun/Pipelinerun status updates upon verification fail/pass
* e.g. add a new field in [pr status](https://github.com/tektoncd/pipeline/blob/6db52ca0c2de48063f4f8a31fea131d72449676e/pkg/apis/pipeline/v1beta1/pipelinerun_types.go#L418)
* Add another reason instead?
* Need something to implement warn mode, also to have a field to affirm that verfication has succeed
* Options:
* annotation <-- can be a good way to prototype and promote later?
* New condition <-- should be able to add via Knative API easily
* ~~New status~~
* (billy) - I was thinking of condition, so this might be the same as above?
* New field in the status <-- probably not what we want since we already have a place for this info (status/condition)
* We may need something like spire to prove the verification.
* i.e. we need a way for chains and other verifiers to double check the verification later on.
* through doing the checksum itself and/or knowing that SPIRE ensured the status is legit
* trust but verify
* (andrea) how is this supposed to be used? by consumers of artifacts?
* (billy) being able to trust but verify seems generally good - being able to give users tool to double check and redo the verification client side if they don't want to trust / double check the evaluation of the tekton controller.
* if the Run fails, status should be failed - chains should also check this before signing provenance.
* VerificationPolicy controls whether the verification was actually executed; if not verifying, other tools may want to verify later
* Verification of API Task/Pipeline (esp when applied to the cluster)
* currently webhook for Task/Pipeline cannot list verification policies
* ideas:
* use config map (deprecated)
* convert CRD into a config map in the controller (i.e. similar to sigstore/policy-controller)
* Why is working with configmaps is easier than configmaps?
* Easiest way would be to use a lister, but not sure if we can do this with the policies.
* CMs are just another CRD resource, so it's odd that CRDs would be a blocking factor here.
* Is this a knative-ism?
* Billy will see if he can find out from Ville/Hector
* Also can reach out on sigstore slack to Ville, he should know idiosyncracies
* https://sigstore.slack.com/archives/C03096V09F1/p1668530097890569
* Store signatures separately
* tekton cli can write signature in files
* trusted resources can resolve remote signatures
* options:
* VerificationPolicy could specify the source of the signature
* Params for Remote Resolver
* Probably need a mapping of remote types with where their signatures should be.
* e.g. git = file.yaml + file.yaml.sig
oci = signature layers
* For API types - we could always introduce a new CRD that maps signatures to CRD resources.
* Probably only for etcd resources - if you're using other storage type you should probably use something inline with that type.
* Semi-enforce mode
* only verify matched resources
* hesitant to support something where it would succeed by removing signatures
* could we make this part of the policies? (e.g. user designates which resources will be WARN vs ENFORCE)?
* Convert VerificationPolicy into configmap
* Verification of images/source code/dependency in Tasks
## Jan 11, 2023
### Attendees
Please sign yourselves in:
* < Name, [pronouns](https://www.amnestyusa.org/pdfs/AIUSA_Pride2015Pronouns.pdf), company, timezone>
* Christie Warwick, she/her, Google, PST
* Billy Lynch, he/him, Chainguard, EST
* Yongxuan Zhang, he/him, Google, EST
* Prakash Jagatheesan, he/him, Google, EST
### Agenda:
- (christie) SPIRE support next steps? (signing PipelineRuns and ResolutionRequests)
- https://github.com/tektoncd/community/blob/main/teps/0089-nonfalsifiable-provenance-support.md#implementation-plan
- Next steps:
- Add chains verification (before adding for more types)
- Currently: TaskRun will succeed even if verification fails
- Any discussion around actually failing in this case? (simpler for users)
- Attacks are out of band for controller - e.g. after the successful completion
- Would be able to detect changes if you check the signature
- Maybe can add this later
- Chains implemetnation exists but PR is out of date and not yet merged
- https://github.com/tektoncd/pipeline/pull/5715 (follow up with @jagathprakash)
- Broken into a couple of smaller PRs, starting with https://github.com/tektoncd/pipeline/pull/5902
- @jagathprakash will provide walkthroughs as other PRs are added
- How do ResolutionRequest fit in?
- Assuming we want to sign status of all CRDs we assume Tekton controllers are relying on
- Can Trusted Tasks solve this so we don't need to sign
- ResolutionRequest populates CRD with Pipeline/Task content and includes signature of the Task/Pipeline
- if Task/Pipeline is trusted, the signature will be included
- If data is tampered with, signature can be used
- In the end will still need trust policies around author, etc.
- But other fields in ResolutionRequest could be modified (e.g. redirect to another version of the Trusted Task)
- (christie) faciltiators: https://github.com/tektoncd/community/blob/main/working-groups.md#software-supply-chain-security-s3c
- New list:
- Christie
- Yongxuan
- Prakash
- Billy
- Also: send message to s3c slack (Yongxuan to ping the chat)
- (Yongxuan) trusted resource updates!
- https://github.com/tektoncd/pipeline/issues/5527 the features PRs all get merged thank you all for reviewing!
- Working on the todo list
- Preparing the e2e demo
- any suggestions?
- Could be cool to add blog post (if desired) https://tekton.dev/blog/
- Cloud native security con (Seattle)
## Dec 13, 2022 (Cancelled)
### Attendees
Please sign yourselves in:
* < Name, [pronouns](https://www.amnestyusa.org/pdfs/AIUSA_Pride2015Pronouns.pdf), company, timezone>
### Agenda:
-
---
## Nov 29, 2022
### Attendees
Please sign yourselves in:
* < Name, [pronouns](https://www.amnestyusa.org/pdfs/AIUSA_Pride2015Pronouns.pdf), company, timezone>
* Christie Warwick (Wilson), she/her, PST
* Billy Lynch, he/him, Chainguard, ET
* Chitrang Patel, he/him, Google, ET
* Andrea Frittoli, he/him, IBM, UTC
* Parth Patel, he/him, Kusari, ET
* Yongxuan Zhang, he/him, Google, ET
### Agenda:
- (chitrang) Rescoped and Renamed [TEP-0122](https://github.com/tektoncd/community/pull/820) since it was causing confusion with what the TEP was trying to achieve.
- Billy to take another look
- Some work already underway in chains to help make this easier https://github.com/tektoncd/chains/pull/603
- (Yongxuan) TEP 91: https://github.com/tektoncd/community/pull/830
- Implememtation https://github.com/tektoncd/pipeline/pull/5714 needs reviews
### Notes
-
## Nov 15, 2022
### Attendees
Please sign yourselves in:
* < Name, [pronouns](https://www.amnestyusa.org/pdfs/AIUSA_Pride2015Pronouns.pdf), company, timezone>
* Christie Warwick (Wilson), she/her, Google, PST
* Billy Lynch, he/him, Chainguard, ET
### Agenda:
- (billy) Deprecate workflow board in favor of simple agenda?
- (christie) I "closed" the project but not sure that actually changed anything XD
- (Yongxuan) some discussions of implementation details of verificationpoliy in tep91
- https://github.com/tektoncd/community/pull/830
- https://github.com/tektoncd/pipeline/pull/5714
- Policy Controller convert the crd to configmap https://github.com/sigstore/policy-controller/blob/ba6cdef1d82974440ea2eb23029fe6150bceb265/pkg/reconciler/clusterimagepolicy/clusterimagepolicy.go#L75-L105
- Policy controller (https://github.com/sigstore/policy-controller) verifies signatures w/in pod specs, etc. Similar to Kyverno, OPA
- What does the resource pattern correspond to?
- A: Resolver URL
- Does this mean that we need to go through resolvers for verification?
- Yes - we should figure out how to support API resolution but it's not a priority to start
- policy-controller let's you have multiple policies that you scope down, whereas impl right now
let's you scope different images within a single policy
- Having multiple instances = easier to share with ppl who want to use it (e.g. the catalog can drop in the corresponding verification policy)
- Wanted to be able to have different policies for different namespaces
- current impl uses namespaced resources - lookup policies in same namespace
- same for policy-controller
- Do we need a CRD or would a ConfigMap be enough? What do we get from having a CRD?
- Original design was ConfigMap, but having CRD = more control over validation, ConfigMap = just key/value prepares, easier to have the struct you're expecting and validate it i.e. a well defined interface for users
- CRD = more resource heavy?
- All just data in etcd anyway
- Shouldn't be a performance impact, no meaningful difference
- Sigstore policy controller -> converts CRD to configmap b/c want to do verification in webhook vs. reconciler (no access to lister)
- Reconciler for the items being verified
- Minimizing number of things to watch (kind of like a cache, instead of the lister)
- Using the Knative configmap watchers (but these exist for other resources)
- [Related Sigstore Slack thread](https://sigstore.slack.com/archives/C03096V09F1/p1668532635375079?thread_ts=1668530097.890569&cid=C03096V09F1)
- CRD = can apply different RBAC policies; configmap = need to grant for all configmaps or just a specific configmap, CRD = can control edit over all ValidationPolicies
- Pattern format
- Is in regex format
- Efficiency will depend on the order that the patterns are applied in
- Will we support very generic patterns like .*?
- Examples and use cases?
- Does VerificationPolicy support embedding public key directly?
- yes - via data field
- we also cache the secret directly in the data field
- Billy to ask in PR: what if the data changes?
- (Chuang Wang) minor point: (if time allows) config source for in-cluster resources
- 2 ways to use in-cluster resources: `taskRef.name` or `cluster resolver`.
### Notes
## Nov 1, 2022
### Attendees
Please sign yourselves in:
* < Name, [pronouns](https://www.amnestyusa.org/pdfs/AIUSA_Pride2015Pronouns.pdf), company, timezone>
* Billy Lynch, he/him, Chainguard, EST
### Agenda:
- how would someone take artificat hub and add signature?
- Artifact Hub showing "signed" icon
- LGTM! 🚢
- How we're doing signatures right now - signature annotation
- Billy: Do we want to use OCI/bundles so that we can attach additional signatures/attestations to the images?
- Quan: Tested this already works with cosign, but ArtifactHub needs a metadata file to link users to the image to use.
- We'd still want to sign/verify this to make sure users aren't redirected elsewhere.
- We can look into supporting OCI support later.
- Chuang: Source information for in-cluster resources or for the resources that are embedded in the in-cluster taskrun/pipelinerun.
- Embedded case:
- Billy: I am fine with leaving it empty.
- In-cluster case, 3 options:
- leave source information empty for in-cluster resources
- set the source information for in-cluster resource (uri: [api path](https://kubernetes.io/docs/reference/using-api/api-concepts/#resource-uris), digest: 256 checksum of the file)
- Billy: This is what we landed before.
- make it configurable by cluster operator
- Billy: It's possible, but I don't see any harm in populating the sha256 (as well as api path). It can at least tell/help verify if things have changed.
- Some thoughts from Christie: we might want to discourage using Task/Pipeline installed in a cluster in favor of having them stored in version control i.e. repository, oci bundle.
- Tasks and Pipelines living in the cluster wouldn’t meet SLSA L3 requirements for [build as code](https://slsa.dev/spec/v0.1/requirements#build-as-code).
- Billy: SGTM - I think this was always the plan (esp w/ Hub). Likely weren't going to have Chains produce a [SLSA 3 VSA](https://slsa.dev/verification_summary/v0.2) if we can't verify the provenance
- What if the cluster operator is concerned about exposing their cluster information through the cluster api path?
- Billy - I'm not too worried about this - if it's a relative path this would only expose the namespace / name. I think as long as we document this it will be fine, otherwise we can push people towards OCI/Git based configs which will solve this.
[Workflow discussion board](https://github.com/orgs/tektoncd/projects/14/views/1)
### Notes
## October 18, 2022
### Attendees
Please sign yourselves in:
* < Name, [pronouns](https://www.amnestyusa.org/pdfs/AIUSA_Pride2015Pronouns.pdf), company, timezone>
* Billy Lynch, he/him, Chainguard, EST
* Yongxuan Zhang, he/him, Google, EST
* Andrea Frittoli, he/him, IBM, UTC+1
* Jerop Kipruto, she/her, Google, UTC-4
* Quan Zhang, he/him, Google, UTC-4
### Agenda:
- Trusted resources signing&verification with tkn, Fulcio.
- signature layers of images, oci bundles tasks the same way
- how would someone take artificat hub and add signature?
- Artifact Hub showing "signed" icon: https://artifacthub.io/docs/topics/annotations/helm/
[Workflow discussion board](https://github.com/orgs/tektoncd/projects/14/views/1)
### Notes
## September 20, 2022
### Attendees
Please sign yourselves in:
* < Name, [pronouns](https://www.amnestyusa.org/pdfs/AIUSA_Pride2015Pronouns.pdf), company, timezone>
* John Calabrese, he/him, google, EST
* Chuang Wang, he/him, Google, EST
* Yongxuan Zhang, he/him, Google, EST
* Billy Lynch, he/him, Chainguard, EST
### Agenda:
- Billy: Administrivia: try to add agenda items ahead of the meeting! 🙏
- Billy: Looking for Pipeline owner to help be primary reviewer for future SPIFFE/SPIRE PRs.
- TEP-0084 POC
- Created issues in SLSA community re. getting clarity on some terminology
- TEP 109: storing schema files
- TEP-0086: Larger Results via Sidecar Logs- https://github.com/tektoncd/community/pull/745
- Chuang: https://github.com/tektoncd/pipeline/pull/5397#discussion_r974607056
- passing remote refs (confi source) via status.annotations.
- future: making provenance an actual field in Run status
[Workflow discussion board](https://github.com/orgs/tektoncd/projects/14/views/1)
### Notes
- TEP 84 almost merged YAYAYAYAYYAYA! :)
- tep 109 chains recognizes struct res... moving forward.
- tep 86 still has ongoing discussions: possibly we can have runs output artifacts.... Stay tuned, reach out to jerop for follow on meetings.
- https://github.com/tektoncd/community/blob/main/teps/0056-pipelines-in-pipelines.md#software-supply-chain-security
## September 6, 2022
### Attendees
Please sign yourselves in:
* < Name, [pronouns](https://www.amnestyusa.org/pdfs/AIUSA_Pride2015Pronouns.pdf), company, timezone>
* Andrea Frittoli, he/him, IBM, UTC+1
* Billy Lynch, he/him, Chainguard, UTC-4
### Notes
* Trusted resources https://github.com/tektoncd/community/pull/788
* Verify at webhook/reconciler or both?
* Verify local resources and oci bundles at webhook
* Verify all resources after resolution at reconciler
* Billy: want to be consistent with rest of remote resolution, don't want to special case API based tasks
* Since we probably can't ensure consistent behavior in remote resolution, just validate in reconciler. We can still validate CRDs as-is in webhook.
* Key discovery should be out-of-scope in first phase?
* Billy: Key discovery is a hard problem. +1 to starting off with a simple list of trusted keys.
* We might be able to do something more complex later for catalog (e.g. catalog adds attestations to tasks)
* Upgrading types in Tekton Pipelines to v1beta1 types
- when v1alpha1 types work, do we want to actively looking for upgrading them to v1beta1 types?
- https://github.com/tektoncd/chains/pull/540
- https://pkg.go.dev/github.com/tektoncd/pipeline/pkg/apis/pipeline/v1beta1#PipelineResourceType
- Chains technically still alpha - will define deprecation policy in push to beta (aiming ~3 months)
- Perhaps we should start deprecating this now though - follow up in chains WG
- Keep them in v1alpha1
- Followup in Tekton Pipelines WG
[Workflow discussion board](https://github.com/orgs/tektoncd/projects/14/views/1)
## August 23, 2022
### Attendees
Please sign yourselves in:
* < Name, [pronouns](https://www.amnestyusa.org/pdfs/AIUSA_Pride2015Pronouns.pdf), company, timezone>
* David Bendory, Google
* Yawen Luo, Google
* Yongxuan Zhang, Google
* Chuang Wang, Google
* Billy Lynch, Chainguard
* Priti Desai, IBM
* Andrea Frittoli, IBM
*
### Agenda:
- Facilitator volunteers?
- @ywluogg
- @Yongxuanzhang
- @chuangw6 (Chuang Wang)
### Notes
[Workflow discussion board](https://github.com/orgs/tektoncd/projects/14/views/1)
* [TEP 109](https://github.com/tektoncd/community/pull/792):
* Need approvals
* Future solution: having a field under status such as "artifacts" and let users write files to `tekton/artifacts/inputs` and `tekton/artifacts/outputs`
* **Looking for approvals**
*
* (Yongxuan):
* Some updates on: https://github.com/tektoncd/community/pull/788
* Store signature in annotation for now and in the future store it along with the resource as a separate file (may rely on remote resolution to resolve the signature as well)?
* Store pubkeys in a new CRD
* Skip mutating webhook via the feature flag, so this feature doesn't have impact on current resources
* Invoke remote resolution at validation webhook
## August 9, 2022
### Attendees
Please sign yourselves in:
* < Name, [pronouns](https://www.amnestyusa.org/pdfs/AIUSA_Pride2015Pronouns.pdf), company, timezone>
* Priti Desai, IBM, PST
### Agenda:
- https://github.com/tektoncd/community/pull/739
- (billy): there probably won't be much resistance to taking over the CLI TEP. Go with whatever is easiest for you for TEP-0091 - since this will likely be CLI plugin anyway, there won't be a hard dependency on tkn.
- Webhook vs Reconciler validation
- Don't want to duplicate efforts in webhook (also permissions)
- (billy): recoginize that we want to reuse remote resolution work. if we do validation at reconcile, we'll need to be very clear about the validation lifecycle, since once it's accepted by etcd other clients using informers will have access.
- safest thing is to block at admission, because downstream clients will never receive a message.
- (adam): Shipwright listens for TaskRuns directly
- Cosign/Sigstore dependencies - are these too much?
- (billy): Ongoing efforts in sigstore to separate core sigstore behavior out of cosign. Let me know if anything seems too heavy and we can look into breaking it out
### Notes
[Workflow discussion board](https://github.com/orgs/tektoncd/projects/14/views/1)
## July 26, 2022
### Attendees
Please sign yourselves in:
* < Name, [pronouns](https://www.amnestyusa.org/pdfs/AIUSA_Pride2015Pronouns.pdf), company, timezone
* Billy Lynch, he/him, Chainguard, EDT
* Andrea Frittoli, he/him, IBM, UTC+1
* Yawen Luo, she/her, Google, EST
* Chuang Wang, he/him, Google, EST
### Agenda:
- Whether Chains should have the features to check the correctness of artifact digest / whether artifact exists (https://github.com/tektoncd/chains/issues/485)
- GCP Artifact Registry:
- OCI images getting digests are different from packages
- Packages have a more universal way to get digests: through files API (https://cloud.google.com/artifact-registry/docs/reference/rest#rest-resource:-v1beta2.projects.locations.repositories.files)
- Packages need users to upload digest themselves
- Maven: upload digest file automatically
- Python: it doesn't. Need to `sha256sum` and upload the files together with wheels
- It sounds like we don't have a standard for artifacts across artifact storages
- We should avoid solutions that are vendor specific
- Distributed artifact trust: https://pyrsia.io/
- Alternative:
- Rely on trusted tasks instead
- We could have a new field in the attestation about "verified by the chains controller"
- Topic is not blocking for Yawen's work right now
- It makes sense to have a "builder version" in attestation
- We may have it today in SLSA spec
- https://github.com/slsa-framework/slsa/issues/384
- https://github.com/slsa-framework/slsa-proposals/blob/main/0002/README.md
- capture cases where there is a bug in the controller
## July 12, 2022
### Attendees
Please sign yourselves in:
* < Name, [pronouns](https://www.amnestyusa.org/pdfs/AIUSA_Pride2015Pronouns.pdf), company, timezone
* Billy Lynch, he/him, Chainguard, EDT
* Andrea Frittoli, he/him, IBM, UTC+1
* Yawen Luo, she/her, Google, EST
* Priti Desai, she/her, IBM, PST
### Agenda:
- Chains release schedule: release rotation; milestones
- Will follow up in the Chains WG
- Not against doing milestones, just hasn't been necessary given that there isn't the same amount of engagement with Chains as there is for Pipelines.
- Generally avoided granting release permissions to non-maintainers since it also grants release permissions for other project (e.g. pipelines)
- AI(Billy): regain release permissions and handle next Chains release.
- Whether Chains should have the features to check the correctness of artifact digest / whether artifact exists (https://github.com/tektoncd/chains/issues/485)
- Side affect of OCI is that it needs to exist in order for us to attach the attestation.
- PR wanted to add support for other artifact types (maven, pypi, etc.). It might be hard to generalize this for all package formats.
- For the PR primarily targetting Artifact Registry, so would likely need to verify separately
- Might be worth following up with the Sigstore packaging working group to see how they are approaching attaching attestations for different package types.
- AI(Billy): Follow up with packaging working group
- AI(Yawen): Double check with how maven authentication is done and if can be done in a general way.
- Trusted Resources also something we could lean on in the future once its ready.
### Notes
[Workflow discussion board](https://github.com/orgs/tektoncd/projects/14/views/1)
## June 28, 2022
### Attendees
Please sign yourselves in:
* < Name, [pronouns](https://www.amnestyusa.org/pdfs/AIUSA_Pride2015Pronouns.pdf), company, timezone>
* John Calabrese, he/him, Google, EST
* Billy Lynch, he/him, Chainguard, EST
* Priti Desai, she/her, IBM, PST
### Notes
[Workflow discussion board](https://github.com/orgs/tektoncd/projects/14/views/1)
#### Agenda:
* [Jerop] TEP-0086: Larger Results
* SBOM use case
* we need external storage (of some kind)
* anecdotally 1.5M def not enough
* proposal link: https://drive.google.com/file/d/14tDHNgpzOZ--5nMsOsTBhxsDgDDM_7iQ/view?t=1h01m41s
* PR #745 request for eyes
* Sidecar Logs
* GHA used to do log parsing for results - their logs got "fooled" into uploading something else
* https://github.com/actions/toolkit/security/advisories/GHSA-mfwh-5m23-j46w
* May want the references still - a couple hundred MBs (for one image) for K8s (but may be worst case)
* May be a progressive change: 4K to 1M
* Results vs Workspaces
* Artifacts - Using Types for now
* [Adam] Recording Network state on TaskRun
* can we do this?
* is this related to hermecton
* needs more info, defer to next time when adam is present
*
## June 14, 2022
### Attendees
Please sign yourselves in:
* < Name, [pronouns](https://www.amnestyusa.org/pdfs/AIUSA_Pride2015Pronouns.pdf), company, timezone>
* Yawen Luo, she/her, Google, EST
* Jason Hall, he/him, Chainguard, EST
* Billy Lynch, he/him, Chainguard, EST
* Andrea Frittoli, he/him, IBM, UTC+1
* David Bendory @ Google EST
* Jerop Kipruto, she/her, Google, EDT
### Notes
[Workflow discussion board](https://github.com/orgs/tektoncd/projects/14/views/1)
#### Agenda:
* [Yawen] Adding maven support in existing type hinting mechanismn: https://github.com/tektoncd/chains/issues/460
* [Billy] Sigstore working on signing Maven packages: https://github.com/sigstore/sigstore-maven
* TEP-109: https://github.com/tektoncd/community/pull/697
* targetting next release in August
* would be in Alpha at first
* fine having this as a working experiment in Alpha before depending on structured results
* let's not proliferate these since we know we want these based on structured results and not specially-named result names
* [Billy] [Pipelines SLSA Review](https://docs.google.com/document/d/1sJQHjH8ldodwy8WcMUVN-p4G3tCY6DFyE3M7Ik3PZck/edit#bookmark=id.1ewwml779qsm)
* Missing verified history to reach SLSA L3 in our own releases
* This [GitHub issue](https://github.com/tektoncd/plumbing/issues/1091) tracks the missing history
* [Jerop] TEP-0086: Larger Results
* SBOM use case
* Sidecar Logs
* GHA used to do log parsing for results - their logs got "fooled" into uploading something else
* https://github.com/actions/toolkit/security/advisories/GHSA-mfwh-5m23-j46w
* May want the references still - a couple hundred MBs (for one image) for K8s (but may be worst case)
* May be a progressive change: 4K to 1M
* Results vs Workspaces
* Artifacts
* Using Types - for now
---
## May 31, 2022
### Attendees
Please sign yourselves in:
* < Name, [pronouns](https://www.amnestyusa.org/pdfs/AIUSA_Pride2015Pronouns.pdf), company, timezone>
* Yawen Luo, she/her, Google, PST
* Adam Kaplan, he/him, Red Hat, EDT
* Billy Lynch, he/him, Chainguard, EDT
### Notes
[Workflow discussion board](https://github.com/orgs/tektoncd/projects/14/views/1)
#### Agenda:
- TEP 84: https://github.com/tektoncd/chains/pull/436
- (adambkaplan): Brief update on SLSA ["Build as Code" requirement](https://github.com/slsa-framework/slsa/issues/368)
- "Verifiably derived" build definitions include things like GitHub Actions YAML, Pipelines-as-code definitions, Tekton Bundles in an OCI artifact.
- (Yongxuanzhang): Trusted Task With Remote Resource Resolution
- Keep trusted tasks in webhook vs in remote resolution?
- (billy): We should look into what the future of taskRef is when Remote Resolution is GA - this might influence how we approach this.
- (billy): We probably want to keep some form of verification in webhooks, since we need to validate that the Remote Resolution ref itself hasn't been modified.
- (priti): Remote resolution isn't even beta yet, it may not make sense to bring in Remote resolution functionality into Pipelines for verification. Focus on current supported resources first, and add remote resolution behavior later?
- (wlynch): (discussion) Is it worth moving defaulting webhook behavior into the controller for spec stability?
- Has come up with Trusted Tasks, SPIRE/SPIFFE
- Mutating webhooks can invalidate and signatures. Should we move the behavior to the controller?
- (adam): What would this look like for the object- would we modify the spec or the status in the controller?
- (billy): probably the status and leave the spec unmodified, but we can figure out the exact details later.
- (priti): probably worth exploring alternatives (e.g. webhook self-signing it's own modifications)
- Billy to find SPIFFE/SPIRE thread detailing more
---
## May 17, 2022
### Attendees
Please sign yourselves in:
* < Name, [pronouns](https://www.amnestyusa.org/pdfs/AIUSA_Pride2015Pronouns.pdf), company, timezone>
* Yawen Luo, she / her, Google,
* Priti Desai, she/her, IBM, PST
### Notes
[Workflow discussion board](https://github.com/orgs/tektoncd/projects/14/views/1)
#### Agenda:
## May 3, 2022
### Attendees
Please sign yourselves in:
* Billy Lynch, he/him, Chainguard, ET
* Adam Kaplan, he/him, Red Hat, EDT
* Luiz Carvalho, he/him, Red Hat, EDT
* Yawen Luo, she/her, Google, EDT
* Andrea Frittoli, he/him, IBM, BST
* Yongxuan Zhang, he/him, Google, BST
* Chuang Wang, he/him, Google, PST
* < Name, [pronouns](https://www.amnestyusa.org/pdfs/AIUSA_Pride2015Pronouns.pdf), company, timezone>
*
### Notes
[Workflow discussion board](https://github.com/orgs/tektoncd/projects/14/views/1)
#### Agenda:
- TEP-0084
- TEP needs to made implementatable, but not blocking for POC/design discussion
- PipelineRun implementation of TEP-0084 without events is ok
- Related TEP
- TEP 75/76
- Enhamcement for the provenance but not blocking
- TEP Results Size
- Complement the provenance work but not blocking
- TEP-0086: https://github.com/tektoncd/community/pull/521
- TEP 0109: [Better structured provenance retrieval in Tekton Chains](https://github.com/tektoncd/community/pull/697)
- Should be TaskRun only or PipelineRun as well?
- It makes sense to apply both
- https://github.com/tektoncd/chains/pull/436 (Chains PipelineRun support)
- wlynch to take a look
- some questions on how to transform PipelineRuns -> intoto, will start discussion in #chains
- Q: are we meeting next time? (Kubecon EU)
- Let's check-in a week
- We can cancel if there is no agenda
-
## April 19, 2022
### Attendees
Please sign yourselves in:
* < Name, [pronouns](https://www.amnestyusa.org/pdfs/AIUSA_Pride2015Pronouns.pdf), company, timezone>
* Billy Lynch, he/him, Chainguard, EDT
* Chuang Wang, he/him, Google, PDT
### Notes
[Workflow discussion board](https://github.com/orgs/tektoncd/projects/14/views/1)
#### Agenda:
- None :)
## Apr 5, 2022
### Attendees
Please sign yourselves in:
* < Name, [pronouns](https://www.amnestyusa.org/pdfs/AIUSA_Pride2015Pronouns.pdf), company, timezone>
* john calabrese, he/him, Google, EDT
* Christie Wilson, she/her, Google, PDT
* Andrea Frittoli, he/him, IBM, BST
* Yawen Luo, she/her, Google, EDT
* Jerop Kipruto, she/her, Google, EAT
* Billy Lynch, he/him, Google, EDT
* Chuang Wang, he/him, Google, PDT
* Priti Desai, she/her, IBM, PST
### Notes
[Workflow discussion board](https://github.com/orgs/tektoncd/projects/14/views/1)
#### Agenda:
- prior action items
- this weeks topics
- s3c milestones discussion (https://github.com/orgs/tektoncd/projects/19/views/8)
- useful to add categorization: tekton IS SLSA x vs. tekton SUPPORTS SLSA x
- any other ad-hoc items people would like to discuss?
-
- thats a wrap
## Mar 22, 2022
[Recording](https://drive.google.com/file/d/1WcjxDzkgvWvy3bbNcQKUh0ZjsZUOzltJ/view?usp=sharing)
### Attendees
Please sign yourselves in:
* < Name, [pronouns](https://www.amnestyusa.org/pdfs/AIUSA_Pride2015Pronouns.pdf), company, timezone>
* Jason Hall, he/him, Red Hat, US Eastern
* Christie Wilson, she/her, Google, PST
* Billy Lynch, he/him, Google, US Eastern
* Jerop Kipruto, she/her, Google, EAT
* Yawen Luo, she/her, Google, EAT
* Priti Desai, she/her, IBM, PST
### Notes
[Workflow discussion board](https://github.com/orgs/tektoncd/projects/14/views/1)
[s3c milestones](https://github.com/orgs/tektoncd/projects/19)
- (Andrea) Cannot attent today due to a conflict)
- Based on the initial meeting I wanted to propose:
- Extend the WG to be 1h long
- Could dig into things in more detail
- Pipeline working group is right after this, would have to find a new time
- or alternatively to meet weekly instead of bi-weekly
- If weekly at current slot, conflicts with gov board
- Keep as an option, revisit (will need to find a new slot either way)
- Deep dives = could schedule one offs, if consistent can reschedule
- Any feedback on the [proposed WG Charter and Scope](https://hackmd.io/-fXxObGpRsCGjNeajgz9eA)?
- Need to identify core things we are trying to provide
- Two areas:
- Building s3c with Tekton
- s3c for Tekton itself
- Documenting specific features, more clarity around where this is provided
- e.g. a repo, documentation (e.g. how to configure Tekton best, what features to use)
- Only need new repo if specific feature that needs it
- Anything we need to add is added to existing projects (in cases we are currently aware of), e.g. triggers feature
- How much detail should scope/charter have, also have docs like:
- [SLSA case study](https://docs.google.com/document/d/12yYP0M_zz5Tc9ftGnLwhDZ_tdZBq4mEod70ngWtHmLs/edit#heading=h.9x3qzmpjptco)
- [roadmap brainstorm](https://hackmd.io/y76ulU0QTLKj8TfWhlFFRA)
- Can reference these from the scope doc
- Actions:
- Clear links to docs with more detail
- Clarity around whether this is a separate project or added to existing projects
- [SLSA case study](https://docs.google.com/document/d/12yYP0M_zz5Tc9ftGnLwhDZ_tdZBq4mEod70ngWtHmLs/edit#)
- Christie to add list of questions for SLSA community and share
- Best practices in s3c, e.g.:
- Keeping dependencies up to date - any reason we're not using dependabot?
- Chains uses dependabot, Billy planning to enable on results
- Probably just b/c we haven't done it
- Some rotation of ppl will need to deal with the resulting PRs
- Jason to bring this up in #plumbing
- Also need to keep other things up to date, e.g. Go version used to build
- Would be easy to setup GitHub Actions for this
- Chains currently using GitHub actions for kind based testing
- Has been possible to get this running on Tekton dogfooding as well
- https://github.com/nestybox/sysbox <-- claims to make it easier to run docker in docker
-
## Mar 8, 2022
### Attendees
Please sign yourselves in:
* < Name, [pronouns](https://www.amnestyusa.org/pdfs/AIUSA_Pride2015Pronouns.pdf), company, timezone>
* Jerop Kipruto, she/her, Google, EAT
* Billy Lynch, he/him, Google, ET
* Adam Kaplan, he/him, Red Hat, EST
* John Calabrese, he/him, Google, EST
* Christie Wilson, she/her, Google, PST
* Andrea Frittoli, he/him, IBM, UTC
* Priti Desai, she/her, IBM, PST
* Jason Hall, he/him, Red Hat, EST
### Notes
- [Workflow discussion board](https://github.com/orgs/tektoncd/projects/14/views/1)
- [S3C Milestones](https://github.com/orgs/tektoncd/projects/19/views/8)
* [roadmap brainstorm](https://hackmd.io/y76ulU0QTLKj8TfWhlFFRA)
* Commit to repo, maybe alongside charter that Andrea has drafted
* Milestone tracker
* https://github.com/orgs/tektoncd/projects/19/views/8
* can add anything here as notes that's not tracked yet in issues
* Credential management
* Number one question: how do I use Tekton with my private _GitHub repo_ (etc)
* Docs working group looking to create specific How-To documentation
* Looking for content creators
* Not sure if GKE workload identity docs belong at tekton.dev? (also EKS, GitHub, etc.)
* https://wlyn.ch/posts/gcp-tekton-workload-identity/
* Blog posts vs core docs
* Core docs neutral, blog posts can be more specific
* tekton.dev website template supports blogs
* Could also use something like medium with a set of admins
* sigstore uses this as well
* Working group scope and charter:
* https://hackmd.io/-fXxObGpRsCGjNeajgz9eA
## Feb 22, 2022
### Attendees
Please sign yourselves in:
* < Name, [pronouns](https://www.amnestyusa.org/pdfs/AIUSA_Pride2015Pronouns.pdf), company, timezone>
* Christie Wilson, she/her, Google, PST
* Vincent Demeester, he/him, Red Hat, CEST
* Adam Kaplan, he/him, Red Hat, EST
* John Calabrese, he/him, Google, EST
* Andrea Frittoli, he/him, IBM, UTC
* Shripad Nadgowda, he/him, IBM, EST
* Priti Desai, she/her, IBM, PST
* Jerop Kipruto, she/her, Google, EST
### Notes
[Workflow discussion board](https://github.com/orgs/tektoncd/projects/14/views/1)
* Start meeting with review of TEPs marked with area/s3c?
* Could also search across all repos
* Not clear how to do this search
* Need a project board to view these
* Action: Priti to look into creating a board
* Org wide search (thanks John) https://github.com/search?q=org%3Atektoncd+label%3Aarea%2Fs3c&type=issues
* Start with just community repo
* [roadmap brainstorm](https://hackmd.io/y76ulU0QTLKj8TfWhlFFRA?view)
* Keep as hackmd, TEP, board?
* Create issues for anything that doesn't have issues, maybe create
* Christie can add discussion items for missing pieces we don't yet have any TEPs/plans around
* Evaluation of SLSA levels and how we are meeting them
* Current list = just what we are missing, or comprehensive evaluation?
* Currently just what we're missing
* Christie planning to create case study to share with SLSA group
* Will share with this group for contributions
* Need a format to prioritize - big picture would help
* Isolation:
* Problematic PVC use
* Could use [ReadWriteOncePod](https://kubernetes.io/blog/2021/09/13/read-write-once-pod-access-mode-alpha/)
* v1
* Any of these blocking v1?
* Hopefully can keep somewhat separate, some TEPs may already be in v1 list
* Milestones for each SLSA level?
* Would need to be cross project
* Could do this with a project board
* John will experiment with a board for this [s3c milestone board](https://github.com/orgs/tektoncd/projects/19/views/8)
## Feb 8, 2022
[Recording](https://drive.google.com/file/d/1My3WHVUEm91z99odfXW1bLIsgKaVdji1/view?usp=sharing)
* [Workflow discussion board](https://github.com/orgs/tektoncd/projects/14/views/1)
* Discussed format for future meetings, faciltiator rotation
* [Seeding a roadmap brainstorm doc](https://hackmd.io/y76ulU0QTLKj8TfWhlFFRA)
## Notes template
### Attendees
Please sign yourselves in:
* < Name, [pronouns](https://www.amnestyusa.org/pdfs/AIUSA_Pride2015Pronouns.pdf), company, timezone>
*
### Notes
[Workflow discussion board](https://github.com/orgs/tektoncd/projects/14/views/1)
Google Drive
Gist
Clipboard
Sign in with Wallet
