Adds python script which compares the issues pysa detects in delibrately_vulnerable_app and raise exceptions (return an error) when there is a mismatch. The output is also out and compared with diff if there is a mismatch.

Adds a github action called pysa that compiles pyre-check from the source code in the repository using ocaml, opam, and dune, runs setup.sh, and the run_integration_tests.py python script.

Modifies ./scripts/setup.py to build a Makefile without tests.

Significant attention has been given to make sure we cache as many dependencies as possible thereby making sure the action can run as quickly as possible.

Adds full_results.json that will contain issues known to be true in the app. For now, it's just issues from rce.py, but can be expanded later on as more vulnerabilities are added to the flask app.

The python script, run_integration_tests.py uses integration_test_utils.py to reads issues in resulsts.expected, run pysa, compare issues generated by pysa against those specified manually.

run_integration_tests.py and its supporting integration_test_utils.py script reside at a new folder: ./tools/integration_tests/.

Modifies .pyre_configuration to exclude checking the folder.

Adds .gitignore containing list of directories generated by running pysa and those files generated by running run_integration_tests.py

Modifies setup.sh to tailor to the github actions by creating a .pyre_configuration file with taint_models_path pointing to ../../stubs and copy the integration test utils to the folder of the delibrately_vulnerable_flask_app. setup.sh is referenced during the github action as mentioned above.

Adds requirements.txt to contain requirements for the flask app. Currently it contains only flask but will be expanded later when more vulnerabilities are added to flask app.

Fixes https://github.com/MLH-Fellowship/pyre-check/issues/11

Bumps acorn from 5.7.3 to 5.7.4.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Adds a pysa quick command: init-pysa, that helps users setup a suitable environment to run pysa. It handles commonly found issues in pysa and creates the best possible environment while handling some of the edge cases.

Test Plan

• create (or enter into the directory of) a python project you'd like to run pysa on
• install pyre from source (see installation docs) (suitably create an alias for the client)
• run pyre init-pysa

Preview:

Signed-off-by: Abishek V Ashok [email protected] Fixes: https://github.com/MLH-Fellowship/pyre-check/issues/80

Bumps lodash from 4.17.15 to 4.17.19.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Here are the sinks and the type definitions for the mysql.connector. With these files, Pyre is able to find all three SQL injection vulnerabilities in the following example: unsafe-mysql-py.zip

Fixes https://github.com/facebook/pyre-check/issues/411

Creating a copy of Pyre's language server and server handler for Pysa. After having two separate language server classes, I will introduce logic for the -tool command that will use a different language server based on arguments passed with the persistent command.

Expected outcome for this PR is to display and highlight errors for .pysa files, via the Pysa VSCode Extension. This is part of the larger issue of creating a VSCode extension for Pysa in the MLH-Fellowship program listed here and has been discussed with @gbleaney before.

Possible milestones:

• [X] Make template extension code for Pysa by cloning Pyre
• [X] Add new functions necessary for handling model validation errors to pysa_server.py and persistent.py
• [X] Connect everything and call get_invalid_taint_models() in query.py
• [X] Make relevant changes on the extension side
• [x] Clean up the server of old Pyre code

Output so far:

Errors are being calculated but are not being published due to server_state.opened_documents list being empty as show in the output. The publishing diagnostics function iterates over this list and sends the errors to VSCode. It's empty right now and hence, the errors are never published. (Opening/closing documents is not being detected)

0.0.22 is not crashing, however. This is on an Ubuntu 18.04 (x64) system using Python 3.7.3

Here's the output I see on a --debug run of 0.0.24:

