sops
sops copied to clipboard
getsops
using flag `--set` on new root level key, creates a new file with just the added key
Version
sops 3.1.1
Bug behaviour
When using sops --set '["some-key"]["nested-key"] "some-value" secrets.yml' where some-key does not exist at the root level of secrets.yml and the file is rewritten with only the keys in the command.
Expected behaviour
The new key is added to the top level, with the nested key(s) and the existing keys in the file.
Discussion
It seems this is the intended behaviour based on https://github.com/mozilla/sops/issues/336. The difference is that nested-key causes the bug.
This is most certainly not intended, and what you describe as the expected behavior is what should happen. Marked as a bug, thanks for the report!
The PR linked to this issue looks like a good fix, and this bug is causing some serious pain (at least for me!). Is there an average time that a PR can be expected to take to get through review?
It would be a shame to have to look for a workaround of my own if this isn't likely to be released any time soon 🙁
I've found a workaround: first set the top-level key to any string value (not object), and then proceed with setting your nested value(s):
sops --set '["some-key"] "irrelevant-value-it-will-be-overridden-with-the-below-command"' secrets.yml
sops --set '["some-key"]["nested-key"] "some-value"' secrets.yml
@krzema12 that's a nice workaround, as long as you also can detect whether the top level key exists first. If the key did already exist, your proposal would first wipe out the entire contents of the existing key (which could be an extensive nested structure) before writing only the new value. This is one step better than obliterating the entire file, but still potentially fairly destructive.
Also, for completeness, the proposed work-around can be achieved in a single command be specifying the nested structure as an object:
sops --set '["some-key"] {"nested-key": "some-value"}' secrets.yml
This has the same problem as the workaround proposed above, in so much as it will obliterate any existing contents of 'some-key' and write just the specified object.
I currently use the above workaround, along with documentation that makes it very clear that any additional nested data added to the file is likely to be obliterated at any time. This is obviously not ideal, especially considering a relatively simple fix is ready and waiting to be applied.
#899 also works for me (found this issue after searching when --set deleted everything from a file!)
I can see that it's slated for v3.8.0, but that has no date - do we have a rough idea of when this fix will be released please?
