feat: Secret config reader to work with base64 and ASCII values #1774
Conversation
| ByteVector.fromBase64Descriptive(b64).flatMap(apply) | ||
|
|
||
| def unsafeFromBase64(b64: String): Secret = | ||
| fromBase64(b64).fold(sys.error, identity) | ||
|
|
||
| implicit def secretReader: ConfigReader[Secret] = | ||
| base64ByteVectorReader.emap(bv => | ||
| Secret(bv.takeWhile(_ != 10)).leftMap(err => | ||
| base64SecretReader orElse asciiSecretReader |
There was a problem hiding this comment.
Does this mean, the ascii secret must not be valid base64? This could happen in theory, perhaps?
There was a problem hiding this comment.
Yes, I know what you mean. It can happen and yes, if it does it's quite unlikely it will be 16, 24 or 32 chars long after decoding. We'll simply fail horrendously. To be honest I don't really see an easy solution for that assuming we'd like to have a single secret entry in the helm config. From the other side, I guess our yat will be the only people who generate the values (in an automatic way), so perhaps that's acceptable. What do you think? I can talk to Alessandro and check if they are happy with that.
There was a problem hiding this comment.
I'm fine of course. Just worth noting, I guess. If it occurs, it will be something hard to find in a year 😄 And might be a support case for deployments not on our control. But agree that it is not very likely. And if we are limited by helm or whatever other tool, I think there is not much we can do.
|
You can access the deployment of this PR at https://renku-ci-gr-1774.dev.renku.ch |
This PR changes the crypt secret config reader so it can read ASCII and base64 encoded values.
closes #1768
/deploy