editorial: Clarify language in VSA spec #882

kpk47 · 2023-06-09T22:50:35Z

Explain the VSA's core assertion.
Update the introduction to be consistent with (1).
Update language to differentiate "users" between "VSA producers" and "VSA consumers".

netlify · 2023-06-09T22:50:49Z

✅ Deploy Preview for slsa ready!

Name	Link
🔨 Latest commit	`ead4e1c`
🔍 Latest deploy log	https://app.netlify.com/sites/slsa/deploys/64f8ff113067ce0008a34788
😎 Deploy Preview	https://deploy-preview-882--slsa.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

Signed-off-by: kpk47 <[email protected]>

joshuagl

This is a great start, thanks!

I compared the PR here to the suggested actions in #878 and noticed that the intro still includes bundle. I'm not entirely certain we need to remove bundle, perhaps we could spend a few more words describing that a VSA may be attesting to a single attestation OR a bundle of attestations?

docs/verification_summary/v1.md

Signed-off-by: kpk47 <[email protected]>

TomHennen

Thanks!

docs/verification_summary/v1.md

Signed-off-by: kpk47 <[email protected]>

docs/verification_summary/v1.md

Signed-off-by: kpk47 <[email protected]>

docs/verification_summary/v1.md

MarkLodato

Looks good to me. The examples really help! A few more suggestions.

docs/verification_summary/v1.md

Signed-off-by: kpk47 <[email protected]>

- Document that we use Netlify instead of GitHub Pages now. - Update the "developing and testing locally" instructions to use `netlify dev` instead of running Jekyll directly so that redirects are handled properly. - Document how deploy previews work. - Document our production Netlify and DNS configuration. - Start a short playbook for how to debug. It likely could be expanded, but this is a good first start. Issue: slsa-framework#266 Signed-off-by: Mark Lodato <[email protected]> Co-authored-by: Joshua Lock <[email protected]>

The reference links for "Threats, Risks, and Mitigations in the Open Source Ecosystem" and "Binary Authorization for Borg" were missing. Signed-off-by: Joshua Lock <[email protected]>

…#911) Update the renovate configuration so that patches and PRs from renovate follow the project's conventional commit guidelines. Fixes: slsa-framework#910 Signed-off-by: Joshua Lock <[email protected]>

