[PATCH] package: openssl: Enable built engines per default

Eneas U de Queiroz cotequeiroz at gmail.com
Fri Apr 23 00:36:29 BST 2021

On Thu, Apr 22, 2021 at 3:55 AM Daniel Danzberger <daniel at dd-wrt.com> wrote:
> Automatically enable an engine in the openssl.cnf if it has been build.
> Before this change, /etc/openssl.cnf had to be edited manually on the
> system to enable the engine.

> +define Package/libopenssl-conf/enable
> +       $(if $(CONFIG_PACKAGE_libopenssl-$(2)),sed -i s/^\#*$(2)=$(2)/$(2)=$(2)/ $(1)/etc/ssl/openssl.cnf)
> +endef

>  define Package/libopenssl-conf/install
>         $(INSTALL_DIR) $(1)/etc/ssl
>         $(CP) $(PKG_INSTALL_DIR)/etc/ssl/openssl.cnf $(1)/etc/ssl/
> +       $(call Package/libopenssl-conf/enable,$(1),devcrypto)
> +       $(call Package/libopenssl-conf/enable,$(1),afalg)
> +       $(call Package/libopenssl-conf/enable,$(1),padlock)

Hi Daniel

The problem with this is that it will enable the config for all
engines in the bots configuration (all packages =m).  OpenSSL will
stop loading the engines past the point where one of them fails.  It
may do it silently, or it may show an error.  If you run the `openssl
engine` command (no flags or with -c), it will show the error; if you
add the `-t` flag, the error message is gone.  In either case, the
engines configured after the first failed one will not load.  Suppose
that you install the afalg engine, but not devcrypto.  When it loads
the config file, devcrypto comes first, and openssl will fail to find
it; then the afalg engine will not be loaded.

I do like the idea, though. My first thought was to add an install
script to the engine packages.  The problem is that the config file
may have been changed in a way that sed may produce unwanted results.
It can be mitigated by configuring engines in a separate file, so only
that file needs to be changed.  It will have a nice effect, that a
feed-installed engine can configure itself without needing a config
section added to the openssl-conf package.

Another option, which may be the easiest and safest, is to use your
approach, but only uncomment the engines built into the firmware (=y),
and not the ones built as modules.



More information about the openwrt-devel mailing list