[OE-core] [PATCH] openssh: build support openssl 1.1

[Alexander Kanavin]

2018-09-11 17:18 GMT+02:00 Hongxu Jia <hongxu.jia at windriver.com>:
> Here are my suggestions
>
> 1: Replace dependence openssl10  -> openssl, such as this fix, and drop
> recipe openssl10 finally;
>     1 (openssh) in oe-core, 3 (umip, ipsec-tools, mailx) in oe, 3
> (openssl-tpm-engine,
>     tpm-tools, trousers) in meta-secure-core
>
> Or 2: Unify openssl,openssl10 and libressl to provide one ssl,
>         we could add PROVIDER = 'virtual/ssl' to above recipe, any recipe
>         depends on `openssl' will be replced with `virtual/ssl', the recipe
>        depends on `openssl10' will not be changed.
>
>        Set PREFERRED_PROVIDER_virtual//ssl = "openssl | openssl10 |
> libressl" in conf
>
> Or 3: Revert previously patch, rename recipe openssl10 -> openssl 1.0, and
> set
>       PREFERRED_VERSION

Option 1 creates a maintainability issue for openssh. You add the big
patch that no one understands, then someone else has to rebase it
later. Of course over time we need to move everything to 1.1 across
all layers, but at the moment it is not feasible for openssh
specifically.

Option 2 implies that openssl, openssl10 and libressl are all drop-in
replacements for each other which is not true. openssl 1.1 API is
significantly different, and choosing one or the other option will
cause significant build breakage. Especially as upstream components
begin to drop 1.0 support.

Option 3 has the same issue.

Can I suggest option 4? As openssh is already patched in meta-selinux,
and the problem is specific to that layer, you can add the 1.1 support
patch there, and replace the openssl10 dependency with openssl (1.1).
If, over time, that patch can be rebased to new versions of openssh
without too much trouble, and upstream still hasn't taken it, we can
re-consider adding it to oe-core.

Alex