-
-
Notifications
You must be signed in to change notification settings - Fork 626
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
B603 false positive? #333
Comments
B603 is However there can still be a problem: bandit is looking at Bandit doesn't know that Unfortunately bandit isn't a code-flow analysis tool so it can't reason about what It's a false positive but the test is functioning as designed, as a simple linter to warn about possible issues. |
I see your point, but I suppose I'm having trouble how you could possibly use
I still trigger B603. As such this feels more like "don't use subprocess.check_output" rather than "make sure the input to subprocess.check_output is trusted", so it feels like the description of B603 is misleading/not helpful. Or am I missing a way to use |
Actually you're right. My apologies. I checked the code and the test is a bit dumb. It will flag any use of I agree with you that the test should be improved to decrease obvious false positives. |
+1 , also linking this to an another one: #373 . This happens with version |
Bandit reports issues for "subprocess call- check for execution of untrusted input", but in each case it's a false positive, as noted here: PyCQA/bandit#333 The pdp_mafft_wrapper.py script catches STDOUT from MAFFT, and cannot execute anything the user can't already run from the shell. In addition, the command whose output is caught is sanitised before it is used. The test_*.py files have input that is declared in the function and sanitised before use.
It would be easy to change the test to be like Even then the confidence should not be high, which it is currently. |
Is there a timeline when this bug will be fixed? |
How does this help here? The best way seems to lower its confidence down to |
According to project PyCQA/bandit#333, the bandit checker cannot be aware of trusted input defined from variable which is in out case APT_METHOD_HTTP. We turn off the check for this subprocess call.
According to project PyCQA/bandit#333, the bandit checker cannot be aware of trusted input defined from variable which is in out case APT_METHOD_HTTP. We turn off the check for this subprocess call.
According to project PyCQA/bandit#333, the bandit checker cannot be aware of trusted input defined from variable which is in out case APT_METHOD_HTTP. We turn off the check for this subprocess call.
+1 Waiting for the timeline on this issue also, Since it's not helpful to have to introduce |
PyCQA/bandit#333 Signed-off-by: Thomas Sjögren <konstruktoid@users.noreply.github.com>
Related to this issue, the reference https://bandit.readthedocs.io/en/1.7.5/plugins/b603_subprocess_without_shell_equals_true.html
Isn't it a false false positive? |
This has been opened since 2018 — I suppose there's still no way to use |
The message 'check for execution of untrusted input' is triggered by any use of subprocess regardless of the actual input, so even fixed input triggers it. Bandit issue PyCQA/bandit#333 discusses that this is a common false positive triggered by any usage. The pattern is common enough in our code to ignore this to avoid clutter and warning fatigue. We already ignore B404 mentioned in the issue above.
The message 'check for execution of untrusted input' is triggered by any use of subprocess regardless of the actual input, so even fixed input triggers it. Bandit issue PyCQA/bandit#333 discusses that this is a common false positive triggered by any usage. The pattern is common enough in our code to ignore this to avoid clutter and warning fatigue. We already ignore B404 mentioned in the issue above.
The message 'check for execution of untrusted input' is triggered by any use of subprocess regardless of the actual input, so even fixed input triggers it. Bandit issue PyCQA/bandit#333 discusses that this is a common false positive triggered by any usage. The pattern is common enough in our code to ignore this to avoid clutter and warning fatigue. We already ignore B404 mentioned in the issue above.
Describe the bug
I don't understand how I should "check for untrusted input.
To Reproduce
Steps to reproduce the behavior:
With the code:
Gives
Issue: [B603:subprocess_without_shell_equals_true] subprocess call - check for execution of untrusted input
. I don't understand how this is shell equals true given that "shell=False" is passed, nor how this is untrusted input.Expected behavior
This line shouldn't be flagged as a warning
Bandit version
Additional context
The text was updated successfully, but these errors were encountered: