-
Notifications
You must be signed in to change notification settings - Fork 878
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
Support using comments to select parts to encrypt #1392
Conversation
@mitar I think the two comments I added address the issues from my review in #974 (review). Can you take a look at the commits? |
if ok && tree.Metadata.UnencryptedCommentRegex != "" { | ||
// If an encrypted comment matches tree.Metadata.UnencryptedCommentRegex, decryption will fail | ||
// as the MAC does not match, and the commented value will not be decrypted. | ||
matched, _ := regexp.Match(tree.Metadata.UnencryptedCommentRegex, []byte(in.(string))) |
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.
Why not use here MatchString
?
Didn't we say we will also try to match against EncryptedCommentRegex
? So both of them should not match the resulting encrypted string?
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 originally implemented this, and then when trying to test it I removed the code again. As opposed to UnencryptedCommentRegex
, encrypted comments matching EncryptedCommentRegex
aren't a problem since comments are only encrypted/decrypted if they are part of an encrypted subtree that's encrypted due to a comment higher up.
For example, you can encrypt
---
#ENC[AES256_GCM,data:MI3A,iv:c9lHpZCbz3W9ooGuGbmQTcWcXAH7JEL/5JyJdC41dec=,tag:LrQLBEgQayguId5RrNiOCA==,type:comment]
foo:
bar: barbar #ENC[AES256_GCM,data:MI3A,iv:c9lHpZCbz3W9ooGuGbmQTcWcXAH7JEL/5JyJdC41dec=,tag:LrQLBEgQayguId5RrNiOCA==,type:comment]
# something else
baz:
bam: bambam #ENC[AES256_GCM,data:MI3A,iv:c9lHpZCbz3W9ooGuGbmQTcWcXAH7JEL/5JyJdC41dec=,tag:LrQLBEgQayguId5RrNiOCA==,type:comment]
with --encrypted-comment-regex ENC
and then decrypt it again without any problems.
We could still implement the check to be extra cautious, but it isn't needed (or I'm missing something :) ).
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.
OK. I think it is then fine and we can revisit this if anyone finds a realistic case where it is breaking some user flow.
Thanks. I think this looks good as it is already. Thank you for all the work. I made a small comment, but I think it is not critical to do it. |
de3e3ac
to
46c488a
Compare
Now that #1389 has been merged, this is ready for review! 🎉 |
if vIsComment { | ||
// If v is a comment, we add it to the slice of active comments. | ||
// This allows us to also encrypt comments themselves by enabling encryption in a prior comment. | ||
commentsStack[len(commentsStack)-1] = append(commentsStack[len(commentsStack)-1], c.Value) |
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.
Is there (n)ever a theoretical chance of len(commentsStack) == 0
?
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.
That can't happen since in the first line of the function, one element is appended to commentsStack
, and during the execution of this function no value is removed from commentsStack
.
46c488a
to
e55463f
Compare
This looks good, any idea when this could be merged ? |
It's currently waiting for further reviews / approval by maintainer(s). |
Is there anything to do to push this further? |
Like several other PRs, this is waiting for a review / approval from someone else in @getsops/maintainers. |
e55463f
to
0b498e9
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.
0b498e9
to
54298f8
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
Signed-off-by: Mitar <mitar.git@tnode.com>
…ments. Signed-off-by: Felix Fontein <felix@fontein.de>
Signed-off-by: Felix Fontein <felix@fontein.de>
54298f8
to
6cfb8ed
Compare
@mitar thank you very much for your contribution! I'm glad it finally got merged... |
Thank you everyone who was involved into getting this in, and especially you @felixfontein for all the help getting it in. How could I bring #1404 further? |
thank you very much for this awesome feature! two questions:
|
README does have some text about this here.
Yes, you can use |
i meant some examples for the config file like:
file.yaml
oh in missed the |
This PR adds support to annotate comments with a string (e.g.,
sops:enc
) which can then be matched with a regex. If it matches, the corresponding value (the one which follows the comment) is encrypted while other values are not. (There is also the opposite regex available, to select those values which should not be encrypted.)This enables the YAML file to have the same structure encrypted and decrypted, without having to add suffixes or manage complex regexes to match keys. See #543 for more discussion.
(This PR currently contains #1389 and will be rebased once that's merged. It is a lot more likely that #1389 will be merged before this PR or any of its variants, so I decided to use that one as a basis.)This PR continues the work of #974 by rebasing #974 upon #1389 and adding some final touches (see #974 (comment)).
Closes #974.