4 ms·
Wow, great work! I am definitely going to test this out over the weekend. However AFAICT the `aws.Config` approach breaks certain backwards compatibility w/how
by upbeatlinux 9y ago
Wow, great work! I am definitely going to test this out over the weekend. However AFAICT the `aws.Config` approach breaks certain backwards compatibility w/how wal-e handles credentials. Also wal-g does not currently support encryption. FWIW, I would love to simply drop-in wal-g without having to make any configuration changes.
- fdr 9y agoDo you want GPG based or some other client side encryption, or S3's encryption support? The latter could probably just be turned on. The former is a feature requiring code.
- upbeatlinux 9y agoIdeally the presence of the `WALE_GPG_KEY_ID` env var should enable encrypted backups https://github.com/wal-e/wal-e#encryption https://github.com/wal-e/wal-e#encryption. Put differently to be a "successor" it needs to be a drop in replacement ;)
- fdr 9y agoI have to be selective about maintenance of features. I'll consider GPG support.
- tatersolid 9y agoPlease consider libsodium or a similar "modern" crypto library instead. There's a lot of ugly 90s crypto in GPG and the API is terrible. Libsodium makes it hard for non-crypto devs to shoot themselves in the foot, and is much less code to write.
- trojanowski 9y agoAlternatively you could use a combination of AES and RSA similar how pghoard implements it: https://github.com/ohmu/pghoard https://github.com/ohmu/pghoard The RSA keys (or path to them) would be passed as environment variables. It would be a little easier to setup than gpg (especially for automatic backup restoration).