-
Notifications
You must be signed in to change notification settings - Fork 482
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
audit fails with custom plugin #611
Comments
Hi @steamraven, thank you for bringing up this issue you encountered. Since it seems to be related to a custom plugin you created, could you provide us with more info about it? This would help us debug and understand what the underlying problem is. |
I have replicated with a minimal plugin: minimal.py:
With just this file in a directory: Then |
Also, with my more useful plugin. This does not seem to be plugin specific, but a race condition in the code to search for plugins themselves. ip_detector.py:
|
@steamraven Hello. I do not think this is a race condition - however I do think there is a bug related to some recent changes. Can you tell me if in your baseline file that you are auditing has any of the following secret types:
|
That pr does not fix it. I generated a baseline using the minimal.py plugin on a folder containing just the plugin itself. The only secrets are "Secret Keyword" and "Nothing". Specifically, the plugins secret type IS in the baseline. It appears audit will fail with ANY external plugin secret type. As I said above, commenting out the lru_cache at
resolves the issue. Unfortunately, it slows down secret detection a lot. I can get you more detailed tracing but it appears that get_mapping_from_secret_type_to_class is called during parameter setup with a generic settings object that has no plugins. Because the lru_cache, this get_mapping_from_secret_type_to_class does not return any external plugins If the lru_cache is removed, it is eventually called with a settings object that has the external plugin |
Here is my baseline: https://gist.github.com/steamraven/8005a93f539ebb9fa25ece4ac9d7a878 |
-- Note that
It appears there is a edited for clarity |
Encountered the same issue. I used my customized plugins to generate a baseline file, detect-secrets scan ./ \
--all-files \
--baseline .detect-secrets/.secrets.baseline \
--exclude-files '^\.git(/.*)?$' \
--exclude-files '^\.detect-secrets(/.*)?$' \
-p .detect-secrets/plugins/absolute_filepath.py \
-p .detect-secrets/plugins/aws_sensitive_info.py \
-p .detect-secrets/plugins/email_address.py \
-p .detect-secrets/plugins/ip_address.py But the newly generated baseline file can not be used for If I don't use the -p argument but directly put my plugins into the |
When running detect-secrets audit against a baseline created with a custom filter, I get a python error
Relevant sections of .secrets-baseline
This appears to be a problem with the lru_cache on "get_mapping_from_secret_type_to_class" in detect_secrets.core.plugins.util. Removing the lru_cache allows this to work, but slowly
The text was updated successfully, but these errors were encountered: