encrypting empty file panics

[jasonkuhrt]

Not a great onboarding experience; in the following I try helm-secrets (which uses sops under the hood) but get a panic.

touch foo.yaml
❯ helm secrets enc foo.yaml
Encrypting foo.yaml
panic: runtime error: index out of range

goroutine 1 [running]:
main.encrypt(0x1a88ce0, 0xc00009a630, 0x2615200, 0x2089cf8, 0x2615200, 0x2089cf8, 0x7ffeefbfe0ef, 0x14, 0xc000064990, 0x1, ...)
	/private/tmp/sops-20190418-79323-1cw3pqc/sops-3.3.0/src/go.mozilla.org/sops/cmd/sops/encrypt.go:66 +0x98a
main.main.func5(0xc000226000, 0x0, 0x0)
	/private/tmp/sops-20190418-79323-1cw3pqc/sops-3.3.0/src/go.mozilla.org/sops/cmd/sops/main.go:483 +0x2ed8
go.mozilla.org/sops/vendor/gopkg.in/urfave/cli%2ev1.HandleAction(0x17f8060, 0x1947088, 0xc000226000, 0x0, 0x0)
	/private/tmp/sops-20190418-79323-1cw3pqc/sops-3.3.0/src/go.mozilla.org/sops/vendor/gopkg.in/urfave/cli.v1/app.go:490 +0xc8
go.mozilla.org/sops/vendor/gopkg.in/urfave/cli%2ev1.(*App).Run(0xc000214000, 0xc0000b8000, 0x8, 0x8, 0x0, 0x0)
	/private/tmp/sops-20190418-79323-1cw3pqc/sops-3.3.0/src/go.mozilla.org/sops/vendor/gopkg.in/urfave/cli.v1/app.go:264 +0x590
main.main()
	/private/tmp/sops-20190418-79323-1cw3pqc/sops-3.3.0/src/go.mozilla.org/sops/cmd/sops/main.go:649 +0x2578
Error: plugin "secrets" exited with error

Maybe a more useful message would be Nothing to encrypt or just make encryption work but it be, well, empty string.

[ajvb]

Thanks for reporting @jasonkuhrt! Seems to be yaml specific.

[fzyzcjy]

Hi the issue seems to still exist...

[Moskovych]

@ajvb , Is this issue planned to be fixed or somehow omitted?
In case of encryption / decryption files in a folder (with loop, etc) with empty files it adds additional complexity for checks.
Additional key, some kind a --skip-empty would be good to have.

[fzyzcjy]

oh almost 3 seasons has passed and the bug is still there, looking forward to seeing it be fixed

[karlschriek]

Also would like to ping on this. Shouldn't default behaviour be output=input in the case where there is nothing to encrypt? It would actually be nice to just run sops recursively on a repo full of manifests and have it look for things to encrypt and leave the rest alone.

[michaeldelago]

For this issue, I just make the yaml file have contents such as:

placeholder: placeholder

Not ideal but it's a pretty simple workaround.

[hwo411]

It seems that it has to be a valid yaml to be encrypted, so you can use {}, since it's an empty object in yaml (like in json)

[cesarjorgemartinez]

I have come to this issue, it is true that it is very uncomfortable to handle these exceptions in automatic processes.

I have broken files in this way:

• Empty files
• Files with only comments, to have them ready to add data

[felixfontein]

I tried to fix this (#1290), but I'm not sure how the behavior should be.

A simple way is to remove the crash (which checks that the first document doesn't have sops metadata - since there are zero documents in this file, it crashes). This results in an encrypted empty file being empty again. Decrypting that empty file isn't possible since it doesn't have sops metadata.

Alternatively the YAML store could be changed to always return at least one document (tree branch in sops internal notation). That would result in a regular sops encrypted file, whose decryption would be {}. If you encrypt {} or a file with only --- in it, you would get the same encrypted file, and its decryption would also be {}.

So - should an empty file be treated as "zero YAML documents", or as "one YAML document that is an empty mapping"?

[felixfontein]

According to the spec, an empty YAML file is zero YAML documents (see https://yaml.org/spec/1.2.2/#92-streams).

[Ph0tonic]

This issue has been fixed by #1290, I just tested it with sops 3.8.1 and it seems to work. Shall we close this issue ?

[zoechi]

Redirecting the output to the file that is encrypted also causes this error.

sops --encrypt some-file.yaml > some-file.yaml

This results in some-file.yaml becoming an empty file.

[felixfontein]

@zoechi that's not very surprising, since some-file.yaml gets cleared due to the stdout redirect before sops is actually started.

Better use sops --encrypt --output some-file.yaml some-file.yaml.

[felixfontein]

Closing since this is fixed. (Thanks @Ph0tonic!)

[cesarjorgemartinez]

¡Genial! El sáb., 25 nov. 2023 21:45, Bastien Wermeille ***@***.***> escribió:

…

This issue has been fixed by #1290 <#1290>, I just tested it with sops 3.8.1 and it seems to work. — Reply to this email directly, view it on GitHub <#483 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA5N2CL6WZ7MYUDFZS6YBULYGJKFXAVCNFSM4HZFC7HKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBSGY2DCNRVGA2Q> . You are receiving this because you commented.Message ID: ***@***.***>