Sops: [Question] Should decrypting remove _unencrypted suffix?

[davidovich]

I use the _unencrypted suffix to tell sops to leave the values as-is. I was under the impression that rendering these values would remove that suffix from the unecrypted version, but that is not the case.

I think that sops should allow, or default to, removing these suffixes to enhance interop with existing tools. Would this be an acceptable direction?

As I see it, the current workflow is to invoke a scrub after the data is decrypted, but this has to be done for every client of sops that use the _unecrypted suffix.

Having sops scrub these for the user would allow using one file for sensitive and unsensitive matter in one place, with the keys that other tools expect, without post-processing.

[jvehent]

I don't think it's the role of Sops to modify the structure of cleartext documents. If this is something you need in your workflow, a post-decryption script outside of Sops is a better option.

[davidovich]

I would argue that _unencrypted is, in the majority of use-cases, not understood by tools reading an unencrypted structure (unless you are in control of said tools). Sops scrubs out it's sops key already as this impacts the schema for other tools. I would think the same for the suffix. _unencrypted is sops-level metadata, so I believe it should be it's responsibility to remove it (as is done with the sops-key).

[bgagnon]

This seems like a useful feature to have to allow any file to return to its original form prior to the adoption of SOPS. For compatibility reasons, the stripping of the suffix could be opt-in with a boolean as part of the sops top level object.

[fredgate]

The _encrypted and _unencrypted suffixes only make sense for sops, but absolutely not for tools using the decrypted files.
IMHO sops should remove these suffixes, or at the very least allow the possibility to remove it via an option (like --strip-encrypted-suffix and --strip-unencrypted-suffix).

[autrilla]

I know this issue predates #543, but since there's more discussion there already, let's continue it there.