2019-04-29 09:51:04,729 WARNING Could not parse 22 external files due to syntax errors!
2019-04-29 09:51:04,829 PERFORMANCE Stubs parsed: 8.907000s
2019-04-29 09:51:40,474 INFO Parsing 136 sources in `/redacted`...
2019-04-29 09:51:40,577 PERFORMANCE Sources parsed: 0.142000s
2019-04-29 09:51:40,578 PERFORMANCE Registered ignores: 0.063000s
2019-04-29 09:51:40,580 INFO Adding environment information to shared memory...
2019-04-29 09:51:40,580 PERFORMANCE Added environment to shared memory: 0.001000s
2019-04-29 09:51:40,681 INFO Building type environment...
2019-04-29 09:53:57,634 ERROR Client exited with error code 1:
Exception: SharedMem.C_assertion_failure("hh_shared.c : 1072")
Potential backtrace:
Raised at file "map.ml", line 131, characters 10-25
Called from file "sexp_conv.ml", line 148, characters 10-37
Worker exited (code: 2)
Exception: SharedMem.C_assertion_failure("hh_shared.c : 1072")
Potential backtrace:
Raised at file "map.ml", line 131, characters 10-25
Called from file "sexp_conv.ml", line 148, characters 10-37
Worker exited (code: 2)
Exception: SharedMem.C_assertion_failure("hh_shared.c : 1072")
Potential backtrace:
Raised at file "map.ml", line 131, characters 10-25
Called from file "sexp_conv.ml", line 148, characters 10-37
Worker exited (code: 2)
Exception: SharedMem.C_assertion_failure("hh_shared.c : 1072")
Potential backtrace:
Raised at file "map.ml", line 131, characters 10-25
Called from file "sexp_conv.ml", line 148, characters 10-37
Worker exited (code: 2)
Worker interrupted with signal: sigpipe
Worker interrupted with signal: sigpipe
Worker interrupted with signal: sigpipe
Worker interrupted with signal: sigpipe
Worker interrupted with signal: sigpipe
Worker interrupted with signal: sigpipe
Worker interrupted with signal: sigpipe
Worker interrupted with signal: sigpipe
Worker interrupted with signal: sigpipe
Worker interrupted with signal: sigpipe
Worker interrupted with signal: sigpipe

Let me know if I can provide any more info. I've reverted to 0.0.22 to continue using pyre in the meanwhile.

Modifies pyre sandbox and adds in support for running pysa. This is done by modifying how the Pyre object is created and by adding an additional analyze endpoint to the flask app. Adds support for adding user-defined as well as the open source models for pysa.

Signed-off-by: Abishek V Ashok [email protected]

Test Plan

• Pull in #509 and then build the frontend with

cd documentation/website
yarn install
yarn start

• Build and run the backend in a virtual environment:

python3 -m venv ~/venvs/sandbox
source ~/venvs/sandbox/bin/activate
cd tools/sandbox
export PYSA_PLAYGROUND_STUBS=<path-to-your-pyre-check-repo>/stubs
pip3 install -r requirements.txt
python3 application.py --debug

• Goto http://localhost:3000/pysa-playground and play around in the playground

Signed-off-by: Abishek V Ashok [email protected] Fixes https://github.com/MLH-Fellowship/pyre-check/issues/79

Adds publishable github action that others can include into their github actions that enables users to run pysa via github actions.

The action is a composite github action that installs pyre-check, runs pysa, and expose the results in SARIF format by creating sarif.json at the repository root using fb-sapp.

Adds instructions to run the action in documentation/pysa_github_action/README.md

Signed-off-by: Abishek V Ashok [email protected] Fixes: https://github.com/MLH-Fellowship/pyre-check/issues/13

See it in action: https://github.com/abishekvashok/zulip/actions/runs/1149735960

I'm testing Pysa to detect vulnerabilities in my flask web application, but i can't add flask_mysqldb commands as Pysa sinks. If i run pyre analyze --no-verify Pysa doesn't detect this as a vulnerability

from flask_mysqldb import MySQL

db = MySQL(app)

email = request.form['email']
cursor = db.connection.cursor()

query = "SELECT * FROM accounts WHERE email ='"+email+"'"
cursor.execute(query)

Should i add a new sink in .pysa files in taint folder ?

Pyre Bug

Bug description Pyre doesn't understand the two argument form of enum.Enum

Reproduction steps

import enum

Color = enum.Enum('Color', ['Red', 'Blue'])
print(Color.Red)

Expected behavior It typechecks

Logs

$ pyre
ƛ Found 2 type errors!
a.py:3:8 Too many arguments [19]: Call `enum.Enum.__new__` expects 1 positional argument, 2 were provided.
a.py:4:6 Undefined attribute [16]: `enum.Enum` has no attribute `Red`.

Rage: https://gist.github.com/a5ac7a79e8896f73521a02e91838bec2

