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
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
