--rotate --in-place results in empty file if user cannot decrypt

[hobti01]

Related to #365 , the following scenario results in an empty file (unexpected) instead of a failure (expected) or no action:

• create .sops.yaml:

creation_rules:
  - path_regex: test.yaml
    key_groups:
      - pgp:
        # userA
        - FD43E10B0D145AA3E865E3088554CA96EF7FF338
        # userB
        - 75385B17ADC57E09BA14A523A7208B9C8B55CCB8

• create test.yaml

$ sops test.yaml

• modify .sops.yaml, removing userB (yourself)

creation_rules:
  - path_regex: test.yaml
    key_groups:
      - pgp:
        # userA
        - FD43E10B0D145AA3E865E3088554CA96EF7FF338

• update keys

$ sops updatekeys -y test.yaml
...
2019/06/26 09:57:28 File test.yaml synced with new keys

• rotate data key to remove access for removed user

$ sops -r -i test.yaml ; echo $?
0
# I would expect 'Failed to get the data key required to decrypt the SOPS file.' and no change to test.yaml
$ cat test.yaml
$

The purpose of rotating the data key after updating the user keys is to prevent removed users from decrypting the files.

Am I approaching this the wrong way?

[chrko]

This has been "accidentally" fixed in https://github.com/getsops/sops/pull/1391/files#diff-774985986bb4d9a68a16d022fd494dfec2de4d2e21bfd35a450cb2839c7438b2R872 and now being part of the main branch: https://github.com/getsops/sops/blob/7880ef47109534560f6ee2d5183d8783aa7e5600/cmd/sops/main.go#L967-L981

[felixfontein]

That commit did not touch the --rotate functionality. It was fixed by 871d10fe2edde6c385e0ce069480d717da0848a6 instead IIRC. That fix closed #855, which was a duplicate of this.

Closing for that reason. Thanks for noticing that this has been fixed!