chore(ruby): avoid shell invocation in extsources.rb

[orbisai0security]

Summary

This PR updates the Ruby binding helper in bindings/ruby/extsources.rb to avoid invoking a shell when listing tracked source files.

The previous implementation used Ruby backticks to run:

git ls-files -z #{root}

Description: Detected non-static command inside .... If unverified user data can reach this call site, this is a code injection vulnerability. A malicious actor can inject a malicious script to execute arbitrary code.

Changes

• bindings/ruby/extsources.rb

Verification

• Build passes
• Scanner re-scan confirms fix
• LLM code review passed

---

Automated security fix by OrbisAI Security

[KitaitiMakoto]

Thank you for report!

Could you detail why the ` (backtick) method call is, especially at high severity, danger in the file's context?

[orbisai0security]

Thanks for the review, you’re right to ask for context.

After looking again, I agree this should not be framed as a confirmed high-severity exploitable vulnerability in the current code path. root is currently a fixed Pathname value, so I do not have evidence that attacker-controlled input reaches the backtick call today.

The reason for the change is defensive hardening: the current implementation invokes a shell unnecessarily, while Ruby’s argv form of IO.popen can run git directly without shell parsing. That avoids this class of issue if the command arguments are ever made dynamic later, and it also makes the intent more explicit.

I’m happy to update the PR title/description to something like:

“chore(ruby): avoid shell invocation in extsources.rb”

and remove the “high severity” / arbitrary code execution wording. This should be treated as a low-risk hardening cleanup rather than a confirmed security vulnerability.

[KitaitiMakoto]

I don't think extsources.rb requires such strict hardening because now it's clear.

[orbisai0security]

Thanks, that’s fair.

I agree that this is not a confirmed vulnerability in the current code, since the path is static and the script is clear. I’ll drop the security framing.

My only remaining rationale is cleanup/defence-in-depth: array-form process execution avoids shell parsing without changing behaviour. But I understand if you prefer not to add hardening where the current code is already clear and constrained.