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

To make it more complicated:
You can set it in
doveadm -o crypt_global_private_key/user/crypt_private_key_file=inline:…
but not in userdb the same way. (I‘m returning it via passdb lua, with userdb_ prefixed.) Setting userdb_crypt_private_key_file without any named filter works inexpectedly. So userdb returned variables are somehow parsed differently (maybe slashes aren‘t split) than doveadm options with divergent behavior and the documentation is wrong about that. :(
I guess the way it works now is unintented and won‘t work in the future.

> Am 07.04.2026 um 10:04 schrieb Ömer Güven <[email protected]>:
> Yes, that didn‘t work either (by removing inline: from the variable and setting it in the config).
> I discovered yesterday that you can set „crypt_private_key_file“ in userdb and that this sets the global private key file (note that there is no prefix/named filter).
> 
> I can live with that, but I guess the correct way should‘ve be „crypt_global_private_key/user/crypt_private_key_file“, but latter is non-functional, despite documented. (Named list filter „user“ is set with empty content in config, so it should exist, but isn‘t reachable from userdb…)
> 
>> Am 07.04.2026 um 07:11 schrieb Aki Tuomi <[email protected]>:
>> 
>>> On 05/04/2026 22:18 EEST Ömer Güven via dovecot <[email protected]> wrote:
>>> 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
>>>  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):
>> 
>>>          }
>>>  As a workaround, I now have to:
>>>           o     store the private key as a file (e.g. %{home}/privkey.pem)
>>>           o     pass only the password via userdb
>>>           o     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.
>>>  Oemer
>>> _______________________________________________
>>> dovecot mailing list -- [email protected]
>>> To unsubscribe send an email to [email protected]
>> 
>> 
>> Hi!
>> 
>> Did you try
>> 
>> protocol imap {
>>  crypt_global_private_key user {
>>       crypt_private_key_file = inline:%{userdb:private_key_file}
>>       crypt_private_key_password = %{userdb:private_key_password}
>>  }
>> }
>> 
>> See https://doc.dovecot.org/2.4.3/core/settings/types.html#file
>> 
>> Aki

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