Add spec for Trusted Publishers (OIDC auth for NuGet) #13673

joelverhagen · 2024-08-03T19:00:11Z

See the rendered functional description (main spec) and rendered technical description (supporting document).

This is a spec for NuGet/NuGetGallery#9332.

It brings OpenSSF's https://repos.openssf.org/trusted-publishers-for-all-package-repositories document to NuGet.org.

Please 👍 or 👎 this comment to help us with the direction of this feature & leave as much feedback/questions/concerns as you'd like on this issue itself and we will get back to you shortly.

Thank You 🎉

JonDouglas · 2024-08-05T14:59:50Z

Here are some additional responses of ~n=100-200 on later questions on the recent survey we ran:

JonDouglas · 2024-08-05T15:02:31Z

accepted/2024/meta/trusted-publishers-oidc-for-nuget-push/trust-policy-form.png

Do we need a branch item here? i.e.

The branch component of the sub identifier gets overridden when someone sets the environment in their YAML. But the environment isn't there by default. I'm not sure if we should only allow folks to specify which "channel" or "track" the packages come from via environment. It seems more git flavored to also allow a branch filter which will be possible on nearly all workflows out of the box vs. an environment specifier.

See https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-deployments/managing-environments-for-deployment

We could have a series of checkboxes. "Filter by environment: ___________", "Filter by branch: __________", "Filter by workflow file: __________". At least one would be required but you could filter by all 3 if you want.

I added clarification about the 3 filtering options (branch vs environment vs workflow file name)

JonDouglas · 2024-08-05T15:05:02Z

accepted/2024/trusted-publishers-oidc-for-nuget-push.md

+the operation will be allowed. If the package ID is new and there is ambiguity on which package owner should be assigned
+to the package (due to multiple matching trust policies), the most recently created trust policy will be used.
+
+### Step 2: add a GitHub Actions workflow with NuGet.org Trusted Publisher authentication


I assume we will want to have a NuGet GH action template on the marketplace to simplify this beyond docs?

i.e. rubygems/rubygems.org#4286

Are you referring to a workflow template like this?
https://docs.github.com/en/actions/using-workflows/creating-starter-workflows-for-your-organization
Or a GitHub Action to do pack + auth + push all in one?

More so on the public marketplace:

https://github.com/rubygems/release-gem?tab=readme-ov-file#requirements -> https://github.com/marketplace/actions/release-gem

The nuget/login action in the design would be on the public marketplace. But it would only do the OIDC -> short-lived API key trade, and not the push step. ... but maybe it could? It would need a parameter to specify which .nupkgs to push.

I think it's better to keep the public marketplace action to be minimal, and re-usable for multiple use cases. If the action does nuget push internally, then we may end up needing all of the CLI parameters that go into nuget push, and add them as push gets more complex.

I would prefer nuget/login public marketplace action and not nuget/release for now. This also makes using the short-lived API key for unlist/relist and even deprecate API easier since all nuget/login does is produce an API key. It's not hardcode to always push.

accepted/2024/trusted-publishers-oidc-for-nuget-push.md

JonDouglas · 2024-08-05T15:24:44Z

accepted/2024/trusted-publishers-oidc-for-nuget-push.md

+
+## Unresolved Questions
+
+Ask away!


There are no desired UI elements to indicate to end-users that a package has enabled this functionality today right?

Would we want to consider parts of the Build Provenance UI elements here?

i.e. Source Commit and Build File of the "trusted publisher"

As part of this design, no.

In your example screenshot there is a green check mark and the word "Signed" as well as a ledger entry. The green check mark only makes sense if there is some tamper protection or strong build provenance consideration (SLSA build level 2+ IMO).

We could perhaps show "Published from GitHub Actions", with the source commit and build file links, but it's not strong in the same sense that npm build provenance is strong where the artifacts are signed inside the workload, rather than just published.

See the latter paragraphs in the Auditing usage on NuGet.org section to see what I think we should commit to in this spec. Essentially, it's just recording the token (or some useful part of it) for later mining.

JonDouglas · 2024-08-05T15:25:29Z

accepted/2024/trusted-publishers-oidc-for-nuget-push.md

+## Future Possibilities
+
+- Enable additional CI/CD systems that support OIDC tokens
+ - Azure DevOps is next on the popularity list. Their workload identity federation is very focused on Azure today


