Let's say that theoretically there is a Gradle plugin that uses an auth token for a task. The auth token affects the outcome of the task since with an incorrect auth token the task will fail. Therefore the auth token is marked with

@Input

. My understanding is that task inputs are hashed and not placed in the build cache in plain text. However running the build with

--debug

would print this key in plain text. So the question is: Is it best practice to mark API keys as

@Input

or

@Internal

?

The auth token influences the outcome, yes. But if the outcome is task failure, the task is rerun anyway. If the outcome was successful, why return if only the auth token changed? Unless there can be different successful results with different with tokens. In the latter case it should probably be input. In the former it is probably unnecessary. In the config cache it should either way be persisted unless you make sure it is only evaluated at that execution time.

Yes the auth token of this plugin encodes another optional parameter which could influence the outcome if the auth token is swapper for another auth token. I realize for task correctness it is needed but I'm wondering if there are any security best practices here. For example someone, or an agent, or CI , trying to debug something might enable

--debug

and that would expose this token.

you could mark it internal, and have another property marked as an input, which you compute yourself (say with a hash function)?

Oh thank you. That's a good idea

We have little on this currently, mostly here. I agree that having more guidance would be useful. Could you file a documentation issue for this?

Certainly! Done: https://github.com/gradle/gradle/issues/37962