Ah ok. That would be a fairly straightforward improvement.
Login to reply
Replies (2)
I think the major issue is that the service has access to both, the encrypted nsec and the key to decrypt it. Plus and service that is between the service and the client will have access to both, e.g., Cloudflare, TLS termination thingy. It’s just not a good approach to the storage of keys unless the organization hosts it in their own trusted infrastructure 🐶🐾🫡
i forget where i saw it implemented... maybe i even wrote an RPC recently that lets you do that unlock remotely so it never touches the disk...
oh, no, it was my former sponsor... let me see...
uses protobuf - you will see the proto and the generated pb.go code in there, that is an unlocker that stays off-disk
a second best option is using an environment variable, you can protect that behind root privileges
GitHub
indra/pkg/storage at 089a0df491fd76ac393875053625f9fd4fdbe140 · indra-labs/indra
Distributed Virtual Private Network Powered By Bitcoin Lightning - indra-labs/indra