panic: runtime error: invalid memory address or nil pointer dereference when using updatekeys
idlecodinggoats opened this issue · 11 comments
I am trying to update my secrets.yaml with a new set of keys for a different computer and when I run:
sops updatekeys secrets/secrets.yaml
I get:
2024/05/10 19:42:14 Syncing keys for file /path-to-secret/secrets/secrets.yaml
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0xe1c17f]
goroutine 1 [running]:
github.com/getsops/sops/v3/cmd/sops/subcommand/updatekeys.updateFile({{0xc00019e2a0, 0x1f}, 0x0, {0xc00006f4b0, 0x1, 0x1}, 0x1, {0xc0004c86a0, 0xa}, {0x0, ...}})
github.com/getsops/sops/v3/cmd/sops/subcommand/updatekeys/updatekeys.go:54 +0x1df
github.com/getsops/sops/v3/cmd/sops/subcommand/updatekeys.UpdateKeys({{0xc00019e2a0, 0x1f}, 0x0, {0xc00006f4b0, 0x1, 0x1}, 0x1, {0xc0004c86a0, 0xa}, {0x0, ...}})
github.com/getsops/sops/v3/cmd/sops/subcommand/updatekeys/updatekeys.go:39 +0xb8
main.main.func7(0xc000174dc0)
github.com/getsops/sops/v3/cmd/sops/main.go:531 +0x238
github.com/urfave/cli.HandleAction({0xedeb80?, 0x1134960?}, 0xa?)
github.com/urfave/cli@v1.22.14/app.go:524 +0x50
github.com/urfave/cli.Command.Run({{0x10c9e94, 0xa}, {0x0, 0x0}, {0x0, 0x0, 0x0}, {0x1100dd2, 0x34}, {0x0, ...}, ...}, ...)
github.com/urfave/cli@v1.22.14/command.go:175 +0x685
github.com/urfave/cli.(*App).Run(0xc000703180, {0xc000040390, 0x3, 0x3})
github.com/urfave/cli@v1.22.14/app.go:277 +0xb3b
main.main()
github.com/getsops/sops/v3/cmd/sops/main.go:1004 +0x3425
Just so you know, I've changed the path to the secrets.yaml to /path-to-secret.
I'm not quite sure whats going on. Any chance of a hand 😄
Which version of sops are you using?
3.8.1 from nixpkgs unstable, although I’ve checked with nixos-23.11 with the same sops version and nixos-23.05 which is version 3.7.3. Exactly the same results with each.
The problem is probably that no config file was found. In that case, conf is nil, and accessing conf.KeyGroups results in the error you're reporting. Can you check whether you have a .sops.yaml in the same directory as secrets.yaml, or somewhere further up in the tree? My guess is that you don't have such a file, or that it doesn't have any creation rules.
My .sops.yaml is further up the tree, but I haven’t had any trouble until trying to add a new key today. I can also still access secrets.yaml just not update the keys.
Does .sops.yaml contain creation_rules?
Yes, with the ´path_regex’ pointing to ´secrets.yaml$’ and ´key_groups’ containing the age passwords for each corresponding key. I should not that what’s happened is that one of my machines died and I lost the private key so I’ve updated the age value of one of these entries. I don’t think this should be a problem, but just in case.
Sorry about formatting, I’m currently on my phone
Hmm, I checked all possible code paths, the only way I can produce the crash you have is if creation_rules is missing from (or misspelled in) .sops.yaml.
Wow, okay... yes there was an accidental added before keys when I updated the .sops.yaml. Sorry that was such a stupid question - the readout was just too cryptic for me to know where to start. I might make a request to check that the config file can be read without failing and if not a readable error returned.
Thanks for your help and your time.
No worries! SOPS definitely shouldn't crash in that case. I've created #1506 which should fix that. It will tell you something like
The config file ../.sops.yaml does not contain any creation rule
Haha, wow, perfect! Thanks. Just to note, my error wasn't missing creation_rules it was actually missing keys because I had keys instead. But at least with your pull request any future idiots like me will know to look in their config files first 😉
Thanks again. Your help is massively appreciated