obfuscation/php/php_obfuscation_declarations.yml fails to load under Opengrep
(the Semgrep fork your README explicitly supports: "Opengrep or any other Semgrep fork could also be used").
The offending pattern is the const alternative:
- pattern: const $VAR = (...);
Opengrep reports:
Rule parse error in rule opt.rules.apiiro.obfuscation.php.php-obfuscation-declarations:
Invalid pattern for PHP: Stdlib.Parsing.Parse_error
----- pattern -----
const $VAR = (...);
----- end pattern -----
Impact
- The rule is skipped, so no PHP obfuscated-declaration detection happens at all for Opengrep users, silently, unless you read the scanner's error output.
- The scan exits non-zero (2), which in a CI gate reads as a scan failure rather than "one rule is bad".
- The error carries no file path, no
path, and spans is empty, so tooling that tries to locate and quarantine the offending rule programmatically cannot find it. (We hit exactly this: our automatic "remove rules the engine rejects" pass converged while the rule still failed.)
Suggested fix
Dropping the trailing semicolon parses cleanly:
- pattern: const $VAR = (...)
Worth confirming against upstream Semgrep as well, if it accepts the ; form, this is a parser
difference rather than an outright rule bug, but the fix appears harmless in both.
obfuscation/php/php_obfuscation_declarations.ymlfails to load under Opengrep(the Semgrep fork your README explicitly supports: "Opengrep or any other Semgrep fork could also be used").
The offending pattern is the
constalternative:Opengrep reports:
Impact
path, andspansis empty, so tooling that tries to locate and quarantine the offending rule programmatically cannot find it. (We hit exactly this: our automatic "remove rules the engine rejects" pass converged while the rule still failed.)Suggested fix
Dropping the trailing semicolon parses cleanly:
Worth confirming against upstream Semgrep as well, if it accepts the
;form, this is a parserdifference rather than an outright rule bug, but the fix appears harmless in both.