I hadn't looked too deeply into the literature there, the paper looks really interesting! We don't have any concrete plans to implement such a system, but I don't think there's any fundamental reason we wouldn't want automatic taint model generation. I'll give the paper a read on Monday to learn more :)
Types will definitely make Pysa find more issues, but you don't need 100% coverage, or really more than the minimal coverage described in that doc I linked, to start finding some issues.
I have 2 questions:
1. The installation doc specified `watchman` as a dependency. Why is that used? without watchman, would pysa not work?
2. Also, why can the pysa become a separate stand alone tool instead of living in the pyre Github repo?
2. Hopefully the answer to (1) helps here. Pysa shares some code with Pyre, including the parallelization infrastructure - the same infrastructure that makes Pyre fast interactively makes Pysa fast on large codebases. Living on the Pyre GitHub repo allows Pysa to use the parallelization infra, in addition to the type checking APIs of Pyre as necessary.
See also our original post introducing Pyre - our goal from the outset was to build a platform for deeper static analyses: https://www.facebook.com/notes/protect-the-graph/pyre-fast-t...
Was that always the name?
Pysa is part of pyre-check and the documentation [0] seems like a lot of work to set up and hope it gets better.
I’m using to using safety [1] and bandit [2] and they are one line drop ins to my builds.
Pysa isn’t the same thing and seems much more powerful but I hope they get to a “Just give me something useful out of the box and I’ll customize my taint scans later.”
[0] https://pyre-check.org/docs/pysa-running [1] https://pypi.org/project/safety/ [2] https://pypi.org/project/bandit/
