Skip to content
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

Merged
merged 3 commits into from
Jun 27, 2024

Conversation

felixfontein
Copy link
Contributor

@felixfontein felixfontein commented Dec 27, 2023

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.

@felixfontein
Copy link
Contributor Author

@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)))
Copy link
Contributor

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?

Copy link
Contributor Author

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 :) ).

Copy link
Contributor

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.

@mitar
Copy link
Contributor

mitar commented Jan 4, 2024

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.

@felixfontein felixfontein marked this pull request as ready for review February 6, 2024 14:03
@felixfontein
Copy link
Contributor Author

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)
Copy link
Member

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?

Copy link
Contributor Author

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.

@Gui13
Copy link

Gui13 commented Apr 7, 2024

This looks good, any idea when this could be merged ?

@felixfontein
Copy link
Contributor Author

It's currently waiting for further reviews / approval by maintainer(s).

@mitar
Copy link
Contributor

mitar commented May 13, 2024

Is there anything to do to push this further?

@felixfontein
Copy link
Contributor Author

Like several other PRs, this is waiting for a review / approval from someone else in @getsops/maintainers.

Copy link
Contributor

@devstein devstein left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, but would be nice to get another review from @hiddeco @onedr0p if possible; otherwise, I can merge

This was referenced Jun 26, 2024
@felixfontein felixfontein added this to the v3.9.0 milestone Jun 26, 2024
Copy link

@sabre1041 sabre1041 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

mitar and others added 3 commits June 27, 2024 09:21
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>
@felixfontein felixfontein merged commit aa800f1 into getsops:main Jun 27, 2024
10 checks passed
@felixfontein felixfontein deleted the pr-974-continue branch June 27, 2024 07:25
@felixfontein
Copy link
Contributor Author

@mitar thank you very much for your contribution! I'm glad it finally got merged...
Also thanks to everyone who helped reviewing and testing this!

@mitar
Copy link
Contributor

mitar commented Jun 27, 2024

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?

@c33s
Copy link

c33s commented Jun 27, 2024

@felixfontein

thank you very much for this awesome feature!

two questions:

  • can you please add a simple example to the readme on how to use this new feature?
  • is it possible to invert the features behavior (encrypt by default and use a comment to keep the value unencrypted)?

@mitar
Copy link
Contributor

mitar commented Jun 27, 2024

README does have some text about this here.

is it possible to invert the features behavior (encrypt by default and use a comment to keep the value unencrypted)?

Yes, you can use unencrypted-regex for that.

@c33s
Copy link

c33s commented Jun 27, 2024

i meant some examples for the config file like:
.sops.yaml

- encrypted_regex: '.'
  unencrypted_comment_regex: 'keep_decrypted'
  path_regex: '*\.yaml$'

file.yaml

foo:
  # keep_decrypted
  bar: 1234
  password: will be enrcypted

oh in missed the --unencrypted-comment-regex. really awesome it can work both ways

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants