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

[Hongxu Jia]

On 2018年09月12日 17:26, Alexander Kanavin wrote:
> 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.

It's a long term target, we should try to push upstream to accept
openssl 1.1, such as split one patch to multiple sub patches step
by step, make it more reviewable,  not only openssh, ideally any
recipe depends on 1.0 should be turned to 1.1

> 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.

Currently, use openssl10 as the standalone recipe to provide openssl,
everything works well in oe-core + oe.

As I mention before, there is still a issue at run time image. Even though
openssh depends on `openssl10',  but the `openssl' is installed at do_rootfs

It breaks DEPEND/RDEPENDS principle

[local.conf]
IMAGE_INSTALL_append = " openssh"
[local.conf]

$ bitbake core-image-minimal

[log.do_rootfs]
   Installing       : openssl-1.1.1~pre9-r0.core2_64
[log.do_rootfs]

The recipe depends on openssl10, but openssl10 will not be installed.
BTW, Is pre9 1.1.1 openssl a stable release?

> 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.

The meta-selinux only exposes the issue, any recipe depends on
openssl10 and indirect depends openssl will trigger the conflict.

A -> openssl10
A -> B
B -> openssl

In oe-core, the most common situation is any recipe depends on
openssl10 and python2/3, will have the problem

Only openssh patched to meta-selinux is not enough, there are  3
(umip, ipsec-tools, mailx) in oe, 3 (openssl-tpm-engine, tpm-tools,
trousers) in meta-secure-core required to be patched. I think it is
not acceptable for meta-selinux maintainer.

Hi RP,

What about your suggestions?

//Hongxu

> Alex