Has there been any updates for this? I am interested in this as well.

Hi @ethomson

Any updates on Adding password or secret types.

I could be wrong, but I think it's more secure keeping some secrets on my offline password manager. That's why I would rather type passwords each time I need to manually trigger a workflow.

Bump

Bump

Bump

Bump

This is just what I need, a password input type.

This is exactly what I am looking for

I would love that

Over a year... and nothing new?

I do confirm that it is simply not possible to use Azure (non) secrets (at all) in certain cases. (e.g. echo from some base 64...)
And it's a bit annoying to have to stop sharing your screen in the middle of a meeting just to launch a workflow.

So please add another string type such as masked, password, secret, whatever you like, as long as it has a masking effect when you enter it.

Bump

Bump

almost 3 years, still no update?

This would be very valuable for my initialization pipeline

At least 2 legit use cases and 3 years since the initial request.
It would be nice to at least have a response on this thread about how is this request being considered and any planning or any information at all to help us track any eventual progress

We use GitHub workflows for cloud deployments. A password is required to run those workflows. We use the scripts below to avoid having the password printed in logs. Sure would appreciate a "password" input type. Or RBAC for workflows.

DEPLOY_PASSWORD=$(cat $GITHUB_EVENT_PATH | jq -r '.inputs.DEPLOY_PASSWORD')
echo "::add-mask::${DEPLOY_PASSWORD}"

AWK incantations when jq is not available:

DEPLOY_PASSWORD=$(cat $GITHUB_EVENT_PATH | sed 's/[{}]/ /g' | awk -v k="DEPLOY_PASSWORD" '{for(i=1; i<=NF; i++) {if ($i ~ k) {print $(i+1)}}}' | sed -e 's/[",]*//g')
echo "::add-mask::${DEPLOY_PASSWORD}"

Ping

bumpy

bump

Bump!

There are work-arounds/hacks but this is such an obvious use case.
I need my (our team's) personal user/pass to access the password store programmatically so we can get all the details for all the systems we then configure (automated Ansible)

• I can't use secrets (or everyone is using my creds)
• We are not allowed automated accounts to access the password store
• I really don't like my password being typed in plain text and plastered all over the logs!

I would really like this for initial NPM package publish.

NPM supports OIDC now-adays, but only AFTER you publish the package once.
So now I have a workflow_dispatch action that does the initial publish with a short lived AccessToken, and then I setup OIDC on npmjs.com.

This needs to have a sensitive or secret input field.

I wonder whether GitHub should offer user secrets/variables (similar to organization/repository secrets/variables) and a input type secret/variable that lets the user choose from his/her secrets/variables. The input would just show the name of the secret/variable but the workflow could access its value as secret or variable. Then the input would not need any masking, and the user would not have to type the secret again and again.

bump

Clearly this is something people want.
@ethomson I see this is "on backlog" what can we do to give this the priority it deserves?