[PATCH 0/3] Engine configuration series
fe at dev.tdt.de
Thu Apr 29 07:52:56 BST 2021
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
> 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
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
> For example, gost engine has "CRYPT_PARAMS: OID of default GOST
> parameters". All I could do to help was to point to a header file
> 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
I think we have to validate the uci options in the future in
the openssl service on startup.
More information about the openwrt-devel