Hi,
When querying for secrets with the API, the user cannot see the plain-text value, only a digest.
Is the digest algorithm public so users can determine if a secret changed without updating it and seeing if the digest changes?
A side question: If I update a secret with the same value, will that trigger a deploy?
Thanks,
Yes! That’s exactly what the digest is for. It’s also for us to determine if a secret changes.
If you update a secret with the same value, it’s a noop. We detect that and don’t restart the VMs.
I now realize I did not express myself correctly. My question was:
Is the algorithm to compute the digest public, so that I can compute it on my side, and avoid doing the request to update a secret to the same value.
Although if it is a noop there is less value in doing so.
Ah, yes. It’s just an md5, this is the exact Ruby we use:
digest = Digest::MD5.hexdigest(val)
You are free to compute your own digests. This is something that could change in the future, though I don’t know why we would.
Thanks a lot!
Ah, yes. It’s just an md5…
Has this been updated recently?
We are seeing different length digests in newer secrets we set.
If I understood what Thomas wrote here correctly, Fly might even get rid of the digests (authenticator tag as Thomas puts it) altogether. So, it is no surprise they’ve moved away from MD5 (which may not be the best choice for a digest, anyway).
Yes, it’s keyed, not based on MD5, and deliberately collide-able now (these are checksums of secrets, not authenticators of secrets). But also, it’s true, we’re likely to get rid of this feature altogether; we have a better plan for how to handle this that doesn’t require our API server to have access even to a checksum of the secret.
My deployments to fly are now failing because the API aborts with an error if secrets aren’t changed, but the checksum is no longer based on MD5 (so my code that avoids setting them is now broken). What’s the recommended way to “ensure” a secret is set to what it needs to be set to?
Can I ask the API not to error if the secrets are already correct?
Then what is the current hashing algorithm? @kurt’s solution no longer applies.
I found that new secrets have a length of 16, instead of the previous 32 (MD5).
For example password yields 34422fcd98e40287.
It’s best not to think of this as a hash; it’s just a change hint. It’s deliberately truncated and heavily collide-able.
I would like to be able to know if secrets have changed, prior to running the setSecrets mutation. It automatically re-deploys a new version on the app when changes are detected.
For example, a --dry-run option would be nice.