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

> 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]