Store generated DKIM keys in a dedicated Redis keystore - #100
Open
gott-alexander wants to merge 1 commit into
Open
gott-alexander wants to merge 1 commit into
gott-alexander wants to merge 1 commit into
Conversation
StefanAkie
reviewed
Sep 14, 2026
| def _dkimRedisConnection_(): | ||
| """Return a Redis client for the dedicated DKIM keystore, or None if | ||
| the dkimRedis configuration section is disabled.""" | ||
| import redis as redislib |
Member
There was a problem hiding this comment.
We use services.
with Service("redis", errors=Service.SUPPRESS_INOP) as redis:
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)
Support ACL username for the DKIM keystore connection
Access the DKIM keystore via the redis service hub
Replace the manually constructed redis client in _dkimRedisConnection_
with the Service("redis", errors=Service.SUPPRESS_INOP) context manager,
so keystore availability is handled by the common service framework.
Provide the DKIM keystore as its own service
Register a dedicated dkimredis service reading the dkimRedis config
section (host, port, ACL username and password) and use it from
dnsHealth, restoring the dedicated, authenticated keystore connection
while keeping the service hub mechanics.
gott-alexander
force-pushed
the
feature/redis-dkim-keys
branch
from
September 15, 2026 21:43
fdafbaf to
f0cf2bc
Compare
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
2 participants
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