-
Notifications
You must be signed in to change notification settings - Fork 549
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add privacy statement for PII storage #1909
Conversation
dbc610b
to
2677f8d
Compare
@bobcallaway @dlorenc @lukehinds - Please take a look and let me know if this seems satisfactory. |
Codecov Report
@@ Coverage Diff @@
## main #1909 +/- ##
==========================================
- Coverage 34.14% 34.07% -0.07%
==========================================
Files 153 153
Lines 9949 9969 +20
==========================================
Hits 3397 3397
- Misses 6172 6192 +20
Partials 380 380
Continue to review full report at Codecov.
|
cc @znewman01 as well Looks great to me, thanks! |
LGTM, let's just let it sit for a business day before merging. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I worry some folks will get in the habit of passing -y
always to skip this prompt, but then they'll also skip some other prompt that doesn't show up every time.
Can we add a way to skip just this prompt? Maybe an environment variable COSIGN_ACCEPT_PII_NOTICE=1
or something?
How do other CLIs handle this when they add a new feature that requires confirmation, but also support a flag that skips confirmation? Is an environment variable per confirmation a standard practice? To me, a “y” flag seemed more in line with the typical CLI interface. FWIW, the other feature using a confirmation is a destructive operation, with its own flag. I’d say that would be a good practice to follow - a unique flag for destructive, but a single flag for skipping simple acknowledgements. Thoughts? |
I tend to like a lot of the guidelines at clig.dev for this.
That seems smart to me. In general, here's what I'd like to see (but I'm okay with variations here!):
In this case, I think I'd rather make the difference between displaying this message or not "am I interactive?" rather than "what flow am I using?" |
I can move the check up to what calls |
79529f5
to
ed04700
Compare
Updated the code based on the comments - The message is now always printed, and only in an interactive session the user is prompted for input. |
ed04700
to
3911422
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, my other comments in this review are just nits
This statement has been added just before the OIDC code/normal flow, since only in this flow we expect a user to be present. For the device flow or when a token is provided, it's likely that Cosign is being run in an automated environment. This requires the user either type Y or provide a global flag for confirmation. This should not break any existing flows in automated environments because it's only the flow when a browser is needed, not for the device flow or when a token is provided. Signed-off-by: Hayden Blauzvern <[email protected]>
10e050d
to
6dcddd1
Compare
Thanks for the reviews! This should address all of the comments - Added a second function, and changed to y/N (also handles both Y and y) |
This statement has been added just before the OIDC code/normal flow,
since only in this flow we expect a user to be present. For the device
flow or when a token is provided, it's likely that Cosign is being run
in an automated environment.
This requires the user either type Y or provide a global flag for
confirmation. This should not break any existing flows in automated
environments because it's only the flow when a browser is needed, not
for the device flow or when a token is provided.
Signed-off-by: Hayden Blauzvern [email protected]
Summary
Ticket Link
Fixes
Release Note