Regression/Bug report: crypt_private_key_file (for crypt_global_private_key) no longer supports inline base64 (from userdb) in dev branch

Ömer Güven via dovecot <[email protected]> Sun, 5 Apr 2026 21:18:47 +0200
Newsgroups gmane.mail.imap.dovecot
Message-ID <[email protected]>
Hi,

I’ve run into what appears to be a regression (or at least a behavioral change) in Dovecot 3.3.0+ / current HEAD regarding crypt_private_key_file handling for the crypt_global_private_key.

I don‘t use per-folder user keys but a global encryption key per user.

Previously, it was possible to provide the private key via userdb using an inline base64:-encoded PEM directly to the crypt_global_private_key_file and Dovecot would correctly parse and use it.

With the latest config scheme change, this no longer works, as you cannot really set named config variables from userdb. I did workaround by setting a custom userdb variable and setting the needed named/filter variables manually in the config file.
To make it work, I had to enclose the config in a „protocol imap“ scope.
The crypt_global_public_key_file is accessible from userdb (as it is not within a named filter scope), so inline-base64 works as with Dovecot 2.3+.

When using the following workaround to reach the scoped variables, Dovecot tries to load the file „inline:BASE64ENCODEDPEM“ as a literal filename (error open(inline:AB….C==) failed):

protocol imap {
  crypt_global_private_key user {
    crypt_private_key_file = %{userdb:private_key_file}
    crypt_private_key_password = %{userdb:private_key_password}
  }
}

As a workaround, I now have to:
	•	store the private key as a file (e.g. %{home}/privkey.pem)
	•	pass only the password via userdb
	•	inject the path indirectly via static config + userdb variables

This works, but is less elegant:

protocol imap {
  crypt_global_private_key user {
    crypt_private_key_file = %{home}/privkey.pem
    crypt_private_key_password = %{userdb:private_key_password}
  }
}

Again, with the new named filter mechanism, it’s no longer possible to directly inject such config values via userdb, which makes fully dynamic per-user key provisioning harder. I now have to export all encrypted private keys from the database to the users home directory.

Ömer

_______________________________________________
dovecot mailing list -- [email protected]
To unsubscribe send an email to [email protected]