-
Notifications
You must be signed in to change notification settings - Fork 940
Add "--value-file" option to "sops set [...]" #1876
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
base: main
Are you sure you want to change the base?
Conversation
a241b77
to
0efd03e
Compare
About the CI failure; I amended the commit to include sign-off. When is CI going to be run again? (It's been 8+ hours.) |
That runs the unit tests; these also pass in CI. What fails are the functional tests (
When someone with appropriate rights presses the buttons. Please remember that we are volunteers who do this in their free time. |
Ok, thanks. I can reproduce the
Oh, sorry, I thought it was automatic, and given the short time spent on "make test" locally I was surprised about 8+ hour latency on github 🙈 |
0efd03e
to
ee2de08
Compare
Functional tests are passing locally now (except for I'll try to create a functional test for the new "--value-file" option tomorrow. |
6e2475f
to
5fe0683
Compare
Hm. The first full Where's the state that makes the test non-deterministic? How to get rid of it? |
It seems test order is random, and some orders work, some does not:
I based the new test, Actually, it might be more nuanced than test order: I ran |
Here's the output of a failing/racy run:
|
Using different filenames from the test you modified can help. |
This allows running "sops set [...]" without leaking secrets in process listings. To read secrets from stdin, use "/dev/stdin" as the file path. Fixes getsops#729 Signed-off-by: Bjørn Forsman <bjorn.forsman@gmail.com>
5fe0683
to
088d677
Compare
Aha, The latest push fixes the tests, by using a unique file name. |
cli.BoolFlag{ | ||
Name: "value-file", | ||
Usage: "treat 'value' as a file to read the actual value from (avoids leaking secrets in process listings)", | ||
}, |
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.
How about adding a (mutually exclusive) further option that reads from stdin instead of a file? That would provide a platform independent way of reading from stdin (/dev/stdin
doesn't work on Windows).
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.
Sure, but that would take some more time for me to implement and test (noob here). Also, isn't that something that can be added on top of this PR and is not in conflict/wrong direction with this change (iow, not a blocker)?
Another option could be to make the "value" argument optional, and if missing, read from stdin. (On Linux it's trivial to pipe file contents to stdin, I don't know about Windows.)
Thoughts?
This allows running "sops set [...]" without leaking secrets in process
listings.
To read secrets from stdin, use "/dev/stdin" as the file path.
Fixes #729
I'm not a go programmer, please review carefully :-)