Bug description As pyre is quite strict with the type narrowing of non-final attributes (which I don't mind), I want to use the walrus operator to make the type narrowing more convenient, but it doesn't seem to play nice with isinstance().

Reproduction steps

from dataclasses import dataclass

@dataclass
class A:
    x: str | int

    def f(self) -> int:
        if isinstance(y := self.x, int):
            reveal_type(y)  # Revealed type for `y` is `typing.Union[int, str]`.
            reveal_type(self.x)  # Revealed type for `self.x` is `typing.Union[int, str]`.
            return y + 2  # Error: `+` is not supported for operand types `typing.Union[int, str]` and `int`.
        return 0

Expected behavior The type of y should be int because I just narrowed it.

Actual behavior The type of y is not narrowed.

Additional context It works fine in mypy and pyright.

Furthermore, the following works fine in pyre:

from dataclasses import dataclass

@dataclass
class B:
    x: str | int

    def f(self) -> int:
        y = self.x
        if isinstance(y, int):
            reveal_type(y)  # Revealed type for `y` is `int`.
            reveal_type(self.x)  # Revealed type for `self.x` is `typing.Union[int, str]`.
            return y + 2
        return 0

pyre version

Binary version: d4aef6ea269d577faf9a2a503032fda33f725936
Client version: 0.9.17

Pyre Feature Request

Having custom config files for each tool is fine. Since most tools use pyproject.toml file for configuration, if pyre supports configuration using it, it would be great.

Pyre Bug

Bug description

Some decorators change the type of the decorated function's inputs. Because there is no easy way to describe a "mapping" over a ParamSpec, such decorators may be typed with a series of overloads, one for each number of parameters up to a reasonable maximum:

@overload
def boxed_args(
    func: Callable[[_P1], _R],
) -> Callable[[Box[_P1]], _R]:
    pass

@overload
def boxed_args(
    func: Callable[[_P1, _P2], _R],
) -> Callable[[Box[_P1], Box[_P2]], _R]:
    pass

@overload
def boxed_args(
    func: Callable[[_P1, _P2, _P3], _R],
) -> Callable[[Box[_P1], Box[_P2], Box[_P3]], _R]:
    pass

...

When such a decorator is applied to a function with default values for one or more parameters, Pyre selects the first matching overload for the decorator, i.e. the overload with only the required parameters. It then forgets about the parameters with default values:

# inferred type (Box[str]) -> None
@boxed_args
def takes_str_and_default_int_decorated(p1: str, p2: int = 404) -> None:
    print(p1, p2)

# does not typecheck
takes_str_and_default_int_decorated(Box("Luc"), Box(0))

Reproduction steps

Complete example on GitHub

#!/usr/bin/env python3

from abc import ABC
from functools import wraps
from typing import Any, Callable, Generic, TypeVar, overload

_T = TypeVar('_T')


class Box(ABC, Generic[_T]):
    def __init__(self, value: _T):
        self.value = value


_P1 = TypeVar('_P1')
_P2 = TypeVar('_P2')
_P3 = TypeVar('_P3')
_R = TypeVar('_R')


@overload
def boxed_args(
    func: Callable[[_P1], _R],
) -> Callable[[Box[_P1]], _R]:
    pass


@overload
def boxed_args(
    func: Callable[[_P1, _P2], _R],
) -> Callable[[Box[_P1], Box[_P2]], _R]:
    pass


@overload
def boxed_args(
    func: Callable[[_P1, _P2, _P3], _R],
) -> Callable[[Box[_P1], Box[_P2], Box[_P3]], _R]:
    pass


def boxed_args(func: Callable[..., _R]) -> Callable[..., _R]:
    @wraps(func)
    def wrapper(*args: Any) -> _R:
        return func(*(arg.value for arg in args))

    return wrapper


def takes_str_and_default_int(p1: str, p2: int = 404) -> None:
    print(p1, p2)


@boxed_args
def takes_str_and_default_int_decorated(p1: str, p2: int = 404) -> None:
    print(p1, p2)


if __name__ == '__main__':
    # typechecks successfully
    takes_str_and_default_int("Typechecker", 1)
    # does not typecheck
    takes_str_and_default_int_decorated(Box("Luc"), Box(0))

Install Pyre (I'm using it through Poetry, with poetry add --group dev pyre-check; poetry run pyre init). Run with pyre (or poetry run pyre).

Expected behavior

The inferred type for the decorated function should be overloaded based on each matching overload of the decorator. In the example above, the decorated function should have a type equivalent to (Box[str]) -> None overloaded with (Box[str], Box[int]) -> None.

Logs

ƛ No watchman binary found.
To enable pyre incremental, you can install watchman: https://facebook.github.io/watchman/docs/install
ƛ Defaulting to non-incremental check.
ƛ Found 1 type error!
sandbox/__init__.py:63:4 Too many arguments [19]: PositionalOnly call expects 1 positional argument, 2 were provided.

pyre_rage.log

Additional context

mypy and Pyright both have very similar bugs; discussion at python/mypy#14144 and microsoft/pyright#4211 may be relevant if this is a weakness in the Python type system rather than in Pyre's implementation.

Pre-submission checklist

• [ ] I've ran the linters locally and fixed lint errors related to the files I modified in this PR. You can install the linters by running pip install -r requirements-dev.txt && pre-commit install
• [ ] pre-commit run

Summary

Test Plan