High Entropy string matchers have false positives on uuids.

[conartist6]

It should be possible to identify random UUIDs which, though they are hex high entropy strings, are generally not secrets. The combination of length, string formatting, and the version bit should be sufficient to match UUIDs, and at least offer the user a configuration option to consider them false positives and quash reporting on them.

[KevinHock]

We might be able to add this to #245, as it has recently come up for us as well.

On a private branch, I had added

            if len(result) == 36:
                UUID_RE = re.compile(
                    r'^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89AB][0-9a-f]{3}-[0-9a-f]{12}$',
                    re.IGNORECASE,
                )
                if UUID_RE.match(result):
                    continue

in this area

detect-secrets/detect_secrets/plugins/high_entropy_strings.py

Lines 92 to 97 in b21c5f8

	for result in self.secret_generator(string):
	if is_false_positive(result, self.automaton):
	continue
	secret = PotentialSecret(self.secret_type, filename, result, line_num)
	output[secret] = secret

recently, but I didn't fully flesh it out.

[KevinHock]

Could you give an example UUID for posterity @conartist6? I realized on my private branch I had - and other metacharacters in the entropy plugin I was running and so it makes sense how my plugin caught them, but on master right now we don't have -'s in our base64 high-entropy plugin, so I'm curious what part of the UUID we did trigger off of (on master).

[conartist6]

5873b5ea-c5cb-40ed-b206-111bb37195f2

This is a v4 uuid.

[KevinHock]

Thanks! :)

[domanchi]

This should have been closed a while ago. In v1, this is added as a filter as well.