Closed nrktkt closed 1 month ago
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.
I don't have much thoughts on secrets.
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 propose exactly what the problem is.
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 toT.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 customcase class Secret[A](a: A)
which has a JSON serializer which always outputsnull
.