-
Notifications
You must be signed in to change notification settings - Fork 17
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
Comments
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
The library
datalog_policy_verifier
, defined insrc/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).The text was updated successfully, but these errors were encountered: