nostr:npub108pv4cg5ag52nq082kd5leu9ffrn2gdg6g4xdwatn73y36uzplmq9uyev6 nostr:npub1ycnhgr56efxcpvhu7q0er9gqjqttpwhgqgjfgjaj7gpfea5g6xhq4zgshs ok, but understand that means all the secrets are effectively on disk at /proc/self/environ. An arbitrary file read (like the two recent Pleroma issues) means full secret disclosure.
I would really recommend against it.
You can get leaks from both env variables and from secret files. It might seem easier to get them out of env variables, but you’re really looking for a similar exploit vector.
The only way to really be secure is pretty complex: using a tool like Vault to rotate secrets, and that gets super annoying and you often have to write your tooling around your rotation tool.
nostr:npub109x0x9dlft64y4h9vz9mxu92qpqn752sd8p4xe2zkcanlzmk2fcq3pwvvl nostr:npub108pv4cg5ag52nq082kd5leu9ffrn2gdg6g4xdwatn73y36uzplmq9uyev6 nostr:npub1ycnhgr56efxcpvhu7q0er9gqjqttpwhgqgjfgjaj7gpfea5g6xhq4zgshs I mean you don’t need vault. The secrets file (on a tmpfs) just needs to be made inaccessible after application init.
At that point secrets can’t be read from the FD by an arbitrary file read vuln, be it directly from a file or from /proc/self/environ.
