Fix libsodium missing from GitHub Releases #1062
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
This PR fixes a security issue with wal-g that the binary releases published as GitHub Releases are built without libsodium support and silently ignore user requests to use libsodium encryption. The three commits in this PR:
The security issue is that a user would expect that their backup files are encrypted but they're silently processed and uploaded as plaintext. The exit-with-failure piece checks if either WALG_LIBSODIUM_KEY or WALG_LIBSODIUM_KEY_PATH are specified and if the binary was not compiled with libsodium support, then it prints an error and immediately exits.
This will be a breaking change for anybody using the GitHub Release binaries who specify libsodium keys on their primary (performing the uploads) but do not include them in their replicas. Previously everything was handled as plaintext so the replicas would have been able to read the primary's plaintext backups. After including this fix, the primary will be uploading encrypted files but any replicas that are missing the libsodium keys will no longer be able to read them unless they also have the same environment variables specified for the libsodium keys (so users need to make sure all their servers are in sync for libsodium usage).
Longer term I think it'd be simpler if there was a single way to specify how to handle encryption. Right now it's a series of if-then-else logic that checks against a bunch of different environment variables, e.g. there's WALG_GPG_KEY_ID, WALG_PGP_KEY, WALG_LIBSODIUM_KEY... If more than one is defined than the one that is picked is based upon the if-then-else order.
A single environment variable, e.g. WALG_ENCRYPTION, could instead be used for both the encryption mechanism and where to look for key material. That way it's explicit and a user indicating a given mechanism knows for sure that's what shall be used, or the app could fail if it's not possible (e.g. no compiled support for the requested mechanism).
That'd be a separate, possibly breaking change, so just leaving it here for future discussion.