Endless loop in controller on invalid base64 encrypted data

[catac]

It seems that improperly encoded base64 encryptedData causes an endless loop in the controller. For example:

apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
  name: brokenss
spec:
  encryptedData:
    foo: foo1foo
    bar: bar1bar

As soon as this kind of broken sealed-secret is added, controller will log each second a new message like this:

E0725 15:10:11.704525       1 reflector.go:205] github.com/bitnami-labs/sealed-secrets/cmd/controller/controller.go:155: Failed to list *v1alpha1.SealedSecret: v1alpha1.SealedSecretList.Items: []v1alpha1.SealedSecret: v1alpha1.SealedSecret.Spec: v1alpha1.SealedSecretSpec.EncryptedData: decode base64: illegal base64 data at input byte 4, error found in #10 byte of ...|:"bar1bar","foo":"fo|..., bigger context ...|0000001"},"spec":{"encryptedData":{"bar":"bar1bar","foo":"foo1foo"}}},{"apiVersion":"bitnami.com/v1a|...

Unfortunately, this blocks the processing of any other sealed-secret added afterwards. The only way to break the loop is to delete the broken sealed-secret.

I tried looking in the code for a way to catch the base64-decoding error and consider the sealed-secret broken, as when the key doesn't match. But it seems this happens too deep in the call stack. The only way I found to "fix" the problem was to change the type of the encryptedData field in the SealedSecretSpec struct to string instead of []byte so that we control the base64-decoding. You can find here the full set of changes for this.

Please let me know if this approach is ok for you and I'll be happy to adapt the code to your comments and come back with a PR. Or maybe you see a better approach?

Thanks!

[mkmik]

@catac thank you very much; I can't think of a better approach; accepting the PR

[catac]

Wow, that was fast! Thanks a lot!