Allow user names to not be registered as secrets

[rbell-mfj]

It would be nice if load-secrets-action had a way to exempt certain values from being registered with the runner as secrets -- particularly username values. These are often not particularly (or at all) secret, and in some environments they tend to be very common strings like admin or readonly (or the name of a client, say).

Making these secrets can have unintended effects, like forcing important debug information to be redacted in logs and preventing other strings that coincidentally contain these values from being passed correctly between jobs via outputs.

[hculea]

Hey @rbell-mfj,

Thank you for reaching out!

To make sure I understand your use-case correctly - you would like the configurability to not have certain fields (specifically the username of Login items) redacted and replaced by the <concealed by 1Password> string in your logs, and for this to not come at the cost of exposing all fields in the logs.

Is my understanding correct? Can I also ask you for such a use-case where the concealment of the username field is relevant for you?

Thanks!

Horia

[rbell-mfj]

@hculea yes, you have it correct.

The specific use case for us is that we have "tenant ID" strings that identify a particular application tenant. We have a series of reusable GitHub workflows that perform certain actions on these tenants. One workflow runs a job that resolves a tenant ID from inputs and makes some database updates. It then calls another workflow to clear relevant portions of a cache, passing along a string that includes that tenant ID as a parameter.

The problem is that, in some environments, the tenant ID happens to also be the database username. When the first job retrieves the DB username and password from a 1Password login item via load-secrets-action, it causes the tenant ID string to be marked as a secret for the entire run - I think due to this line of code.

As a result:

1. The tenant ID becomes masked in all further runner output, even steps unrelated to credentials, like Updating widgets for tenant: ***. This makes it hard to see what's going on.
2. The attempt to pass the string with tenant ID to the cache clear workflow quietly fails with a warning like Skip output 'cache-prefix' since it may contain secret. The called workflow gets an empty value for the corresponding input and crashes.

We are working around this for now by retrieving only the DB password from load-secrets-action, and hardcoding logic into the workflow that (depending on environment) assumes that the DB username is the tenant ID. Ideally, since these do comprise a login, we'd be able to get both of them from the 1Password item, keeping the password a secret but not treating the username that way.

[zxaos]

We just ran into this. We have turbocache settings in a 1P entry, part of which is our company name, so now our logs are full of spurious redactions:

run npm exec turbo --no -- run ci --continue --affected --summarize
[...]
• Running ci in 9 packages
• Remote caching enabled
@***/package-a:prettier
@***/package-b:prettier
@***/package-c:postinstall
@***/package-d:prettier
@***/package-e:prettier
[...]

where *** would normally be our npm name but is redacted because it happens to match the cache key.

We can work around it, sure, but it's frustrating that we can't just opt out of the behaviour for that value somehow.