fix: use envvars in release action

[reedham-aws]

Description of changes:
Using environment variables instead of direct variable injection.

By submitting this pull request

• I confirm that my contribution is made under the terms of the Apache 2.0 license.
• I confirm that I've made a best effort attempt to update all relevant documentation.

[aws-sam-tooling-bot]

Code Review Results

Reviewed: fae65dd..b4e3479
Files: 1
Comments: 1

---

Comments on lines outside the diff:

[.github/workflows/release.yml:47] [SECURITY] The PR converts user-controllable inputs (github.actor, github.event.inputs.*) to env vars to avoid direct shell interpolation, but the same workflow still interpolates secrets directly into a run: block on this line:

AUTH=$(echo -n "${{ secrets.CENTRAL_USERNAME }}:${{ secrets.CENTRAL_PASSWORD }}" | base64)

GitHub expressions are substituted into the script before the shell parses it, so any shell metacharacter in a secret value (backtick, $(...), double-quote) would be evaluated by bash. While the risk for repo-owner-controlled secrets is lower than for user inputs, GitHub's security hardening guidance recommends the env-var pattern for all expression interpolation in run: blocks, and it would be consistent with the rest of this PR.

Suggested fix using the same pattern already adopted in the "Release and publish package" step:

- name: Upload to Central Publisher Portal
       run: |
         AUTH=$(echo -n "$CENTRAL_USERNAME:$CENTRAL_PASSWORD" | base64)
         curl --fail -X POST "https://ossrh-staging-api.central.sonatype.com/manual/upload/defaultRepository/com.amazonaws.serverless" \
           -H "Authorization: Bearer $AUTH"
       env:
         CENTRAL_USERNAME: ${{ secrets.CENTRAL_USERNAME }}
         CENTRAL_PASSWORD: ${{ secrets.CENTRAL_PASSWORD }}

[reedham-aws]

IMO the AI comment about the secrets being risks for injection is a little silly considering those are the secrets themselves, but I will make the change I guess.

[reedham-aws]

Integration test needs to be fixed, but it's definitely unrelated to this change.