Dovecot: build with GSSAPI support (package change only) #290

New issue

Closed

opened 2026-08-07 22:51:21 +02:00 by dominik.polakovics · 0 comments

dominik.polakovics commented

2026-08-07 22:51:21 +02:00

Owner

Part of #266. Build Dovecot with GSSAPI support on mail. Package change only — no configuration change, no behaviour change. Enabling the mechanism is the follow-up issue, and it cannot start until this is verified.

Why it is split this way

auth_mechanisms = plain gssapi with GSSAPI not compiled in is a fatal Dovecot startup error — that is mail down, not degraded. So the build lands and is proven first, entirely inert, before any config references the mechanism.

Confirmed starting state

dovecot-2.3.19.1's auth binary links no krb5:

/nix/store/7p6n6zv1mvl6dlqh9npg16swa0fc4wgz-dovecot-2.3.19.1/libexec/dovecot/auth  → no krb5 linkage

nixpkgs' pkgs/by-name/do/dovecot/generic.nix on nixos-26.05 — the channel hosts/mail/channel pins — has no kerberos in buildInputs, no --with-gssapi in configureFlags, and exposes no withGSSAPI argument. .override therefore cannot help; the derivation's attributes have to be extended.

Scope

Add krb5 to buildInputs and --with-gssapi=yes to configureFlags on the dovecot 2.3 package mail runs. Use =yes (linked into the auth binary, which is what the verification below checks) rather than =plugin.

Nothing else changes. auth_mechanisms, the LDAP passdb, auth_bind and every other Dovecot setting stay exactly as they are.

The pigeonhole trap — this is how this change breaks mail

hosts/mail/modules/dovecot.nix:263 installs config.services.dovecot2.package.dovecot_pigeonhole, and the comment directly above it records that a dovecot/pigeonhole version mismatch already broke sieve/managesieve on this host once.

A naive overrideAttrs can leave a passthru still pointing at the un-overridden dovecot, which would install sieve modules built against a different binary. Establish which mechanism actually propagates rather than assuming: an overlay replacing dovecot_2_3 is more likely to than an inline overrideAttrs at the services.dovecot2.package site. mail currently defines no nixpkgs.overlays; hosts/nb and hosts/web-arm show the in-repo pattern for adding one.

Cost, for context

One C autotools project — roughly 5–10 minutes on this host, no JVM, no Node, no Python. Nix rebuilds it only when the derivation changes, i.e. when the channel moves dovecot: a few times a year on 26.05, not on every bento rebuild. If the build ever fails after an upstream bump, mail stays on its previous generation — stale rather than down — so leave a comment explaining the override for whoever hits that.

Out of scope — all of it belongs to the follow-up

The imap/imap.cloonar.com service principal and its keytab
auth_mechanisms, auth_krb5_keytab, auth_username_format
Anything on nb or in Thunderbird
SMTP/Postfix, and Dovecot master-user/authzid

Verification

scripts/pre-commit dry-builds mail.

Human, after deploy — the first two are the gate for starting the follow-up:

The auth binary now links GSSAPI:

a=$(find /nix/store -maxdepth 4 -path '*dovecot-2*/libexec/dovecot/auth' | head -1)
ldd "$a" | grep -iE 'gss|krb5'

Pigeonhole was rebuilt against the override — readlink -f $(command -v sieve-test) must resolve under the same dovecot store path as above.
systemctl status dovecot2 clean; send and receive mail normally.
A sieve filter still fires. This is the pigeonhole risk, and it is the one failure that would not be obvious from the service status.

Rollback is reverting the commit.

