Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Fix is_verified not stored in PotentialSecret #578
Fix is_verified not stored in PotentialSecret #578
Changes from all commits
936c440
da42fcc
a071ff1
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this only a testing issue or do we need to somehow enable this in a production mode as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The same issue will be in production as well if the detect-secrets is ran with python 3.6/3.7 in macOS. I didn't want to add
NO_PROXY
in production code as it would lead to ignoring proxy configurations in the environment and the issue doesn't impact most environment. that being said detect-secrets can still be run in impacted environments by either settingNO_PROXY
env variable prior to running it or adding the--no-verify
flag.I think the issue existed prior to this PR it's just that non of the tests invoked Requests APIs from a forked process.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we verify that this was existing in some sort of integration test / brute force testing? I would just like to ensure we are not introducing any new issues to the repository.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've created a draft PR with test data that should invoke Requests API from forked process, the same error occurred
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this is caused by
requests
, could it be the case that a newer version doesn't have this issue anymore? I see we're using2.26.0
, while the latest one is2.28.1
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like requests v2.28.0 dropped support for python 3.6, I tried
requests
v2.27.1 with no luck.It's worth noting that the issue can be fixed if we use
spawn
context for multiprocessing but I think that would come at a performance cost.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right. So python 3.8+ multiprocessing library has switched to spawn where before it was fork. This is an issue since spawn does not share any memory between the parent and child processes. So we default the multiprocessing to fork when creating a pool of processes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we try and use
v2.28.1
. Python 3.6 is end of life. We can consider dropping support for it.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried
v2.28.1
, still the same problem. I think this is more of a python issue than requests, the default context was changed to spawn because of crashes similar to this.Since we are already using default multiprocessing (spawn) for python 3.8+ on macOS, what do you think of checking the current OS and if it's macOS we change to spawn?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, that was the initial attempt to fix it. We decided to try and stay away from being OS specific so instead of changing the default multiprocessing, we instead passed the shared settings to child processes from the parent. So in python 3.8+ we are using spawn which is the default.