On 2018年09月11日 18:39, Alexander Kanavin wrote:
I'm afraid I have changed my mind, and I have to say no to this. It is
*not* a backport, it is a very large patch that nobody understands, it
will need to be rebased every time there is new openssh out, we cannot
rely on Fedora doing this, as they apply this patch on top of their
other patches. Meanwhile, upstream pull request has been stalled for a
very long time and just isn't going anywhere.

I would suggest you make openssh depend on libressl and find out why
it is working everywhere except arm64 - that's the only reason we
haven't done it yet.

Use openssh depends on libressl could not fix the issue, which also conflicts
with openssl in the meta-selinux example (they provides the same headers/libraries)

The root cause is since rename libssl (1.0) -> libssl10, and drop PRFERRED_VERSION,
there are multiple recipes provide ssl (openssl, openssl10, libressl) with different name

BTW, even though openssh depends `openssl10',  the `openssl' is installed
to 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.

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


//Hongxu


Alex