feat: encrypt secrets for internal use #333
Conversation
|
@supabase/dashbit, if there is any way to continue keeping secrets in funs across upgrades, I would be happy to hear about it, as I haven’t found any safe method |
There was a problem hiding this comment.
Hi @abc3 👋 LGTM!
if there is any way to continue keeping secrets in funs across upgrades, I would be happy to hear about it, as I haven’t found any safe method
Not that I know. I will keep investigating this, but I can only think of doing serialization/deserialization of the function term, which is similar to what you did here. But yeah, it wouldn't be safe without the encryption/decryption.
| def decode_secret(fun) when is_function(fun) do | ||
| Logger.warning( | ||
| "Using deprecated function `decode_secret/1` #{inspect(Process.info(self(), :current_stacktrace), pretty: true)}" | ||
| ) |
There was a problem hiding this comment.
Emitting the deprecation warning is fine, but have you considered using the @deprecated module tag - https://hexdocs.pm/elixir/Module.html#module-deprecated-since-v1-6-0 - with a different function name? This would make easier to spot the locations you are still using this, and would make easier to migrate. Of course is totally fine to keep as it is :)
WDYT?
|
Other approaches to consider:
@derive {Inspect, only: []}
defstruct :secret
|
Co-authored-by: Filipe Cabaço <[email protected]>
To avoid logging sensitive data (passwords, secrets, etc.), we keep it internally as anonymous functions
fn -> some_secret end. However, during hot upgrades, old links to these funs can become invalid, so this PR introduces a new approach by turning sensitive data into binary.The PR also includes the HotUpgrade module, which will replace existing encoded secrets, currently cached or residing within the
:poolboysupervisor, with this new method