Register credentials extracted from proxy configuration as secrets

[mbg]

This will cause the credentials extracted from the proxy configurations to subsequently be masked in the Actions log, reducing the probability of accidental leakage.

Merge / deployment checklist

• Confirm this change is backwards compatible with existing workflows.
• Confirm the readme has been updated if necessary.
• Confirm the changelog has been updated if necessary.

[Copilot]

Pull Request Overview

Registers credentials extracted from proxy configurations as GitHub Actions secrets to prevent accidental leakage in logs.

• Imports @actions/core and invokes core.setSecret on any extracted password or token.
• Mirrors the secret-masking logic in the compiled JavaScript output.

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
src/start-proxy.ts	Imported @actions/core and added core.setSecret calls for password/token
lib/start-proxy.js	Added secret registration logic in the compiled start-proxy.js

Comments suppressed due to low confidence (1)

src/start-proxy.ts:69

• Consider adding unit tests to verify that core.setSecret is called when credentials include a password or token, ensuring secrets are properly masked in logs.

if (e.password !== undefined) {

[mbg]

This looks like a FP to me.

[navntoft]

Consider testing for null as well to guard against future changes. Better safe than sorry in these cases...

[mbg]

I don't disagree, but we don't seem to check for null anywhere else (including elsewhere here where we inspect other members of the same JSON object).

I think we can do a much better job at validating the JSON value we get in general (e.g. check that it actually is an array, rather than just assuming it), but that may be a larger chunk of work. I am not sure if it makes sense to change this one now and not the others - what do you think?

[navntoft]

Hmm, good question. I was about to write that it is probably more important to be consistent and make a sweep later with proper validation.

But: What is the impact if the structure of the JSON changes and makes our assumptions false in other places vs. here? In other places something might just crash, which we can hopefully detect and fix, but here we risk leaking secrets.

Your call though, as I haven't looked at the other places, and don't know the severity of the potential leak...