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.

Share your screen. It is helpful for the facilitator to open this document and share their screen so that everyone can follow along.
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, the company you work for.
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.

July 25, 2023 (Cancelled)

July 11, 2023 (Cancelled)

June 27, 2023 (Cancelled)

Attendees

Please sign yourselves in:

< Name, pronouns, company, timezone>

May 16, 2023

Attendees

Please sign yourselves in:

< Name, pronouns, 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
- 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, company, timezone>
Billy Lynch, he/him, Chainguard, EST
Vincent Demeester, he/him, Red Hat, CEST

Agenda:

(Chitrang) Discuss Build Type
- 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, 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.
- 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, company, timezone>

Agenda:

CANCELLED - NO AGENDA

Mar 21, 2023

Attendees

Please sign yourselves in:

< Name, pronouns, 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 (presented to CDF TOC)
- CDF TOC Meeting - March 14, 2023 recording
- [billy] open questions around artifacts and addressing gaps around type hinting
  - Feature: Task provenance output #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

Mar 7, 2023

Attendees

Please sign yourselves in:

< Name, pronouns, 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:

// 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, 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

Jan 24, 2023

Attendees

Please sign yourselves in:

< Name, pronouns, 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
    - 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, 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, company, timezone>

Agenda:

Nov 29, 2022

Attendees

Please sign yourselves in:

< Name, pronouns, 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 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, 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
  - 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, 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, 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.
  - Billy: SGTM - I think this was always the plan (esp w/ Hub). Likely weren't going to have Chains produce a SLSA 3 VSA 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

Notes

October 18, 2022

Attendees

Please sign yourselves in:

< Name, pronouns, 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/

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`	在筆記中貼入程式碼
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.

Tekton Software Supply Chain Security (s3c) Working Group

Facilitators:

Facilitator instructions

July 25, 2023 (Cancelled)

July 11, 2023 (Cancelled)

June 27, 2023 (Cancelled)

Attendees

May 16, 2023

Attendees

Agenda:

May 2, 2023

Attendees

Agenda:

Apr 18, 2023

Attendees

Agenda:

Apr 4, 2023

Attendees

Agenda:

Mar 21, 2023

Attendees

Agenda:

Mar 7, 2023

Attendees

Agenda:

Feb 21, 2023

Attendees

Agenda:

Jan 24, 2023

Attendees

Agenda:

Jan 11, 2023

Attendees

Agenda:

Dec 13, 2022 (Cancelled)

Attendees

Agenda:

Nov 29, 2022

Attendees

Agenda:

Notes

Nov 15, 2022

Attendees

Agenda:

Notes

Nov 1, 2022

Attendees

Agenda:

Notes

October 18, 2022

Attendees

Agenda:

Notes

September 20, 2022

Attendees

Agenda:

Notes

September 6, 2022

Attendees

Notes

August 23, 2022

Attendees

Agenda:

Notes

August 9, 2022

Attendees

Agenda:

Notes

July 26, 2022

Attendees

Agenda:

July 12, 2022

Attendees

Agenda:

Notes

June 28, 2022

Attendees

Notes

Agenda:

June 14, 2022