sops: Question: How to manage merge conflicts with MAC signature

As the original author of Sops and manager of the team in charge of it, I can say this: Sops is actively maintained and in heavy use in major services. It will continue being maintained for the foreseeable future.

We implement the features that we need for our own use cases at Mozilla. We also provide feedback and guidance to contributors who wish to implement the features they need for their own use cases., while keeping the project and code base sane and maintainable.

Unlike other secrets management tools, we do not have a business model around Sops. As a result, we do not provide free engineering services. If someone wants a fix for their own use case, they need to implement it themselves. This is usually how open source works, and it doesn’t make Sops a lesser tool, but if you were hoping for free beer, sorry, we don’t have any.

It is possible to create an alias to ease the regeneration of MAC without having to open interactively an editor.

alias sops-regen-mac='EDITOR="vim -es +'"'"'norm Go'"'"' +'"'"':wq'"'"'"  sops --ignore-mac'

However this will regenerate the MAC even if there is no mismatch in the target file. It might be recommended to only to do it for files that do have mismatches.

#!/bin/bash

set -o errexit
set -o pipefail
set -o nounset

find . -name '*.enc.yaml' | while read -r file;
do
    sops -d "$file" >/dev/null 2>&1 && rc=$? || rc=$?
    # In case of MAC mismatch, then MAC is regenerated
    # See https://github.com/mozilla/sops/blob/v3.6.1/cmd/sops/codes/codes.go#L19
    if [ $rc -eq 51  ] ; then
      echo "Regenerating sops MAC for: $file"
      EDITOR="vim -es +'norm Go' +':wq'"  sops --ignore-mac "$file"
    fi
done

In our team, our git branching workflow handles the MAC mismatch git conflict in pull-requests and it is the task of authors to resolve/regenerate a correct MAC within their PRs. It is for sure a thing more to take care of but it helps to ensure file integrity.

I’m using SOPS via Helm Secrets. Is there a way to turn on --ignore-mac via a sops.yaml file or some global config?

Also, I can’t believe this isn’t a bigger issue. We ran into this almost immediately, and we’re not even that big of an engineering team.

up

That there is no significant development is very debatable. We still review and welcome PRs from contributors and have merged a few features lately. Just because a feature on your personal wishlist has not been implemented it doesn’t mean that the project is not maintained.

Vault is a completely different beast from sops. If it fits your use case, great! But I don’t see how Vault makes this problem any better. In fact, I think it makes it worse. If there’s a conflict in Vault, data is just lost, no?

So do we. You also have a very small team.

An excellent tool that doesn’t work for medium-sized teams or medium-sized files is actually not so excellent. 😦

If you have more than 10 people not only accessing, but also editing the same secrets, I think you have a much bigger problem than SOPS not handling merge conflicts well. But again, your use case might be very different than the use cases I imagine for SOPS. Can you go into why this is the case more? It might be good to have a section in the documentation titled something along the lines of “Is SOPS for you?”.

Checking the MAC while decrypting makes sure that these files weren’t tampered with after they were copied out of your repo.

Checking MAC is not enough because somebody could still roll-back to an old (possibly compromised) version of the file and MAC checking would still pass. If you worry if files are exactly the version you intend, then simply doing hash comparison of original file and destination file before deploying is good enough and it solves both the attack you are describing as MAC protecting against and roll-back attack.

I strongly disagree with that. (I won’t comment on this any further in this issue though, since this is getting more off-topic IMO.)

Interesting. I think that makes sense, but I’m not convinced that’s a problem that sops itself should be solving. IIUC, whether this problem exists (and if it’s something you care about) really depends on your architecture and how many “steps”/“layers” exist between your git repos that hold sops files and the actual places where the sops binary gets invoked to decrypt those files.

By anology with code: code is also part of git repositories, but also exists outside of them (for example, when building a docker image, .deb file, python package, etc, and uploading that artifact somewhere). Is it absolutely true that we should worry about those artifacts getting tampered with, but that’s not something we try to solve by signing the source code: instead, the trusted server/human that reacts to git commits and does the building/copying is responsible for signing the generated artifact.

I agree with @autrilla . Allowing the user to disable security every time is a bad idea. I like this approach better:

I suppose we could write a sops mergetool command that does the merge for you, checking the MAC of each of the branches, and then opening the (diffed) decrypted files in your editor and reencrypting the result.

Alright, I explored git-mergetool. Unfortunately, we would need to have users set up .git/config with a [mergetool "sops-mergetool"] to get it working. That being said, the gist is now focused on git-mergetool and feels like a good experience (after the .git/config):

https://gist.github.com/twolfson/962b1eb776ce9947a09d4924d91fd8b2/1978689a51b7b2f388121fe71a530eae145863fa