Open ossie-git opened 3 days ago
Hi @ossie-git, thanks for reaching out.
I was able to reproduce the problem, using the uv
tool, which is quite convenient:
$ uvx --python 3.10 --with fb-sapp --with django-stubs --from pyre-check pyre -n analyze --no-verify
# 2 issues
$ uvx --python 3.12 --with fb-sapp --with django-stubs --from pyre-check pyre -n analyze --no-verify
# 1 issue
$ uvx --python 3.13 --with fb-sapp --with django-stubs --from pyre-check pyre -n analyze --no-verify
The problem is indeed in our taint stubs. I have a fix internally, we should be able to merge that in master pretty quickly. Once that is merged and the issue is closed, you should be able to use the pyre-check-nightly
package instead of pyre-check
, until we push a new release.
Thanks @arthaud. Given that this might have resulted in CI/CD pipelines and normal users running pysa missing findings, would it be possible to have these types of errors (signature mismatches) result in pysa failing with a non-zero exit code instead of continuing? A possible option would be to add a command line switch which would allow users to override this. Just a suggestion. Thanks
You should get an error if you are running without --no-verify
. The problem is that you would also get unrelated errors, related to missing stubs. We would definitely want to improve this, but have higher priority work, unfortunately.
Pysa Bug
Pre-submission checklist [X] I've checked the list of common issues and mine does not appear
Bug description
I was going through the practice exercise3 and noticed the following
pyre analyze --verify
eval
) when I runpyre analyze --verify
pyre analyze --verify
In the exercise, we have two sinks:
and we have the following in the predefined
rce_sinks.pysa
:so they should both be detected, even on Python versions higher than 3.11
On 3.12, I would see the following in the output which means that it didn't match
def exec
and claims that there is a signature mismatch:Running:
shows that the signature hasn't changed, but for some reason, pyre thinks that it has.
On 3.13, it did this both for exec and eval
Again, looking at the signature shows that it hasn't changed:
but pyre thinks that it has for some reason. Any ideas? Thanks
Reproduction steps See above
Expected behavior See above
Logs Please run your reproduction steps with
--noninteractive
(eg.pyre --noninteractive analyze
) and paste the output here:Below is the output for 3.13.0
Additional context Add any other context about the problem here. (like dependencies in your venv, third party stub files being used, overall goals, etc.)