Store generated DKIM keys in a dedicated Redis keystore - #100
Open
gott-alexander wants to merge 2 commits into
Open
Store generated DKIM keys in a dedicated Redis keystore#100gott-alexander wants to merge 2 commits into
gott-alexander wants to merge 2 commits into
Conversation
Generate DKIM keys as before, but additionally push the private key
into a dedicated Redis instance (hashes DKIM_PRIV_KEYS /
DKIM_SELECTORS), from which grommunio-antispam's dkim_signing module
reads keys when configured with use_redis. This removes the manual
copy step into /var/lib/grommunio-antispam/dkim that the UI previously
had to demand, because the API could not write to that directory.
- generateDkimKeys returns {pubKey, redisStored, redisError} so
clients can tell whether the key is already in place for signing
- on API startup, all locally stored keys are re-pushed; the files
under the admin-api data directory remain the source of truth
- keystore connection is configured via the new dkimRedis section
(disabled by default, so behaviour without grommunio-setup wiring
is unchanged)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.Suggestion cannot be applied right now. Please check back later.
Summary
Generated DKIM keypairs currently end up as files under the admin-api data
directory, and the UI has to ask the administrator to copy them into
/var/lib/grommunio-antispam/dkim/by hand, because the API has no writeaccess to the antispam directories. This PR lets the API push generated keys
into a dedicated Redis keystore instead, from which grommunio-antispam
(rspamd
dkim_signingwithuse_redis) reads them directly — removing themanual copy step entirely.
Changes
tools/dnsHealth.py:generateDkimKeys()now pushes the generated private key into thekeystore (
HSET DKIM_PRIV_KEYS <selector>.<domain>andHSET DKIM_SELECTORS <domain>).{pubKey, redisStored, redisError}so clients know whether the key isalready in place for signing (openapi.yaml updated accordingly).
syncDkimKeysToRedis()re-pushes all locally stored keys; called on APIstartup. The key files remain the source of truth, so the keystore is a
rebuildable cache and signing survives the loss of Redis data.
res/config.yaml: newdkimRedissection (enabled,host,port,username,password). Disabled by default — behaviour withoutgrommunio-setup wiring is unchanged (keys are generated as before and the
UI shows the manual instructions).
main.py: run the sync once at startup when the keystore is enabled.Verification
Keystore round-trip tested end to end: generate a key via the API with the
keystore enabled (
redisStored: true, key visible underDKIM_PRIV_KEYS/DKIM_SELECTORS), rspamd signs outbound mail with it(
DKIM_SIGNED), and disabling the keystore restores the previousmanual-instruction behaviour. Sync-on-start re-pushes keys after wiping the
Redis database.
Companion PRs
rspamd and admin-api configuration, imports pre-existing keys