Audit fails to find non-quoted base64 strings

[domanchi]

Reproduction Steps

$ cat test.file
SECRET_ACCESS_KEY=dGhpcyBuZWVkcyB0byBiZSBsb25nIGVub3VnaCB0byBjcmVhdGUgZW50cm9weQ
$ detect-secrets scan test.file > baseline.json
$ detect-secrets audit baseline.json
Secret:      1 of 1
Filename:    test.file
Secret Type: Base64 High Entropy String
----------
ERROR: Secret not found on line 1!
Try recreating your baseline to fix this issue.
----------
What would you like to do? (s)kip, (q)uit:

But it works if we do:

$ cat test.file
SECRET_ACCESS_KEY="dGhpcyBuZWVkcyB0byBiZSBsb25nIGVub3VnaCB0byBjcmVhdGUgZW50cm9weQ"
$ detect-secrets scan test.file > baseline.json
$ detect-secrets audit baseline.json
Secret:      1 of 1
Filename:    test.file
Secret Type: Base64 High Entropy String
----------
1:SECRET_ACCESS_KEY="dGhpcyBuZWVkcyB0byBiZSBsb25nIGVub3VnaCB0byBjcmVhdGUgZW50cm9weQ"
----------
Is this a valid secret? i.e. not a false-positive (y)es, (n)o, (s)kip, (q)uit:

[OiCMudkips]

Dumping thoughts:

In this example, dGhpcyBuZWVkcyB0byBiZSBsb25nIGVub3VnaCB0byBjcmVhdGUgZW50cm9weQ is being detected as a secret by master, but in the audit view, the plugin can't find it again for some reason. It finds 0 potential secrets with quotes and 3 secrets SECRET ACCESS KEY= dGhpcyBuZWVkcyB0byBiZSBsb25nIGVub3VnaCB0byBjcmVhdGUgZW50cm9weQ, none of which are what was hashed, leading to the error.

I guess the question is how dGhpcyBuZWVkcyB0byBiZSBsb25nIGVub3VnaCB0byBjcmVhdGUgZW50cm9weQ is even being detected as a secret since #203 suggests this shouldn't work.

[KevinHock]

That should be due to how Yaml/ini files are parsed differently, whereas #203 the example was not found in a valid Yaml or ini file. (It was a file w/ no extension too, IIRC)

As an aside, it's worth mentioning I've been meaning to replace the "let's solely look at the line in the baseline" logic for auditing with the "let's run detect-secrets and match the hashed_secret with the baseline" so

• audit doesn't break on stale line numbers (which I think is the case at the moment)
• it'll help us out with the hard part of #92

That would solve this issue I think, but it's a little larger in scope than this issue originally intended.

[OiCMudkips]

I think then the way to fix this would be either: (a) to move some the logic from https://github.com/Yelp/detect-secrets/blob/master/detect_secrets/plugins/high_entropy_strings.py#L50 into https://github.com/Yelp/detect-secrets/blob/master/detect_secrets/plugins/high_entropy_strings.py#L104 (i.e. analyze into secret_generator) since audit uses secret_generator to find and highlight the secret plaintext
(b) change audit to use analyze instead of secret_generator

And now that I read what I'm writing (b) is basically the let's run detect-secrets and match the hashed_secret with the baseline KevinHock mentions above.