Release 1.5.4: Hardened git command execution and more reliable default `--from` detection

Summary

Version 1.5.4 is a small, security-focused update that tightens validation around git command arguments (to reduce the risk of option/argument injection) and improves how the library determines a safe default for the --from reference when generating release notes.

Changes

Security hardening for git command arguments

Several git helpers now apply stricter input validation before invoking git:

• Added explicit validation for remote names and branch names (e.g., disallowing values that start with - and restricting to common safe characters).
• Additional defensive checks to prevent treating user-controlled values as git options (e.g., values like --upload-pack=...).
• Safer staging/unstaging behavior:
  • stageFiles() now uses git add -- <files...> after validating each file path.
  • unstageAll() uses git rm --cached -- <files...> for “fresh repo with no commits yet” scenarios, and validates staged file paths before use.

Why it matters: These changes reduce the risk of command/option injection when branch, remote, ref, or file path inputs are derived from user input or external automation.

More reliable default --from reference detection

getDefaultFromRef() was improved to be more robust and predictable, with clearer fallback behavior. It now attempts (in order):

1. Previous working/v* tag (only when on the working branch)
2. Previous release tag (v*) based on the current version in package.json
3. Local branch fallbacks: main, then master
4. Remote fallbacks: origin/main, then origin/master

It also reads the current version preferentially from HEAD:package.json (with a filesystem fallback), making it less dependent on the working tree state.

Why it matters: Automation that depends on “compare since last release” behavior should see fewer failures and fewer cases where the wrong baseline is selected.

Package version

• package.json version is now 1.5.4.

Impact

• Users: More secure behavior by default, especially in CI/CD or tooling contexts where branch/remote/ref values may come from environment variables, CLI args, or external systems.
• Developers integrating this library: Behavior should be compatible, but inputs that previously “worked” despite being unsafe (e.g., names starting with - or containing spaces) may now be rejected earlier with clearer errors.

Breaking changes

No breaking changes were detected in the release range (main → HEAD).
That said, this release intentionally becomes stricter about validating branch/remote names and file paths; if your workflows relied on unusual (or invalid) git names, you may need to normalize those inputs.