Add workflow validator to enforce policy - #17
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 23873d652d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
d05f80b to
97ea9dd
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 97ea9dd4df
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| R3x::Workflow::Registry.reset! | ||
| workflow_files.each do |entrypoint| | ||
| R3x::Workflow::Validator.scan_file(entrypoint) |
There was a problem hiding this comment.
Scan all workflow source files before loading pack
PackLoader.load! only validates each workflow.rb entrypoint, then immediately requires it. In lib/r3x/workflow/pack_loader.rb, this lets a workflow bypass the new policy by moving forbidden code into a secondary file (for example require_relative "unsafe" where unsafe.rb reads ENV or shells out), because that file is never scanned. Since this commit is meant to enforce workflow policy at load time, limiting validation to entrypoints leaves a straightforward enforcement gap in production.
Useful? React with 👍 / 👎.
| module Policy | ||
| STRICT_FORBIDDEN_CONSTANTS = %w[ENV].freeze | ||
| STRICT_FORBIDDEN_MODULE_PREFIXES = %w[R3x::Env ::R3x::Env].freeze | ||
| STRICT_FORBIDDEN_METHODS = %i[eval system exec spawn send __send__ instance_eval class_eval const_get].freeze |
There was a problem hiding this comment.
Forbid
public_send to prevent policy bypass
The strict forbidden-method list omits public_send, so workflows can still invoke blocked behavior indirectly (for example Kernel.public_send(:system, "ls") or dispatch to other forbidden methods) while passing validation. Because Validator only matches call-site method names, this omission creates a direct bypass of the new enforcement introduced in this commit.
Useful? React with 👍 / 👎.
- Define strict policy constants for forbidden constants/modules/methods - Add AST-based `R3x::Workflow::Validator` to scan workflow files - Forbid direct `ENV`/`R3x::Env` access, shell exec, `eval`, `send`, etc. - Wire validator into `PackLoader.load!` to reject unsafe workflows at load - Add tests exercising validator and pack loader rejection behaviors
97ea9dd to
f3647e4
Compare
8561c04 to
801b7e6
Compare
c47ea07 to
ef8244c
Compare
R3x::Workflow::Validatorto scan workflow filesENV/R3x::Envaccess, shell exec,eval,send, etc.PackLoader.load!to reject unsafe workflows at load