This PR contains the following updates: actions/deploy-pages: `v2.0.2` -> `v2.0.3` actions/setup-node: `v3.6.0` -> `v3.7.0` actions/upload-pages-artifact: `v1.0.9` -> `v1.0.10 Signed-off-by: Mend Renovate <[email protected]>

Dashes are not supported by the GitHub Action PR linter we use: https://github.com/amannn/action-semantic-pull-request resolves: slsa-framework#902 Signed-off-by: arewm <[email protected]>

Update the list of meeting notes on slsa.dev/notes to no longer say "bi-weekly". Signed-off-by: Mark Lodato <[email protected]>

Signed-off-by: kpk47 <[email protected]>

TomHennen · 2023-07-12T13:48:20Z

docs/verification_summary/v1.md

+    value. This step ensures that the consumer is using the VSA for the
+    producer's intended purpose.
+
+6.  Verify that the value for `slsaResult` is `PASSED`. This step ensures the


Instead of slsaResult this should be verificationResult, right?

I think the confusion results from overlap in verificationResult and verifiedLevels. The latter also has a FAILED entry, and the name implies that it's only for PASSED. Should we deprecate verificationResult and just say verifiedLevels are only for things that passed?

I'm assuming the original intention was to support saying "I checked at L2 and it failed". If so, is that a foot gun?

So, if verificationResult != 'PASSED' then verifiedLevels must be empty? If so, SGTM

TomHennen · 2023-07-12T13:48:52Z

docs/verification_summary/v1.md

+
+    -   `resourceUri` is R.
+
+    -   `slsaResult` is `PASSED`.


As above, verificationResult

TomHennen · 2023-07-12T13:49:25Z

docs/verification_summary/v1.md

+
+    -   `resourceUri` is R.
+
+    -   `slsaResult` is `PASSED`.


verificationResult

TomHennen · 2023-07-12T13:50:17Z

docs/verification_summary/v1.md

@@ -240,13 +252,111 @@ WARNING: This is just for demonstration purposes.

 <div id="slsaresult">


Should this div go down near line 352? Should there be a different div id for 'how to verify'?

I actually think SlsaResult should move up here.

That's fine too, as long as they go together. :)

laurentsimon · 2023-07-12T23:55:08Z

docs/verification_summary/v1.md

+>
+> VSA producers MAY add additional, non-SLSA properties to this field provided
+> the values do not conflict with the definition of [SlsaResult]. VSA Producers
+> SHOULD negotiate the meaning of such properties with their intended verifier.


verifier -> consumer?

MarkLodato

Sorry for so many comments.

MarkLodato · 2023-07-13T13:52:57Z

docs/verification_summary/v1.md

-Verification summary attestations communicate that an artifact has been verified
-at a specific SLSA level and details about that verification.
+Verification summary attestations convey high-level information about an
+artifact's verification, allowing  consumers to delegate verification decisions


Suggested change

artifact's verification, allowing consumers to delegate verification decisions

artifact's verification, allowing consumers to delegate verification decisions

MarkLodato · 2023-07-13T15:03:57Z

docs/verification_summary/v1.md

Personally I would go into more detail, particularly to explain the reason for the change. Something like:

Clarify that VSA can be used to express verification of things other than the SLSA Level. Previously this was technically possible, but it was only mentioned in one sentence (under SlsaResult). Now the purpose, model, and field documentation make this explicit.

Make fields policy and timeVerified optional because [...]

Add new "How to verify" section, including examples. Previously it was unclear to many readers exactly how VSAs were intended to be used, leading to possible mistakes. Now we make this explicit. This also brings the VSA spec up to parity with Provenance, which already has such a section.

Add a SLSA_BUILD_LEVEL_UNEVALUATED entry because [...]

Explain why resourceUri is required.

Other edits for clarity.

Hmm, this PR is getting a bit big. Might make sense to split...

MarkLodato · 2023-07-13T15:06:07Z

docs/verification_summary/v1.md

@@ -240,13 +252,111 @@ WARNING: This is just for demonstration purposes.

 <div id="slsaresult">


I actually think SlsaResult should move up here.

MarkLodato · 2023-07-13T15:07:14Z

docs/verification_summary/v1.md

+> This field MAY be absent if the verifier is not attesting to a specific SLSA
+> level.


Line 175 says required but here it says it's optional. Which is it?

If required, what does that mean? Is one of the SLSA_ values required? When we have more than one track, is it required to have exactly one entry for each track?

MarkLodato · 2023-07-13T15:12:41Z

docs/verification_summary/v1.md

-The VSA also allows consumers to determine the verified levels of
-all of an artifact’s _transitive_ dependencies.  The verifier does this by
-either a) verifying the provenance of each non-source dependency listed in
-the [resolvedDependencies](/provenance/v1#resolvedDependencies) of the artifact
-being verified (recursively) or b) matching the non-source dependency
-listed in `resolvedDependencies` (`subject.digest` ==
-`resolvedDependencies.digest` and, ideally, `vsa.resourceUri` ==
-`resolvedDependencies.uri`) to a VSA _for that dependency_ and using
-`vsa.verifiedLevels` and `vsa.dependencyLevels`.  Policy verifiers wishing
-to establish minimum requirements on dependencies SLSA levels may use
-`vsa.dependencyLevels` to do so.


We seem to have lost this level of detail, e.g. checking vsa.resourceUri against provenance.resolvedDependencies.uri. Should this go somewhere as well? Perhaps a new "How to produce" section?

Alternatively should this detail go in the SLSA Provenance "How to verify" section, since it's more about provenance?

/cc @TomHennen

I vote not to mention those here.

The check of vsa.resourceUri and provenance.resolvedDependencies.uri really belongs to the topic of policy and verification, and the URI matching is an opinionated way to check whether the short-circuit is permitted.

In order for that to work, there are some implicit assumptions, namely 1) the policy being evaluated is completely determined by the URIs; 2) there is a 1:1 mapping between the URIs and policies; 3) both vsa.resourceUri and provenance.resolvedDependencies.uri follow the same specs.

We could either spend a lot of energy fully flesh out all these, and in the end we just described one way it can work; Meanwhile, there are other ways short-circuiting could work, for example the policy.uri and policy.digest also contain information that may be used for making decision.

Alternatively, I think it is better just leave a high-level description here that "the verifier can use VSA to short-circuit policy verification when appropriate" and leave the details in SLSA Provenance "How to verify".

MarkLodato · 2023-07-13T15:33:08Z

docs/verification_summary/v1.md

+5.  Verify that the value for `resourceUri` in the VSA matches the expected
+    value. This step ensures that the consumer is using the VSA for the
+    producer's intended purpose.


This piece probably needs more fleshing out, perhaps in a separate PR. There have been many questions about what the resource URI is, e.g. #891.

MarkLodato · 2023-07-13T15:35:16Z

docs/verification_summary/v1.md

+    value. This step ensures that the consumer is using the VSA for the
+    producer's intended purpose.
+
+6.  Verify that the value for `slsaResult` is `PASSED`. This step ensures the


I think the confusion results from overlap in verificationResult and verifiedLevels. The latter also has a FAILED entry, and the name implies that it's only for PASSED. Should we deprecate verificationResult and just say verifiedLevels are only for things that passed?

I'm assuming the original intention was to support saying "I checked at L2 and it failed". If so, is that a foot gun?

MarkLodato · 2023-07-13T15:36:10Z

docs/verification_summary/v1.md

+
+    -   `slsaResult` is `PASSED`.
+
+    -   `verifiedLevels` contains `SLSA_BUILD_LEVEL_UNEVALUATED`.


I don't understand this piece. Why does someone check that the build level was unevaluated? If they don't care, shouldn't they just ignore it?

MarkLodato · 2023-07-13T15:36:31Z

docs/verification_summary/v1.md

 ## _SlsaResult (String)_

 </div>

 The result of evaluating an artifact (or set of artifacts) against SLSA.
 SHOULD be one of these values:

+-   SLSA_BUILD_LEVEL_UNEVALUATED


What is the purpose of this new field? That's not clear to me.

MarkLodato · 2023-07-13T15:36:55Z

docs/verification_summary/v1.md

+    verifying the artifact's SLSA provenance. See
+    [Verifying artifacts](/spec/v1.0/verifying-artifacts) for details about which
+    threats are addressed by verifying each SLSA level.
+
 ## _SlsaResult (String)_


Q: Should this enum name be changed to something not slsa specific?

MarkLodato · 2023-08-18T12:11:11Z

The v1.1 directory now exists as of #942. Should this change move there? or alternatively split out the editorial from content changes, and apply the former to v1.0 and the latter to v1.1?

Signed-off-by: kpk47 <[email protected]>

kpk47 · 2023-09-06T22:55:32Z

I've split this PR into two changes. This one contains the original's editorial changes, moved to the v1.1 directory. I moved the content changes to #964.

laurentsimon · 2023-09-06T23:13:36Z

docs/spec/v1.1/verification_summary.md

-the dependencies were verified at.
+Assert that the VSA producer has verified an artifact or set of artifacts.
+Optionally include details about the verification process, such as the verified
+SLSA level(s) and the verifier's expectations.


verifier's expectations == policy? In the rest of the text we say policy. Shall we use the same term throughout the doc? It's a bit confusing otherwise, at least for me.

laurentsimon · 2023-09-06T23:15:10Z

docs/spec/v1.1/verification_summary.md

+in-toto attestation [Statement]) by evaluating the artifact and its associated
+attestation(s) against the `policy` for `resourceUri`. Consumers who trust
+the `verifier` may assume that the artifacts identified by the
+`(subject, resourceUri)` pair met the indicated SLSA level without


to be more general and follow earlier wording, we could say pair met the details about the verification process.

I think including both may be more helpful, i.e. "... met the indicated SLSA level and other criteria in the policy".

We are implementing a producer/consumer of VSA v1.0 and realized that there are two different scenarios:

We consume VSA produced by ourselves: in this case we could leverage the extension attributes to fully convey all the information that we are interested in, such as additional verification beyond what is defined in the SLSA BUILD levels;

We consume VSA produced by others (and similarly, others consume VSA produced by us): in this case, since the consumers and producers may not have mutual definitions on extended checks, to make the VSA useful, we must all resort to the standard language, i.e. SLSA defined levels.

So, if we are producing a VSA without foreknowledge of who will consume it, we should put in both SLSA levels and the extension attributes in the VSA.

laurentsimon · 2023-09-06T23:16:46Z

docs/spec/v1.1/verification_summary.md

+the `verifier` may assume that the artifacts identified by the
+`(subject, resourceUri)` pair met the indicated SLSA level without
+themselves needing to evaluate the artifact or to have access to the
+attestations the `verifier` used to make its determination.


may add another example that the VSA works in cases where the repository is not public. That's why we can't verify SLSA provenance directly for closed-source software.

laurentsimon · 2023-09-06T23:19:46Z

docs/spec/v1.1/verification_summary.md

+attestations the `verifier` used to make its determination.
+
+VSAs can also be chained together to meet higher level goals, such as tracking
+the verified SLSA level(s) for the `subject`'s transitive dependencies. Rather


same comment as before: if we're saying that levels and other verified metadata is optional, we could be more generic tracking details about the verification process for the subject's transitive dependencies.

laurentsimon · 2023-09-06T23:22:28Z

docs/spec/v1.1/verification_summary.md

+VSAs can also be chained together to meet higher level goals, such as tracking
+the verified SLSA level(s) for the `subject`'s transitive dependencies. Rather
+than verifying provenance for the artifact and each of its transitive
+dependencies all at once, the verifier can verify each dependency independently


If a verifier can verify provenance and generate VSA, why does it need to verify them independently? Is this for security or is it a caching (optimization) mechanism? Is there an assumption in the sentence that maybe there are multiple verifiers, one that verified dependencies (say, RedHat) while another consumers it (say, Google) to validate a Google binary? Maybe the sentence can be expanded to motivate both cases...?

I think this part refers to the "divide-and-conquer" strategy the VSA enables.

For a naive example, if a system image has 20 software packages, and each package has 50 dependency libraries. A complete transitive dependency verification would involve checking 1+20+20*50 = 1021 artifacts during a single verification, which may consume too much time and violate the verifier's latency SLO.

However, with VSA, what can happen is that, when the 20 software packages get staged in an artifact repo, the repo invokes transitive verification for each, so each verification only checks 1+50 artifacts; and the verification produces VSAs, which propagate to the system image's attestation bundle. Then, when we verify the system image, the verifier will only need to perform at 1+20 checks, because the presence of VSAs of the packages eliminates the need to check the dependency libraries (since VSA is a proof that they are already checked).

Effectively, VSA functions as a "distributed dynamic programming table" and facilitates efficient transitive dependency verification.

laurentsimon · 2023-09-06T23:23:50Z

docs/spec/v1.1/verification_summary.md

+dependencies all at once, the verifier can verify each dependency independently
+and produce VSAs. Finally, the verifier combines those VSAs; the artifact
+is the final VSA's `subject` and each transitive dependency is an
+entry in `dependencyLevels`.


same comment: do we want to be generic about "verified metadata" or mention verified levels? If the former, we could have a dedicated section with examples for different types of metadata, starting with a verified level. Just an idea...

laurentsimon · 2023-09-06T23:26:18Z

docs/spec/v1.1/verification_summary.md

+themselves needing to evaluate the artifact or to have access to the
+attestations the `verifier` used to make its determination.
+
+VSAs can also be chained together to meet higher level goals, such as tracking


what does higher-level goal mean?
Not clear what "chained" means. Do VSAs reference each other like in a block chain, ie do they link to a prior VSA in their output format?

I think "chained" refers to the following:

VSA summarizes verification results; and

VSA can short-circuit verification.

These two properties feed each other, so that a VSA is able to summarize the verification results on all transitive dependencies. A VSA represents cumulative verification along the dependency chains of an artifact.

Maybe it is more accurate to describe VSAs subsumes from one another.

For a native example, a system image with 20 packages, each with 50 dependency libraries.

Without VSA, the attestation bundle of the system image will look like:

[system image build provenance] [package 1 build provenance] ... [package 20 build provenance] [package 1 library 1 build provenance] ... [package 1 library 50 build provenance] [package 2 library 1 build provenance] ... ... [package 20 library 50 build provenance]

With VSA and staging repo verification, the attestation bundle of the system image will look like:

[system image build provenance] [package 1 VSA] ... [package 20 VSA]

After the system image get verified, the attestation bundle of the system image can be reduced to just:

[system image VSA]

Update VSA for SLSA v1.1

8b0b25e

Signed-off-by: kpk47 <[email protected]>

kpk47 force-pushed the vsa branch from 9e37dcd to 8b0b25e Compare June 9, 2023 23:04

joshuagl reviewed Jun 12, 2023

View reviewed changes

docs/verification_summary/v1.md Outdated Show resolved Hide resolved

docs/verification_summary/v1.md Outdated Show resolved Hide resolved

docs/verification_summary/v1.md Outdated Show resolved Hide resolved

AdamZWu reviewed Jun 12, 2023

View reviewed changes

docs/verification_summary/v1.md Outdated Show resolved Hide resolved

laurentsimon reviewed Jun 13, 2023

View reviewed changes

docs/verification_summary/v1.md Outdated Show resolved Hide resolved

Address review comments

1233829

Signed-off-by: kpk47 <[email protected]>

kpk47 marked this pull request as ready for review June 23, 2023 15:24

kpk47 requested a review from MarkLodato as a code owner June 23, 2023 15:24

kpk47 requested a review from joshuagl June 26, 2023 19:11

clarify that you can set verifiedLevels without setting policy

68adac3

Signed-off-by: kpk47 <[email protected]>

kpk47 requested review from mlieberman85, laurentsimon, TomHennen and AdamZWu June 28, 2023 13:00

TomHennen approved these changes Jun 28, 2023

View reviewed changes

docs/verification_summary/v1.md Outdated Show resolved Hide resolved

docs/verification_summary/v1.md Outdated Show resolved Hide resolved

Clarify that verifiedLevels can contain custom values.

956dc5a

Signed-off-by: kpk47 <[email protected]>

AdamZWu reviewed Jun 28, 2023

View reviewed changes

docs/verification_summary/v1.md Outdated Show resolved Hide resolved

laurentsimon reviewed Jun 28, 2023

View reviewed changes

docs/verification_summary/v1.md Outdated Show resolved Hide resolved

MarkLodato reviewed Jun 28, 2023

View reviewed changes

docs/verification_summary/v1.md Outdated Show resolved Hide resolved

docs/verification_summary/v1.md Outdated Show resolved Hide resolved

docs/verification_summary/v1.md Outdated Show resolved Hide resolved

reworked How to Verify section

b0a877b

Signed-off-by: kpk47 <[email protected]>

kpk47 requested review from TomHennen, MarkLodato, AdamZWu, laurentsimon and olivekl and removed request for AdamZWu June 28, 2023 21:44

laurentsimon reviewed Jun 28, 2023

View reviewed changes

docs/verification_summary/v1.md Outdated Show resolved Hide resolved

MarkLodato reviewed Jun 29, 2023

View reviewed changes

docs/verification_summary/v1.md Outdated Show resolved Hide resolved

docs/verification_summary/v1.md Outdated Show resolved Hide resolved

docs/verification_summary/v1.md Outdated Show resolved Hide resolved

docs/verification_summary/v1.md Outdated Show resolved Hide resolved

fix formatting

60396db

Signed-off-by: kpk47 <[email protected]>

MarkLodato and others added 7 commits July 11, 2023 16:24

impl: add missing links in relatedwork doc (slsa-framework#912)

359c50a

The reference links for "Threats, Risks, and Mitigations in the Open Source Ecosystem" and "Binary Authorization for Borg" were missing. Signed-off-by: Joshua Lock <[email protected]>

impl: update renovate config for conventional commits (slsa-framework…

79fdfe1

…#911) Update the renovate configuration so that patches and PRs from renovate follow the project's conventional commit guidelines. Fixes: slsa-framework#910 Signed-off-by: Joshua Lock <[email protected]>

impl: Update github-actions (slsa-framework#909)

2f22cf3

This PR contains the following updates: actions/deploy-pages: `v2.0.2` -> `v2.0.3` actions/setup-node: `v3.6.0` -> `v3.7.0` actions/upload-pages-artifact: `v1.0.9` -> `v1.0.10 Signed-off-by: Mend Renovate <[email protected]>

impl: Remove dashes from types in PR name lint (slsa-framework#903)

4cde255

Dashes are not supported by the GitHub Action PR linter we use: https://github.com/amannn/action-semantic-pull-request resolves: slsa-framework#902 Signed-off-by: arewm <[email protected]>

nonspec: community meeting is no longer biweekly (slsa-framework#906)

c0e01a1

Update the list of meeting notes on slsa.dev/notes to no longer say "bi-weekly". Signed-off-by: Mark Lodato <[email protected]>

grammar/clarity edits

d0ef5f4

Signed-off-by: kpk47 <[email protected]>

kpk47 changed the title ~~content: Update VSA for SLSA v1.1~~ content: Clarify the VSA's purpose and how to verify VSAs. Jul 11, 2023

Added changelog for this PR

f2e1d11

Signed-off-by: kpk47 <[email protected]>

kpk47 requested a review from MarkLodato July 11, 2023 23:45

kpk47 added 2 commits July 11, 2023 16:46

Merge branch 'main' of https://github.com/kpk47/slsa into vsa

614a115

lint

a219938

Signed-off-by: kpk47 <[email protected]>

TomHennen requested changes Jul 12, 2023

View reviewed changes

laurentsimon reviewed Jul 12, 2023

View reviewed changes

MarkLodato requested changes Jul 13, 2023

View reviewed changes

kpk47 mentioned this pull request Jul 17, 2023

discussion: What is the role of VSA? #921

Open

kpk47 added 6 commits September 5, 2023 15:40

Merge branch 'main' of https://github.com/slsa-framework/slsa into vsa

3c8ee37

move changes to v1.1 directory

1febf58

Signed-off-by: kpk47 <[email protected]>

backport editorial changes to v1.0

1fa3fa9

Signed-off-by: kpk47 <[email protected]>

move ediorial changes to v1.1 directory

e214c2a

Signed-off-by: kpk47 <[email protected]>

fix link refs

03fe050

Signed-off-by: kpk47 <[email protected]>

fix link caps

ead4e1c

Signed-off-by: kpk47 <[email protected]>

kpk47 changed the title ~~content: Clarify the VSA's purpose and how to verify VSAs.~~ editorial: Clarify language in VSA spec Sep 6, 2023

kpk47 requested review from TomHennen, MarkLodato and laurentsimon September 6, 2023 22:55

laurentsimon reviewed Sep 6, 2023

View reviewed changes

kpk47 closed this Oct 10, 2023

		@@ -240,13 +252,111 @@ WARNING: This is just for demonstration purposes.

		<div id="slsaresult">

	artifact's verification, allowing consumers to delegate verification decisions
	artifact's verification, allowing consumers to delegate verification decisions

		> This field MAY be absent if the verifier is not attesting to a specific SLSA
		> level.


		- `slsaResult` is `PASSED`.

		- `verifiedLevels` contains `SLSA_BUILD_LEVEL_UNEVALUATED`.

editorial: Clarify language in VSA spec #882

editorial: Clarify language in VSA spec #882

Conversation

kpk47 commented Jun 9, 2023 • edited Loading

netlify bot commented Jun 9, 2023 • edited Loading

✅ Deploy Preview for slsa ready!

joshuagl left a comment

Choose a reason for hiding this comment

TomHennen left a comment

Choose a reason for hiding this comment

MarkLodato left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MarkLodato left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MarkLodato Jul 13, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AdamZWu Jul 13, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MarkLodato commented Aug 18, 2023

kpk47 commented Sep 6, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AdamZWu Sep 7, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AdamZWu Sep 7, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kpk47 commented Jun 9, 2023 •

edited

Loading

netlify bot commented Jun 9, 2023 •

edited

Loading

MarkLodato Jul 13, 2023 •

edited

Loading

AdamZWu Jul 13, 2023 •

edited

Loading

AdamZWu Sep 7, 2023 •

edited

Loading

AdamZWu Sep 7, 2023 •

edited

Loading