+1 to AzDo based on usage and qualitative data posted in this PR thread as a comment screenshot.

I hope we can get Azure DevOps integration. That would help many Microsoft teams who publish from Azure DevOps to NuGet.org (e.g. NuGet client team, NuGet.* packages!).

JonDouglas

Looks great. Awesome details and data driving this! Let me know when we can amplify and get more eyes on it. The functional bits look good to me and added comments as consideration points.

Clarify branch, environment, and workflow filters. Add note about 2FA Fix typo. Clarify existing NuGet auth flows Require HTTPS for service index and ApiKeyService endpoint Mentioned public marketplace for GitHub Action

accepted/2024/trusted-publishers-oidc-for-nuget-push.md

dtivel · 2024-08-06T03:41:21Z

accepted/2024/trusted-publishers-oidc-for-nuget-push.md

+This step is pretty self explanatory. Many developers, even hobbyist developers who are only producing packages for
+their own consumption, already have their source code stored in a Git repository, hosted on GitHub.
+
+Additionally, GitHub Actions must be enabled for your repository. For public repositories, there is a generous free


You should be explicit on whether a repository can be private.

Added! As long as the token is valid and issued from GitHub Actions (the known issuer base URL https://token.actions.githubusercontent.com), we will accept it. This can include private repositories.

dtivel · 2024-08-06T03:42:41Z

accepted/2024/trusted-publishers-oidc-for-nuget-push.md

+(OIDC) tokens because they take the place of long-lived NuGet API keys as the credential. The NuGet package source must
+also be configured to allow OIDC tokens from this specific build environment.
+
+For the sake of understanding, we'll use GitHub and GitHub Actions as the example below, but it's important to note that


Are there any minimum expectations on a forge, in terms of security, transparency, or whatever?

I updated the future possibilities section with some vague details. I think the reality is that we will evaluate it on case-by-case basis. GitHub is a trusted, industry wide service so trusting their OIDC tokens is straight forward. If there is a request for a Trusted Publisher we, nor many of our users, know anything about, we will probably be a little skeptical and ask a lot of questions.

dtivel · 2024-08-06T04:03:10Z

accepted/2024/trusted-publishers-oidc-for-nuget-push.md

+information about scopes on API keys, see [Scoped API
+keys](https://learn.microsoft.com/en-us/nuget/nuget-org/scoped-api-keys). In summary:
+
+- **Package owner**: for users that are members of one or more organizations, it's important to know which package owner


Suppose you transfer ownership of a package to me. (You make me a coowner, and then I remove you.) How would I remove your ability to continue publishing packages with your trusted publisher policy?

The moment you are removed as an owner, your trust policy will no longer work. The trust policy is moreso associated with a package owner rather than a package. In fact, the only this package-specific about a trust policy (or long lived API key) is a package ID scope.

Each time you upload a package version (via web, API key, or Trusted Publisher), whether or not the Package owner in question (the package owner property listed here) is a current, direct owner of the package. If it is not, the upload will be blocked.

I updated the spec to clarify this.

accepted/2024/trusted-publishers-oidc-for-nuget-push.md

Co-authored-by: Damon Tivel <[email protected]>

dtivel · 2024-08-08T14:15:33Z

accepted/2024/trusted-publishers-oidc-for-nuget-push.technical.md

+ - `environment` claim must be `{environment}` (case insensitive)
+- If a workflow path filter is provided in the trust policy:
+ - `job_workflow_ref` claim must be `{repo owner}/{repo name}/{workflow path}@.*` (case insensitive)
+ - The workflow path should be normalized to `/` path separators at the time of trust policy creation


Is this NuGet.org's responsibility? Is it as simple as replacing all \ with /?

I think it can be NuGet.org's responsibility, as a nicety. It would be very annoying to get auth errors, just because you copied the relative path from a Windows machine. Yes, it should be that simple.

dtivel · 2024-08-08T14:23:50Z

accepted/2024/trusted-publishers-oidc-for-nuget-push.technical.md

+In addition to the general JWT checks, specific checks are made for each Trusted Publisher. For GitHub Actions, the
+following checks will be made:
+
+- `sub` claim matches `{repo owner}/{repo name}:.*` (case insensitive)


It's a bit difficult for me to understand what's variable and what's constant. For example, this might be reworded to:

sub claim matches the regular expression pattern {repo owner}/{repo name}:.* where {repo owner} is the repository owner's name and {repo name} is the repository's name. Then, I would understand dtivel/myrepo:somepath as a matching pattern.

(I inferred that * is something of a wildcard or maybe .* is a regular expression pattern, but I can't be certain from the spec.)

What would an actual sub look like?

I expressed it as a regex. You're right, that's confusing. I'll clarify that and add a sample.

A branch sub would look like this: repo:octo-org/octo-repo:ref:refs/heads/demo-branch.

accepted/2024/trusted-publishers-oidc-for-nuget-push.technical.md

dtivel · 2024-08-08T14:42:06Z

accepted/2024/trusted-publishers-oidc-for-nuget-push.technical.md

+scalability it must opt to rate limit the endpoint instead of caching. NuGet.org will rate limit the endpoint to 1 API
+key created per 30 seconds, per user.


I don't grok how this limit aligns with someone publishing many packages in a short period of time. Consider the .NET team publishing packages in bulk to NuGet.org. Will that translate to hundreds or thousands of API calls within a short timeframe? Or, is the API key cached and reused on the client side?

It would be good to discuss here how you see this limitation not being a problem for various publishing scenarios.

Will that translate to hundreds or thousands of API calls within a short timeframe? Or, is the API key cached and reused on the client side?

I expect the API key to be cached on the client side. In most workflows (no custom scripting), this will be done by a single nuget/login workflow step with a single output value, which is the short lived API key. This could be used one or more push operations (all referring to the single step output == single API key). I imagine most users will do dotnet nuget push *.nupkg which internally does multiple push operations with a single API key provided via CLI arg.

Suppose dotnet nuget push *.nupkg takes longer than 15 minutes. Imagine lots of packages, slow network, whatever. Will NuGet client automatically re-request a new token via nuget/login midstream, as necessary?

Not with this version of the proposal. See the https://github.com/NuGet/Home/blob/jver-oidc/accepted/2024/trusted-publishers-oidc-for-nuget-push.md#enable-nuget-authentication-provider-integration-to-avoid-token-expiration-for-long-workflows.

The user will be able to work around the issue with multiple nuget/login GitHub Actions steps and breaking up the push steps. It's not a great solution, but the data suggests we can pick a single short lifetime (15 minutes) and cover the vast majority of cases.

dtivel · 2024-08-08T14:47:27Z

accepted/2024/trusted-publishers-oidc-for-nuget-push.technical.md

+Content-Type: application/json
+
+{
+ "api_key": "{short lived API key in clear text}",


I didn't see any explicit mention of how long the short-lived API key will be valid. I think that's intentional, since we should have some flexibility in adjusting its lifespan. However, for the sake of argument, what is a reasonable starting point? 30 minutes?

What is the user experience if the short-lived API key expires before they're done publishing and how do they recover? Or, is the client (NuGet client, here) supposed to automatically reacquire a new API key transparently so that the user never notices the expiration?

I'm trying to understand where this automagical flow might actually break down for users.

I didn't see any explicit mention of how long the short-lived API key will be valid. I think that's intentional, since we should have some flexibility in adjusting its lifespan. However, for the sake of argument, what is a reasonable starting point? 30 minutes?

I actually thought I documented. I did not 😂. I was planning on using 15 minutes. This is what PyPI uses and it should have good coverage for our push patterns. I will add supporting data.

dtivel · 2024-08-08T14:54:00Z

accepted/2024/trusted-publishers-oidc-for-nuget-push.technical.md

+- `sub` claim matches `{repo owner}/{repo name}:.*` (case insensitive)
+ - The suffix of the `sub` is implied by the other checks
+- `repository_owner` claim matches the `{repo owner}` name (case insensitive)
+- `repository_owner_id` claim matches the numeric owner ID recorded at the time of the trust policy creation


This numeric owner ID is forge-assigned (here GitHub-assigned)?

Yes, GitHub assigned.

I should note that other forges may not have a numeric owner ID. We will need to assess resurrection attacks or any other impersonation risks on a case by case basis.

accepted/2024/trusted-publishers-oidc-for-nuget-push.technical.md

Co-authored-by: Damon Tivel <[email protected]>

Renamed resource from ApiKeyService to TokenService to be a bit more flexible for the future.

haydentherapper

This is a fantastic write up! Excited to see this spec!

haydentherapper · 2024-08-09T19:50:36Z

accepted/2024/trusted-publishers-oidc-for-nuget-push.md

+ | extend ["% of owners"] = round(100.0 * Owners / TotalUniqueOwnersSets, 2)
+-->
+
+| Forge | Package IDs | Owners | % of package IDs | % of owners |


It might be helpful to also note which of these platforms support OIDC for their workflows.

Great point. I'll do that research and include a little note in the table.

accepted/2024/trusted-publishers-oidc-for-nuget-push.md

haydentherapper · 2024-08-12T19:53:51Z

accepted/2024/trusted-publishers-oidc-for-nuget-push.md

+CI/CD systems will be supported so some users will still need to use the older authentication flows such as long-lived,
+manually rotated API keys.
+
+The trust policy is configured once and works forever. An API key forces the package author to re-assess CI/CD


Thoughts on if you would let a package "downgrade" to move off trusted publishing? And a similar question, would you allow both to be configured, or only one?

Hmm good question! I think starting out we would allow full flexibility in a "walk-crawl-run" approach. As we mature, we see how the feature goes in our ecosystem, we can lock things down more. We took a similar approach with requiring 2FA on our website. At first it was opt in, then opt out (new accounts had it enabled), then it was mandated. This allowed us to look at customer feedback as we went and not move so quickly that folks got stuck.

I added a section about this.

accepted/2024/trusted-publishers-oidc-for-nuget-push.md

accepted/2024/trusted-publishers-oidc-for-nuget-push.technical.md

haydentherapper · 2024-08-12T20:12:21Z

accepted/2024/trusted-publishers-oidc-for-nuget-push.technical.md

+The metadata available in a GitHub Actions OIDC token is mentioned in GitHub's [Understanding the OIDC
+token](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#understanding-the-oidc-token).
+
+These claims could offer useful indicators to package consumers about the package. In order to support a future effort


This comment is orthogonal for trusted publishing, but I might avoid discussing SLSA Build L1 - It doesn't add much given it's not a signed attestation and if the registry was constructing the provenance, then it requires trust in the registry that it properly recorded the claims, rather than the builder.

That's a fair point. I do want to mention SLSA Build levels to come extent, at least to say this does NOT provided L2+! I talked to Zach S. on the OpenSSF Slack. He said using this information would be L1 but it's not great since it is tamperable. I would say this metadata is better than package author-attested repo/project URL since the consumer needs to just trust the registry and GitHub Actions, but it's not as good as a proper signed provenance thing.

skofman1 · 2024-08-12T22:08:47Z

accepted/2024/trusted-publishers-oidc-for-nuget-push.md

+
+#### What NuGet API operations can be used inside the GitHub Actions workflow?
+
+To scope the ways in which a GitHub trust policy can be used, similar scoping rules to the current API key flow can be


I recommend investigating the current usage of API Key scopes to understand how they are used. For example, are globs commonly used? Are there API keys that only allow pushing new versions? Are they common? I have a suspicion that this functionality isn't used, so we should check before carrying it forward. We might want to make changes / simplify the MVP.

Great point. I was assuming parity would be the easiest since we would be stamping out short-lived API keys from the OIDC token, so all of the existing API key scoping can apply. But there is still cost to adding these parameters to the trust policy definition and making the UI work and look pretty+accessible. I will check the usage and modify the spec if adoption is "low".

I looked at the data. I think we can definitely get by without package ID and allowed action scoping, especially since the API keys are short-lived.

accepted/2024/trusted-publishers-oidc-for-nuget-push.md

accepted/2024/trusted-publishers-oidc-for-nuget-push.technical.md

Co-authored-by: Damon Tivel <[email protected]>

dtivel

I'm partial to calling this "OIDC Publishers" over "Trusted Publishers", but otherwise this spec looks good.

martincostello · 2024-09-05T07:30:30Z

accepted/2024/trusted-publishers-oidc-for-nuget-push.md

+to see all of the properties.
+
+For the sake of simplicity, we will start with the following workflow filters:
+- Filtering for a specific *branch*, as shown in the UI above (branch filter)


Will this also support tags? For example, when a tag is created v1.2.3 and a workflow is kicked off automatically on tag creation to build that version and then publish it.

Hmmm generally a tag trust policy should be possible: https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/about-security-hardening-with-openid-connect#filtering-for-a-specific-tag

Question for you: would you want this feature? It seems like you would need to update the trust policy for every release as your version tag increments.

I'll note the existing filters are meant to be "invariants" you set once and change infrequently (branch name, env name, workflow path). Tag seems different in this regard.

I guess more what I'd be after is a policy that matches a tag with pattern (e.g. :ref:refs/tags/v*) rather than exact match.

My typical release process is to draft a release for a tag in GitHub that has a specific version (e.g. v1.2.3) with the release notes prepared etc. Then when I'm ready to ship, I publish that release which creates the tag. The triggers on my CI workflow are then setup like this:

on: push: branches: [ main ] tags: [ v* ] pull_request: branches: [ main ] workflow_dispatch:

Publishing then happens based on a condition like this:

if: | github.event.repository.fork == false && startsWith(github.ref, 'refs/tags/v')

The net effect is that the "real" build happens after tagging, and that packages get shipped off to NuGet.org once produced.

So in a vacuum, I would match on the tag rather than a branch as I wouldn't want any push to main to be allowed to publish.

If tags aren't supported, then I would use an environment rather than a branch, as I currently use environments to scope the NuGet API key secret to that environment so it's not available to all the workflow runs (it also lets me manually approve the push job).

I heartily endorse @martincostello's comments above - this is how a very large set of OSS projects are versioned, not just in the .NET ecosystem but broadly across other ecosystems as well. Not supporting pattern-based, tag-based workflows would be a huge miss IMO.

It may be useful looking into branch wildcard support as well - I know that e.g. in dotnet we use pattern-based rules in many other places to signify some special status - e.g. for the SDK ^release/\d\.\d\.\d\d\d$ is a stable release branch and may be able to trigger certain workflows.

I updated the document with wildcard support on tags and branches. This aligns with the pattern matching on package ID scopes. I am not sure if a regex is the right UX but I'm happy to hear other opinions on that!

I am not sure if a regex is the right UX but I'm happy to hear other opinions on that!

Glob patterns vs. regex have both been used as examples here, so I think it's worth clarifying which since the syntax is so similar for trivial cases. A lot of places use glob patterns for branch matching, so there may be some confusion if regex is used.

Glob pattern above: :ref:refs/tags/v* (typically converted to regex: :ref:refs/tags/v.* though this is not precisely the same; it would be more accurate as :ref:refs/tags/v[!/]* though that's hardly intuitive)
Regex pattern above: ^release/\d\.\d\.\d\d\d$ (converted to glob: release/[0-9].[0-9].[0-9][0-9][0-9])

Worth noting in the glob pattern example, typically glob expansion only happens within the current directory level, so v* will match v1.2.3 but not version/1.2.3. The simple regex conversion .* does not respect path delimiters, so v.* would match both v1.2.3 and version/1.2.3.

to clarify - I'd be perfectly happy for just globs, the regex was just meant to be a related example of branch and ref names being signals based on structure. I'd expect users to use release/* for example.

Good point @jimmylewis, in my experience the term globbing is most often used for file system/file paths. I am not sure if the concept cleanly translated in users' minds to tag/branch names with slashes. IMO we can do something simple where * expands to .* regex and not worry about including slashes in that that capture.

Today "globbing" on NuGet.org API key scopes is like this:
https://github.com/NuGet/NuGetGallery/blob/a4b3c64acb65ca68eb67ac6b51242356aa5e4da7/src/NuGetGallery.Services/Extensions/ScopeExtensions.cs#L54-L58

Add spec for Trusted Publishers (OIDC auth for NuGet)

b5394a8

joelverhagen force-pushed the jver-oidc branch from 42f3571 to b5394a8 Compare August 3, 2024 19:04

JonDouglas requested a review from a team August 3, 2024 19:23

joelverhagen requested a review from a team August 3, 2024 23:18

JonDouglas reviewed Aug 5, 2024

View reviewed changes

accepted/2024/trusted-publishers-oidc-for-nuget-push.md Show resolved Hide resolved

JonDouglas reviewed Aug 5, 2024

View reviewed changes

JonDouglas approved these changes Aug 5, 2024

View reviewed changes

Address comments

9279166

Clarify branch, environment, and workflow filters. Add note about 2FA Fix typo. Clarify existing NuGet auth flows Require HTTPS for service index and ApiKeyService endpoint Mentioned public marketplace for GitHub Action

dtivel reviewed Aug 6, 2024

View reviewed changes

joelverhagen and others added 3 commits August 6, 2024 09:34

Update accepted/2024/trusted-publishers-oidc-for-nuget-push.md

5f7f90e

Co-authored-by: Damon Tivel <[email protected]>

Update accepted/2024/trusted-publishers-oidc-for-nuget-push.md

8878bda

Co-authored-by: Damon Tivel <[email protected]>

Address comments

d9d2e48

dtivel reviewed Aug 8, 2024

View reviewed changes

joelverhagen and others added 4 commits August 9, 2024 12:16

Update accepted/2024/trusted-publishers-oidc-for-nuget-push.technical.md

aeeb29d

Co-authored-by: Damon Tivel <[email protected]>

Add example sub, clarify API key caching

8d6c280

Address comments

a822af8

Renamed resource from ApiKeyService to TokenService to be a bit more flexible for the future.

Add note about masking

c3952bc

haydentherapper reviewed Aug 12, 2024

View reviewed changes

skofman1 reviewed Aug 12, 2024

View reviewed changes

accepted/2024/trusted-publishers-oidc-for-nuget-push.md Show resolved Hide resolved

joelverhagen and others added 3 commits August 15, 2024 16:48

Address some comments

25fa03e

Don't allow ID scoping and allowed action scoping

21128b5

Merge remote-tracking branch 'origin/jver-oidc' into jver-oidc

24c2348

dtivel reviewed Aug 22, 2024

View reviewed changes

accepted/2024/trusted-publishers-oidc-for-nuget-push.md Outdated Show resolved Hide resolved

dtivel reviewed Aug 22, 2024

View reviewed changes

accepted/2024/trusted-publishers-oidc-for-nuget-push.md Outdated Show resolved Hide resolved

dtivel reviewed Aug 22, 2024

View reviewed changes

accepted/2024/trusted-publishers-oidc-for-nuget-push.technical.md Outdated Show resolved Hide resolved

joelverhagen and others added 3 commits August 22, 2024 11:52

Update accepted/2024/trusted-publishers-oidc-for-nuget-push.md

0cb0ade

Update accepted/2024/trusted-publishers-oidc-for-nuget-push.md

f4da52e

Co-authored-by: Damon Tivel <[email protected]>

Update accepted/2024/trusted-publishers-oidc-for-nuget-push.technical.md

011fcc5

Co-authored-by: Damon Tivel <[email protected]>

dtivel approved these changes Aug 22, 2024

View reviewed changes

JonDouglas mentioned this pull request Aug 22, 2024

[Epic] "Trusted Publishers" (name tbd) #13731

Open

11 tasks

erdembayar mentioned this pull request Sep 4, 2024

Readme: Add support for NOTE, TIP, WARNING, IMPORTANT, and CAUTION notations NuGet/NuGetGallery#10125

Open

martincostello reviewed Sep 5, 2024

View reviewed changes

joelverhagen marked this pull request as ready for review September 5, 2024 12:34

joelverhagen requested a review from a team as a code owner September 5, 2024 12:34

Add tag filtering to the proposal

6509acd

		scalability it must opt to rate limit the endpoint instead of caching. NuGet.org will rate limit the endpoint to 1 API
		key created per 30 seconds, per user.


		#### What NuGet API operations can be used inside the GitHub Actions workflow?

		To scope the ways in which a GitHub trust policy can be used, similar scoping rules to the current API key flow can be

Add spec for Trusted Publishers (OIDC auth for NuGet) #13673

Are you sure you want to change the base?

Add spec for Trusted Publishers (OIDC auth for NuGet) #13673

Conversation

joelverhagen commented Aug 3, 2024 • edited by JonDouglas Loading

JonDouglas commented Aug 5, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JonDouglas Aug 5, 2024 • 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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JonDouglas 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

joelverhagen Aug 9, 2024 • 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

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

haydentherapper 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

Choose a reason for hiding this comment

dtivel left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joelverhagen Sep 5, 2024 • edited Loading

Choose a reason for hiding this comment

joelverhagen Sep 5, 2024 • 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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joelverhagen commented Aug 3, 2024 •

edited by JonDouglas

Loading

JonDouglas Aug 5, 2024 •

edited

Loading

joelverhagen Aug 9, 2024 •

edited

Loading

joelverhagen Sep 5, 2024 •

edited

Loading

joelverhagen Sep 5, 2024 •

edited

Loading