Discuss further revisions to CI/CD privacy notice

[swinslow]

Description

From conversation with @haydentherapper, as a follow-on to #2796 / #2797, this is a longer-term placeholder to follow up on whether to further revise / expand the privacy statement notice as relates to CI/CD usage.

May also want to consider whether to clarify usage of flags (e.g. --yes) in connection with non-interactive usage.

[znewman01]

I think my preference here is to make opt-in explicit with a unique --accept-terms flag. It seems somewhat wrong that non-interactive clients don't actually accept the terms (similarly for --yes).

That said, it's a little user-hostile so I'd be happier if we introduce a local Cosign state first so you could accept the terms permanently.

[haydentherapper]

Chatted with Zack about this, summary of a few ideas from the chat:

• Each prompt should be "pre-answerable" using a unique CLI flag (--accept-terms, --allow-private-container-upload)
• We should have a Cosign config file which lets you define the values for each flag. Hopefully should be easy to add, mapping a flag to an env var to a config value
• We should rename --yes to something like --accept-defaults. It should be very clearly documented what this does (skips all prompts, push for private containers, may in the future permit other behavior unexpectedly)
• The default value for the ToS prompt should be no, forcing explicit consent (note that it currently is)

Shouldn't have to worry about deprecations for any of these changes. We'll alias --yes and remove it later, but no need to prioritize that.

[favonia]

• We should rename --yes to something like --accept-defaults. It should be very clearly documented what this does (skips all prompts, push for private containers, may in the future permit other behavior unexpectedly)

Hi, I'm a bit confused by the specification of --accept-defaults. The default values of the ToS prompt is no, and so --accept-defaults will reject the ToS. Is that correct? If so, aliasing --yes (that should probably accept the ToS) to --accept-defaults (that should probably reject the ToS) seems to be wrong.

[haydentherapper]

We chatted about that too, probably need a different name. The goal is some flag that bypasses all prompts

[znewman01]

Thanks for mentioning that, @favonia. Yeah, I think the goal here is:

1. Provide a flag you can pass to make sure Cosign never hangs by doing something instead of prompting.
2. Make it really obvious what the behavior of that flag is (--yes isn't great for that).
3. Make that flag not accept the terms of service, as you haven't really accepted the terms if you didn't look at them.
4. Transitioning to the end-goal state smoothly.

We probably need to bikeshed a little (e.g., we should replace rather than rename --yes) but I think the core ideas are right.

[favonia]

Suggestion: can we put the ToS on https://oauth2.sigstore.dev/auth/device so that we can log in AND agree with the ToS at the same time?

[znewman01]

I think that's a great idea, but there's a catch: the OAuth URL doesn't capture all of the flows that might result in something being uploaded to a transparency log (there's Rekor and also ambient-credential-based OAuth flows). I'd also be worried that it'd be easy to miss.