[PATCH 0/3] Engine configuration series

[Florian Eckert]

Hello Eneas,

On 2021-04-28 14:17, Eneas U de Queiroz wrote:
> This series builds upon what was first started by Daniel Danzberger,
> with some suggestions by Florian Eckert to enable the engines when they
> are installed.
> 
> The series split is subject to discussion:
> - the first commit does a patch cleanup proposed by Rosen Penev, and
>   also splits the configuration from one monolithic file to one file 
> per
>   engine, and also an engines list.
> - the sencond implements my first proposal, of enabling engines during
>   their installation.  It introduces an engine.mk file that provides
>   menu placement, basic dependencies and the postinst, postrm functions
>   for engine packages, and can be used for out of tree engine packages.
> - the third commit introduces uci configuration, and does the engines
>   list generation during startup, or when an engine package is
>   installed or removed.
> 
> The first commit received basic testing on mvebu running master,
> covering afalg and devcrpto engines built as modules.
> 
> The second and third commits had testing expanded to checking built-in
> engine builds.
> 
> I have not squashed the commits, but I do think that 2 and 3 may be
> squashed if 3 is merged.  The first one is just cleanup, and the second
> adds complexity that ended up being removed by the third commit.
> Nonetheless, all of them result in a working package.
> 
> I thought about expanding uci support to include other configuration
> commands, but it would drop the documentation provided by the current
> config files.  Besides, each engine has its own options, which would
> add complexity to config generation if you are to actually verify them.
> Passing unknown commands straight from uci to the config files would be
> simple and work, but it would be hard to find what options are
> available, compared to just reading the example configs provided
> otherwise.

I think the uci config options are great, you can build on
them and make the configuration for openssl better and can
finally be configured with the uci.

> openssl engine -vv would show the commands, with some basic description
> of them, but getting the supported arguments may not be 
> straightforward.
> For example, gost engine has "CRYPT_PARAMS: OID of default GOST 
> 28147-89
> parameters".  All I could do to help was to point to a header file 
> where
> the actual list of supported parameters is defined.

The only thing I have to say is that if the configuration no longer 
fits, then we
have a non-functioning openssl! You just have to know what you
are doing when you change the openssl configuration.

> After this is merged, I will adapt the two engines in the packages 
> feed.

I think we have to validate the uci options in the future in
the openssl service on startup.


Regards

Florian