Skip to content
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

datalog_policy_verifier library is used for too many things. #728

Open
markww opened this issue Sep 21, 2022 · 0 comments
Open

datalog_policy_verifier library is used for too many things. #728

markww opened this issue Sep 21, 2022 · 0 comments

Comments

@markww
Copy link
Contributor

markww commented Sep 21, 2022

The library datalog_policy_verifier, defined in src/analysis/souffle/BUILD, is currently used as a sort of "default" policy verifier library. While that is consistent with its very-general name, it is not consistent with its actual contents. datalog_policy_verifier is actually for the very narrow purpose of performing SQL policy verification from the SQL policy verifier we have integrated with. Its general name is an artifact of history, in that this was the first real analysis that we wrote. This should be renamed to have a more specific name and removed from all analysis other than the SQL verifier integration (and tests of that analysis).

copybara-service bot pushed a commit that referenced this issue Oct 7, 2022
…_verifier.

In the early days of Raksha, we created the `datalog_policy_verifier`. This was before we understood that the Souffle language and the Souffle internal architecture meant that we would have to create a separate library per policy interface, and that having one Souffle library to serve all of our needs probably wasn't going to cut it.

Others coming to the Raksha project saw the name and, quite reasonably, believed it was the generic Raksha analysis rather than a SQL-verifier-specific analysis. Attempts to use this library as a generic policy library made it bloated and tangled.

This commit attempts to move us to a better state by separating out the SQL policy verifier into a separate `sql_policy_verifier_interface` and associated `sql_policy_verifier`. This allows slimming down that library and extracting it from the tangle. The `datalog_policy_verifier` is now not used for any production purpose, and we can clean it up at our leisure.

Fixes #747
See #728

PiperOrigin-RevId: 479677692
copybara-service bot pushed a commit that referenced this issue Oct 7, 2022
…_verifier.

In the early days of Raksha, we created the `datalog_policy_verifier`. This was before we understood that the Souffle language and the Souffle internal architecture meant that we would have to create a separate library per policy interface, and that having one Souffle library to serve all of our needs probably wasn't going to cut it.

Others coming to the Raksha project saw the name and, quite reasonably, believed it was the generic Raksha analysis rather than a SQL-verifier-specific analysis. Attempts to use this library as a generic policy library made it bloated and tangled.

This commit attempts to move us to a better state by separating out the SQL policy verifier into a separate `sql_policy_verifier_interface` and associated `sql_policy_verifier`. This allows slimming down that library and extracting it from the tangle. The `datalog_policy_verifier` is now not used for any production purpose, and we can clean it up at our leisure.

Fixes #747
See #728

PiperOrigin-RevId: 479677692
copybara-service bot pushed a commit that referenced this issue Oct 7, 2022
…_verifier.

In the early days of Raksha, we created the `datalog_policy_verifier`. This was before we understood that the Souffle language and the Souffle internal architecture meant that we would have to create a separate library per policy interface, and that having one Souffle library to serve all of our needs probably wasn't going to cut it.

Others coming to the Raksha project saw the name and, quite reasonably, believed it was the generic Raksha analysis rather than a SQL-verifier-specific analysis. Attempts to use this library as a generic policy library made it bloated and tangled.

This commit attempts to move us to a better state by separating out the SQL policy verifier into a separate `sql_policy_verifier_interface` and associated `sql_policy_verifier`. This allows slimming down that library and extracting it from the tangle. The `datalog_policy_verifier` is now not used for any production purpose, and we can clean it up at our leisure.

Fixes #747
See #728

PiperOrigin-RevId: 479677692
copybara-service bot pushed a commit that referenced this issue Oct 7, 2022
…_verifier.

In the early days of Raksha, we created the `datalog_policy_verifier`. This was before we understood that the Souffle language and the Souffle internal architecture meant that we would have to create a separate library per policy interface, and that having one Souffle library to serve all of our needs probably wasn't going to cut it.

Others coming to the Raksha project saw the name and, quite reasonably, believed it was the generic Raksha analysis rather than a SQL-verifier-specific analysis. Attempts to use this library as a generic policy library made it bloated and tangled.

This commit attempts to move us to a better state by separating out the SQL policy verifier into a separate `sql_policy_verifier_interface` and associated `sql_policy_verifier`. This allows slimming down that library and extracting it from the tangle. The `datalog_policy_verifier` is now not used for any production purpose, and we can clean it up at our leisure.

Fixes #747
See #728

PiperOrigin-RevId: 479691720
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant