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

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]