Create a T.secret for credentials or similar

[nrktkt]

None of the task types provided by default are ideal for handling secrets like credentials.
T.worker is close, but keeps the value in memory in the long-running background process. T.input seems ideal for reading credentials out of environment variables and such, but it writes the secret to disk which is obviously not what you'd want.

A T.secret would work similarly to T.input, but would not write the return value to JSON. The hash value could still be stored so that caching works the same way (it would need to be looked into if the default .hashCode would be appropriate, or if we should do something like use Java serialization run through a cryptographic hash and take the first couple bytes to use as the hash).
This is also a usability boon because it offers an obvious thing to use for sensitive values for new users of mill who haven't dug into each type of task and the cache system.

A workaround for users in the meantime would be to use T.input with a custom case class Secret[A](a: A) which has a JSON serializer which always outputs null.

[lefou]

I'm a bit reluctant to this request, since it's not totally clear to me, how it should behave in detail? Also I see the work that's needed to implement a new T type in our macros and the code complexity it produces.

Since not all secrets need to be a T.input themselves, having the constant check for changes wired into a hypothetical T.secret might be overkill.

You said a T.worker will keep it's value in memory, but you can simply work-around that, if the worker itself is a function/closure that only computes and returns the secret on demand.

So it's currently more like a pattern, which involves a Worker[() => Array[Char]] with an optional dependency on a Input[Int], that creates some hashCode of the secret.

I'd like to hear what @lihaoyi thinks about secrets in Mill.

[lihaoyi]

There is probably something here, but we would need to be clear about what kind of security model we are proposing. Right now, Mill assumes there is no security boundary, so secrets "kept in memory", "cached on disk", or "passed by the user" are all in the same domain.

IMO this probably should be discussed more rigorously before we can define exactly what the problem space is, and what concrete thread model we want to mitigate. Until then, it's too early to talk about T.secret or other details