Keep alpha release token out of push URL

[mcc0nnell]

Summary

Keep the alpha-release PAT out of the Git remote URL when pushing the release tag.

The workflow still uses the existing PERSONAL_TOKEN, so the tag push continues to trigger the downstream publish workflow. The token is provided through the step environment and a one-shot Git credential helper instead of being interpolated into the git push URL.

The command also clears inherited credential helpers before installing the one-shot helper, so credentials from the runner environment cannot take precedence.

Why

The current git push interpolates PERSONAL_TOKEN directly into the HTTPS remote URL. In a GitHub Actions run step that places the credential in generated shell text and in the git command-line argument.

Passing the PAT through the secret-backed environment keeps the credential out of both while preserving the current push semantics.

Validation

• actionlint .github/workflows/alpha-releases.yml
• git diff --check
• exercised the credential-helper path locally with a dummy token and verified Git receives the expected username/password

[NullVoxPopuli]

what's the problem? maybe I don't understand

[mcc0nnell]

The concern is not log masking — GitHub will mask the secret in displayed logs.

The narrower issue is where the secret value exists before Git runs. In the current command, the Actions expression is expanded into the HTTPS URL before the shell invokes git, so the PAT becomes part of Git's argv. With this change, the PAT value stays in the step environment; Git's argv contains only the credential-helper code with a literal $PERSONAL_TOKEN reference, and that value is expanded later when Git asks the helper for credentials.

So this is hardening rather than a known token leak: same push behavior, but the secret is no longer embedded in the remote URL or process arguments.

[NullVoxPopuli]

Why is the way it is now a problem?

[mcc0nnell]

The current form isn't broken in the sense that GitHub is exposing the token in logs. The concern is just exposure surface: ${{ secrets.PERSONAL_TOKEN }} is substituted before the shell runs, so the literal PAT ends up in the generated command and in git's argv as part of the remote URL. Masking only affects displayed logs; it doesn't remove the value from those process/script surfaces.

That matters mainly if something else on the runner can inspect argv, temporary scripts, debugging output, or failure artifacts. On an ephemeral GitHub-hosted runner with only trusted steps, the practical risk is small. So I'd characterize this as defense-in-depth, not a known Ember vulnerability.

If that reduction isn't worth the extra credential-helper machinery here, I'm also fine closing the PR.

[NullVoxPopuli]

That matters mainly if something else on the runner can inspect argv,

If something can inspect argv, it can inspect process.env

If that reduction

it's not clear there is any reduction, to me

[mcc0nnell]

That's fair — if something already has code execution on the runner, moving the PAT from argv to process.env doesn't create a meaningful security boundary.

I was thinking more about software assurance down the road: keeping release credentials out of command construction where practical, so there are fewer places to reason about if an upstream action/tooling dependency is ever compromised. But I agree this PR by itself may not buy much against that threat model.

Also, I've been looking through the Ember release setup while working on this — really nice work.