Summary

Replaces the shell-interpolated execSync tar invocation in pushArchiveToGitRepository() with the tar npm package (already a dep). Closes a latent shell-injection hazard and makes the unpack step robust against adversarial artifact paths.

The hazard

src/targets/commitOnGitRepository.ts used to unpack the downloaded tarball with:

childProcess.execSync(`tar -zxvf ${archivePath}${stripComponentsArg}`, {
  cwd: directory,
});

archivePath comes from this.artifactProvider.downloadArtifact(...) so today it's Craft-constructed and not directly attacker-controllable. But the pattern is fragile: any future artifact provider that returns a path containing ;, $(), backticks, spaces, or | becomes a silent arbitrary-command-execution vector during release. stripComponents is zod-validated as a number so that vector is blocked, but the archive path is not so constrained.

The fix

Use tar.x({ file, cwd, gzip, strip }) from the tar npm package. It takes the path as a function parameter with no shell parsing at any layer, so even a path like /tmp/evil;touch /tmp/pwned.tgz is treated as a literal filename.

tar 7.x is already a dep (package.json); src/utils/system.ts already uses tar.extract elsewhere.

Tests

src/targets/__tests__/commitOnGitRepository.test.ts:

• Existing "basic functionality" test updated to assert on the tar.x mock instead of the old execSync spy.
• New test "No strip-components when not configured" covers the strip: 0 path.
• New regression test "Shell-metacharacter archivePath does not reach a shell" plants a path like /tmp/evil;touch /tmp/CRAFT_INJECTION.tgz and asserts tar.x received it literally. This would have been a shell injection under the old code.

All 4 tests pass; lint / build clean.