| Message ID | 20210428121704.19707-1-cotequeiroz@gmail.com |
|---|---|
| Headers | show |
| Series | Engine configuration series | expand |
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