Part of #266. Build Dovecot with GSSAPI support on `mail`. **Package change only — no configuration change, no behaviour change.** Enabling the mechanism is the follow-up issue, and it cannot start until this is verified. ## Why it is split this way `auth_mechanisms = plain gssapi` with GSSAPI **not** compiled in is a fatal Dovecot startup error — that is mail down, not degraded. So the build lands and is proven first, entirely inert, before any config references the mechanism. ## Confirmed starting state `dovecot-2.3.19.1`'s auth binary links no krb5: ``` /nix/store/7p6n6zv1mvl6dlqh9npg16swa0fc4wgz-dovecot-2.3.19.1/libexec/dovecot/auth → no krb5 linkage ``` nixpkgs' `pkgs/by-name/do/dovecot/generic.nix` on `nixos-26.05` — the channel `hosts/mail/channel` pins — has no kerberos in `buildInputs`, no `--with-gssapi` in `configureFlags`, and exposes no `withGSSAPI` argument. `.override` therefore cannot help; the derivation's attributes have to be extended. ## Scope Add `krb5` to `buildInputs` and `--with-gssapi=yes` to `configureFlags` on the dovecot 2.3 package `mail` runs. Use `=yes` (linked into the auth binary, which is what the verification below checks) rather than `=plugin`. Nothing else changes. `auth_mechanisms`, the LDAP passdb, `auth_bind` and every other Dovecot setting stay exactly as they are. ## The pigeonhole trap — this is how this change breaks mail `hosts/mail/modules/dovecot.nix:263` installs `config.services.dovecot2.package.dovecot_pigeonhole`, and the comment directly above it records that a dovecot/pigeonhole version mismatch **already broke sieve/managesieve on this host once**. A naive `overrideAttrs` can leave a `passthru` still pointing at the *un-overridden* dovecot, which would install sieve modules built against a different binary. Establish which mechanism actually propagates rather than assuming: an overlay replacing `dovecot_2_3` is more likely to than an inline `overrideAttrs` at the `services.dovecot2.package` site. `mail` currently defines no `nixpkgs.overlays`; `hosts/nb` and `hosts/web-arm` show the in-repo pattern for adding one. ## Cost, for context One C autotools project — roughly 5–10 minutes on this host, no JVM, no Node, no Python. Nix rebuilds it only when the derivation changes, i.e. when the channel moves dovecot: a few times a year on 26.05, not on every bento rebuild. If the build ever fails after an upstream bump, `mail` stays on its previous generation — stale rather than down — so leave a comment explaining the override for whoever hits that. ## Out of scope — all of it belongs to the follow-up - The `imap/imap.cloonar.com` service principal and its keytab - `auth_mechanisms`, `auth_krb5_keytab`, `auth_username_format` - Anything on `nb` or in Thunderbird - SMTP/Postfix, and Dovecot master-user/authzid ## Verification - `scripts/pre-commit` dry-builds `mail`. Human, after deploy — the first two are the gate for starting the follow-up: 1. The auth binary now links GSSAPI: ```bash a=$(find /nix/store -maxdepth 4 -path '*dovecot-2*/libexec/dovecot/auth' | head -1) ldd "$a" | grep -iE 'gss|krb5' ``` 2. Pigeonhole was rebuilt against the override — `readlink -f $(command -v sieve-test)` must resolve under the **same** dovecot store path as above. 3. `systemctl status dovecot2` clean; send and receive mail normally. 4. **A sieve filter still fires.** This is the pigeonhole risk, and it is the one failure that would not be obvious from the service status. Rollback is reverting the commit.

dominik.polakovics added the

ready-for-agent

label

2026-08-07 22:51:21 +02:00

dominik.polakovics changed title from ~~Dovecot GSSAPI: build with kerberos and accept Kerberos tickets for IMAP (experiment)~~ to Dovecot: build with GSSAPI support (package change only)

2026-08-07 22:54:39 +02:00

dominik.polakovics referenced this issue

2026-08-07 22:55:10 +02:00

Dovecot GSSAPI: enable the mechanism and authenticate Thunderbird by ticket #291

dominik.polakovics referenced this issue from a pull request that will close it,

2026-08-07 23:39:55 +02:00

feat(mail): build dovecot 2.3 with GSSAPI #293

dominik.polakovics closed this issue

2026-08-07 23:41:55 +02:00

dominik.polakovics referenced this issue

2026-08-08 02:31:14 +02:00

ADR-0022: record what the Dovecot GSSAPI work actually cost, and the keytab invariant #297