Mozilla SOPS is all fun and games until someone has to fix a merge conflict in an encrypted file 😂

[m0un10]

Any guidelines for handling this...

I can only think of two ways to prevent this...

1. Do trunk-based dev, so that devs are discouraged from long running branches
2. Use multiple files where possible to reduce the likelihood that two people will want to change the same file around the same time. e.g. don't have an uber sops file with all secrets in it, break it down to keep things that change for different reasons in different files

Actually fixing the conflict will (presumably) involve decrypting both versions followed by creating a new version that merges both changes. Probably quite a bit of faffing about to do this.

Probably fair to say, it's all an edge case that is only really caused by bad practices but one thing for sure, it is certainly painful fixing merge conflicts in SOPS files.

[renannprado]

One should rebase and modify the most up to date version before sending PR/merging.

[m0un10]

That's right. They would still need to fix the conflicts on their branch though and I don't think it would be able to be done like a conventional conflict fix. E.g. just editing the changes to select what to keep from theirs and mine will result in a broken file from a sops perspective.

[Enrico204]

Maybe configuring git to show plaintext diff may be a solution? I never tried: https://github.com/mozilla/sops#showing-diffs-in-cleartext-in-git

[renannprado]

That's right. They would still need to fix the conflicts on their branch though and I don't think it would be able to be done like a conventional conflict fix. E.g. just editing the changes to select what to keep from theirs and mine will result in a broken file from a sops perspective.

There's no conflict when you edit & apply your changes on top of the newest version of the sops file. It could be that there's a clever way of dealing with this, I'm not sure how much @Enrico204's suggestion helps, but IMHO this just seems more like a git basics question rather than sops question given that you can't modify sops file without the sops binary because it breaks the file.

[sochotnicky]

I think the problem that @m0un10 was trying to describe (and I've hit as well is following situation:

• You create a new feature branch to add a new service etc in the process you modify sops file. You put it up for review let's say...
• In the meantime a colleage is finished with their own change and their sops edits are merged into main branch
• Now you have to rebase on top of their changes. The rebase fails since the file is encrypted

In those situations what I had to do was to manually reapply all my original changes. Which was a PITA. I had to copy my original edits elsewhere and then copy-paste them back onto the edited file. I suppose that is what the question is about - is there a nicer/recommended workflow for dealing with this situation.

[felixfontein]

Git should already mostly merge the two encrypted files (assuming you didn't modify entries next to each other, then you'll have to fix them up manually, but that's not sops specific). The only problem are the conflicts for lastmodified and mac in the sops metadata. Simply pick one of the two values, decrypt the file with --ignore-mac, and re-encrypt. That should do the trick. That's still not perfect, but a lot better than manually re-applying changes :)

[sochotnicky]

Git should already mostly merge the two encrypted files (assuming you didn't modify entries next to each other, then you'll have to fix them up manually, but that's not sops specific). The only problem are the conflicts for lastmodified and mac in the sops metadata. Simply pick one of the two values, decrypt the file with --ignore-mac, and re-encrypt. That should do the trick. That's still not perfect, but a lot better than manually re-applying changes :)

Yeah, what you describe is what I meant as "manually reapplying". I suppose you are right that it's mostly just about removing the sops metadata pieces. The trouble was that the first time I encountered it, I didn't know about --ignore-mac switch. So took a bit of time.

I guess it should be possible to have a git hook that would detect this situation and auto-resolve it. Or perhaps better for sops to detect git conflict strings and offer to resolve them in the way you describe.