Added a way to ignore MAC validation to the decrypt package

[ricje]

The CLI provides a way to skip MAC validation which was not mirrored to the decrypt package.

Simply adding a way to duplicate what can be done using the sops CLI with the --ignore-mac flag.

[autrilla]

Why do you want this? Ignoring MAC validation is rarely a good idea. Without getting into the implementation, I would prefer not supporting this unless you have a good use case, since it's dangerous.

[ricje]

Without going into too much technical details, our encrypted Json goes through an Unmarshal/Marshal step before we can decrypt it. Since this step changes the fields ordering, the original Json and pre-decrypt one will be different causing a validation error.

I understand that this validation pass is the default and that it should stay that way. But, with that said, my use case is still there and, I think that by duplicating a feature that is already provided in the CLI with the --ignore-mac flag is a clean way to uniformize the feature set between the CLI and the library.

[ajvb]

While I do agree that in nearly all cases we should have feature parity between the cli and the library, I do agree with @autrilla. In my mind, using --ignore-mac is something that should only be used in the case of fixing a problem that has occurred, not something for regular use.

Nonetheless, if you feel comfortable ignoring the MAC for your use case, so be it, but I don't think we should support this within the library.

[ricje]

Thank you, I'm closing the PR.

[ghost]

I can't see a strong reason to have a different interface between CLI and the library. If the option should not be used or if it is dangerous then the CLI probably also shouldn't have the option, but it does. I think the reason the option exists is because there are valid use cases for when --ignore-mac is useful/necessary.

Basically the option is useful in any situation when the encrypted data object might be changed by another tool, and where the encrypted data is not affected. For my use case, I am looking at Kubernetes objects that store encrypted data. Kubernetes manages the data object, and as such, adds and mutates parts of the data to achieve its goals. This obviously doesn't play well with the MAC validation.

I don't think it makes sense that the only way to skip the MAC validation is to either use the CLI or to write your own version of the decrypt package that implements an existing feature of the CLI.

[autrilla]

You're not wrong. If someone came today and asked for --ignore-mac on the CLI, we'd probably say no. I can only think of one good use case, and that's merge conflicts. Even that one can be circunvented by decrypting all the conflicting files and merging the decrypted files. Or by just avoiding merge conflicts in the first place.

Basically the option is useful in any situation when the encrypted data object might be changed by another tool, and where the encrypted data is not affected.

But it is affected. Maybe not for the semantics you want, but the file is affected, otherwise the MAC would still be valid. Without going very far into it, I think the approach of such an operator is wrong. Giving Kubernetes a SOPS file directly is bound to be very brittle.

[ghost]

Fair enough. I understand that you don't want to add this option to the library as a way to compel library users to adhere to the integrity constraints that the MAC provides.

I can see the benefits of the MAC, let me see if there is a way I can use this library and keep the MAC intact. Cheers