How to backport openssl to Sumo

How to backport openssl to Sumo

[Ryan Harkin]

[-- Attachment #1: Type: text/plain, Size: 1052 bytes --]

Hi all,

I'm struggling with backporting OpenSSL to my Sumo build [1], so wondered
if anyone else had done something similar with success.

I copied "meta/recipes-connectivity/openssl" from Poky master branch [2]
into my own layer [3]. It didn't pick up, so I discovered I needed to add
a PREFERRED_VERSION, eg:

+PREFERRED_VERSION_openssl ?= "1.1.%"
+PREFERRED_VERSION_openssl-native ?= "1.1.%"
+PREFERRED_VERSION_nativesdk-openssl ?= "1.1.%"

Now it builds fine. However, I no longer have /usr/bin/openssl in my disk
image.

It doesn't appear in FILES_${PN}, and adding it to the recipes doesn't seem
to make any difference.

What am I missing?

Thanks,
Ryan.

[1] I'm looking for CVE fixes, 1.0.2p has a lot of CVEs.

[2] http://git.yoctoproject.org/git/poky
I'm at SHA a616ffebdc, so I copied openssl_1.1.1d.bb and all the other
files in the directory.

[3] I have a clone of Linaro's meta-backports. I'm trying to generate a
patch to submit for review there.
https://git.linaro.org/openembedded/meta-backports.git

[-- Attachment #2: Type: text/html, Size: 1555 bytes --]

Re: How to backport openssl to Sumo

[Ross Burton]

On 20/11/2019 18:18, Ryan Harkin wrote:
> Now it builds fine. However, I no longer have /usr/bin/openssl in my 
> disk image.

$ oe-pkgdata-util find-path /usr/bin/openssl
openssl-bin: /usr/bin/openssl

Did you try adding openssl-bin to your image explicitly?

Ross

Re: How to backport openssl to Sumo

[Ryan Harkin]

[-- Attachment #1: Type: text/plain, Size: 1019 bytes --]

On Wed, 20 Nov 2019 at 18:28, Ross Burton <ross.burton@intel.com> wrote:

> On 20/11/2019 18:18, Ryan Harkin wrote:
> > Now it builds fine. However, I no longer have /usr/bin/openssl in my
> > disk image.
>
> $ oe-pkgdata-util find-path /usr/bin/openssl
> openssl-bin: /usr/bin/openssl
>
> Did you try adding openssl-bin to your image explicitly?
>

No, I hadn't even thought about that, as it was already working before I
updated.

I added openssl-bin to my RDEPENDS for my packagegroup, right after the
openssl entry. I tried to manually bitbake openssl-bin, and it complained:

$ bitbake openssl-bin
[snip]
ERROR: Nothing PROVIDES 'openssl-bin'. Close matches:
  openssl
  openssl-native
  openssl10
  openssl RPROVIDES openssl-bin

So I guess that isn't the problem?


>
> Ross
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

[-- Attachment #2: Type: text/html, Size: 1815 bytes --]

Re: How to backport openssl to Sumo

[Mark Hatle]

On 11/20/19 12:18 PM, Ryan Harkin wrote:
> Hi all,
> 
> I'm struggling with backporting OpenSSL to my Sumo build [1], so wondered if
> anyone else had done something similar with success.
> 
> I copied "meta/recipes-connectivity/openssl" from Poky master branch [2] into my
> own layer [3]. It didn't pick up, so I discovered I needed to add
> a PREFERRED_VERSION, eg:
> 
> +PREFERRED_VERSION_openssl ?= "1.1.%"
> +PREFERRED_VERSION_openssl-native ?= "1.1.%"
> +PREFERRED_VERSION_nativesdk-openssl ?= "1.1.%"
> 
> Now it builds fine. However, I no longer have /usr/bin/openssl in my disk image.
> 
> It doesn't appear in FILES_${PN}, and adding it to the recipes doesn't seem to
> make any difference.
> 
> What am I missing?
> 
> Thanks,
> Ryan.
> 
> [1] I'm looking for CVE fixes, 1.0.2p has a lot of CVEs.

You know that 1.0.2 and 1.1 APIs are not compatible?  So you will need to update
everything that needs OpenSSL to understand the new API.

For CVE fixes, typically you would patch 1.0.2p, or update to the latest
(1.0.2t) as you go.  (If you have an OSV, this should be part of the services
that they offer you.)

In my opinion, 1.0.2 will be around for at least another 4-5 years due to the
number of people actively using it in the world.  Until 1.1/3.0 (won't be a 2.0
from what I read) exists and has a FIPS-140-2 support available -- people will
continue to use 1.0.2 and maintain it as necessary for security.

As an FYI:  http://git.yoctoproject.org/cgit/cgit.cgi/meta-openssl102/

This version is for thud, warrior, zeus and master.  It is intended to be
maintained until either 1.0.2 is no longer maintainable -- or the FIPS-140-2
needs have been met by OpenSSL.

--Mark

> [2] http://git.yoctoproject.org/git/poky
> I'm at SHA a616ffebdc, so I copied openssl_1.1.1d.bb <http://openssl_1.1.1d.bb>
> and all the other files in the directory.
> 
> [3] I have a clone of Linaro's meta-backports. I'm trying to generate a patch to
> submit for review there.
> https://git.linaro.org/openembedded/meta-backports.git
> 

Re: How to backport openssl to Sumo

[Ryan Harkin]

[-- Attachment #1: Type: text/plain, Size: 2691 bytes --]

On Wed, 20 Nov 2019 at 18:36, Mark Hatle <mark.hatle@kernel.crashing.org>
wrote:

>
>
> On 11/20/19 12:18 PM, Ryan Harkin wrote:
> > Hi all,
> >
> > I'm struggling with backporting OpenSSL to my Sumo build [1], so
> wondered if
> > anyone else had done something similar with success.
> >
> > I copied "meta/recipes-connectivity/openssl" from Poky master branch [2]
> into my
> > own layer [3]. It didn't pick up, so I discovered I needed to add
> > a PREFERRED_VERSION, eg:
> >
> > +PREFERRED_VERSION_openssl ?= "1.1.%"
> > +PREFERRED_VERSION_openssl-native ?= "1.1.%"
> > +PREFERRED_VERSION_nativesdk-openssl ?= "1.1.%"
> >
> > Now it builds fine. However, I no longer have /usr/bin/openssl in my
> disk image.
> >
> > It doesn't appear in FILES_${PN}, and adding it to the recipes doesn't
> seem to
> > make any difference.
> >
> > What am I missing?
> >
> > Thanks,
> > Ryan.
> >
> > [1] I'm looking for CVE fixes, 1.0.2p has a lot of CVEs.
>
> You know that 1.0.2 and 1.1 APIs are not compatible?  So you will need to
> update
> everything that needs OpenSSL to understand the new API.
>

So far, we're only using it in a shell script to sign an image and later
verify the image, so I've assumed, perhaps naively, that the API changes
won't matter...

>
> For CVE fixes, typically you would patch 1.0.2p, or update to the latest
> (1.0.2t) as you go.  (If you have an OSV, this should be part of the
> services
> that they offer you.)


> In my opinion, 1.0.2 will be around for at least another 4-5 years due to
> the
> number of people actively using it in the world.  Until 1.1/3.0 (won't be
> a 2.0
> from what I read) exists and has a FIPS-140-2 support available -- people
> will
> continue to use 1.0.2 and maintain it as necessary for security.
>
> As an FYI:  http://git.yoctoproject.org/cgit/cgit.cgi/meta-openssl102/
>
> This version is for thud, warrior, zeus and master.  It is intended to be
> maintained until either 1.0.2 is no longer maintainable -- or the
> FIPS-140-2
> needs have been met by OpenSSL.
>

Great, that looks like a better option anyway, assuming it has the latest
fixes I need, and doesn't give me the same build problem.  Thanks for
pointing it out. I'll give it a go.

Thanks,
Ryan.


>
> --Mark
>
> > [2] http://git.yoctoproject.org/git/poky
> > I'm at SHA a616ffebdc, so I copied openssl_1.1.1d.bb <
> http://openssl_1.1.1d.bb>
> > and all the other files in the directory.
> >
> > [3] I have a clone of Linaro's meta-backports. I'm trying to generate a
> patch to
> > submit for review there.
> > https://git.linaro.org/openembedded/meta-backports.git
> >
>

[-- Attachment #2: Type: text/html, Size: 4210 bytes --]

Re: How to backport openssl to Sumo

[Mark Hatle]

On 11/20/19 1:06 PM, Ryan Harkin wrote:
> 
> 
> On Wed, 20 Nov 2019 at 18:36, Mark Hatle <mark.hatle@kernel.crashing.org
> <mailto:mark.hatle@kernel.crashing.org>> wrote:
> 
> 
> 
>     On 11/20/19 12:18 PM, Ryan Harkin wrote:
>     > Hi all,
>     >
>     > I'm struggling with backporting OpenSSL to my Sumo build [1], so wondered if
>     > anyone else had done something similar with success.
>     >
>     > I copied "meta/recipes-connectivity/openssl" from Poky master branch [2]
>     into my
>     > own layer [3]. It didn't pick up, so I discovered I needed to add
>     > a PREFERRED_VERSION, eg:
>     >
>     > +PREFERRED_VERSION_openssl ?= "1.1.%"
>     > +PREFERRED_VERSION_openssl-native ?= "1.1.%"
>     > +PREFERRED_VERSION_nativesdk-openssl ?= "1.1.%"
>     >
>     > Now it builds fine. However, I no longer have /usr/bin/openssl in my disk
>     image.
>     >
>     > It doesn't appear in FILES_${PN}, and adding it to the recipes doesn't seem to
>     > make any difference.
>     >
>     > What am I missing?
>     >
>     > Thanks,
>     > Ryan.
>     >
>     > [1] I'm looking for CVE fixes, 1.0.2p has a lot of CVEs.
> 
>     You know that 1.0.2 and 1.1 APIs are not compatible?  So you will need to update
>     everything that needs OpenSSL to understand the new API.
> 
> 
> So far, we're only using it in a shell script to sign an image and later verify
> the image, so I've assumed, perhaps naively, that the API changes won't matter...

Correct, but there may be other components of the system that could be using the
API that you are unaware of.  On a system as old as Sumo, you will need to take
precautions to ensure that ONLY the 1.1x version is being used.  (There may be
an openssl10 for compatibility that will need to be blacklisted.)

> 
>     For CVE fixes, typically you would patch 1.0.2p, or update to the latest
>     (1.0.2t) as you go.  (If you have an OSV, this should be part of the services
>     that they offer you.) 
> 
> 
>     In my opinion, 1.0.2 will be around for at least another 4-5 years due to the
>     number of people actively using it in the world.  Until 1.1/3.0 (won't be a 2.0
>     from what I read) exists and has a FIPS-140-2 support available -- people will
>     continue to use 1.0.2 and maintain it as necessary for security.
> 
>     As an FYI:  http://git.yoctoproject.org/cgit/cgit.cgi/meta-openssl102/
> 
>     This version is for thud, warrior, zeus and master.  It is intended to be
>     maintained until either 1.0.2 is no longer maintainable -- or the FIPS-140-2
>     needs have been met by OpenSSL.
> 
> 
> Great, that looks like a better option anyway, assuming it has the latest fixes
> I need, and doesn't give me the same build problem.  Thanks for pointing it out.
> I'll give it a go.

It's better to work with the Sumo version for your needs.  I just posted that as
an example of openssl 1.0.2 being needed still by others, even as oe-core/Yocto
Project have changed their defaults.

--Mark

> Thanks,
> Ryan.
>  
> 
> 
>     --Mark
> 
>     > [2] http://git.yoctoproject.org/git/poky
>     > I'm at SHA a616ffebdc, so I copied openssl_1.1.1d.bb
>     <http://openssl_1.1.1d.bb> <http://openssl_1.1.1d.bb>
>     > and all the other files in the directory.
>     >
>     > [3] I have a clone of Linaro's meta-backports. I'm trying to generate a
>     patch to
>     > submit for review there.
>     > https://git.linaro.org/openembedded/meta-backports.git
>     >
> 

Re: How to backport openssl to Sumo

[Andre McCurdy]

On Wed, Nov 20, 2019 at 11:09 AM Mark Hatle
<mark.hatle@kernel.crashing.org> wrote:
> On 11/20/19 1:06 PM, Ryan Harkin wrote:
> > On Wed, 20 Nov 2019 at 18:36, Mark Hatle <mark.hatle@kernel.crashing.org
> > <mailto:mark.hatle@kernel.crashing.org>> wrote:
> >
> >     You know that 1.0.2 and 1.1 APIs are not compatible?  So you will need to update
> >     everything that needs OpenSSL to understand the new API.
> >
> >
> > So far, we're only using it in a shell script to sign an image and later verify
> > the image, so I've assumed, perhaps naively, that the API changes won't matter...
>
> Correct, but there may be other components of the system that could be using the
> API that you are unaware of.  On a system as old as Sumo, you will need to take
> precautions to ensure that ONLY the 1.1x version is being used.  (There may be
> an openssl10 for compatibility that will need to be blacklisted.)
>
> >     For CVE fixes, typically you would patch 1.0.2p, or update to the latest
> >     (1.0.2t) as you go.  (If you have an OSV, this should be part of the services
> >     that they offer you.)
> >
> >
> >     In my opinion, 1.0.2 will be around for at least another 4-5 years due to the
> >     number of people actively using it in the world.  Until 1.1/3.0 (won't be a 2.0
> >     from what I read) exists and has a FIPS-140-2 support available -- people will
> >     continue to use 1.0.2 and maintain it as necessary for security.
> >
> >     As an FYI:  http://git.yoctoproject.org/cgit/cgit.cgi/meta-openssl102/
> >
> >     This version is for thud, warrior, zeus and master.  It is intended to be
> >     maintained until either 1.0.2 is no longer maintainable -- or the FIPS-140-2
> >     needs have been met by OpenSSL.
> >
> >
> > Great, that looks like a better option anyway, assuming it has the latest fixes
> > I need, and doesn't give me the same build problem.  Thanks for pointing it out.
> > I'll give it a go.
>
> It's better to work with the Sumo version for your needs.  I just posted that as
> an example of openssl 1.0.2 being needed still by others, even as oe-core/Yocto
> Project have changed their defaults.

If you want an up to date openssl 1.0.2 recipe which is compatible
with Sumo, you can find one here:

  https://github.com/armcc/meta-plumewifi

I'm only actively testing it with OE 1.6 (Daisy) and OE 2.7 (Warrior)
but it should work for all versions in between (and if it doesn't I'll
accept patches or try to fix it).

Re: How to backport openssl to Sumo

[Ryan Harkin]

[-- Attachment #1: Type: text/plain, Size: 3125 bytes --]

Hi Andre,

On Wed, 20 Nov 2019 at 19:27, Andre McCurdy <armccurdy@gmail.com> wrote:

> On Wed, Nov 20, 2019 at 11:09 AM Mark Hatle
> <mark.hatle@kernel.crashing.org> wrote:
> > On 11/20/19 1:06 PM, Ryan Harkin wrote:
> > > On Wed, 20 Nov 2019 at 18:36, Mark Hatle <
> mark.hatle@kernel.crashing.org
> > > <mailto:mark.hatle@kernel.crashing.org>> wrote:
> > >
> > >     You know that 1.0.2 and 1.1 APIs are not compatible?  So you will
> need to update
> > >     everything that needs OpenSSL to understand the new API.
> > >
> > >
> > > So far, we're only using it in a shell script to sign an image and
> later verify
> > > the image, so I've assumed, perhaps naively, that the API changes
> won't matter...
> >
> > Correct, but there may be other components of the system that could be
> using the
> > API that you are unaware of.  On a system as old as Sumo, you will need
> to take
> > precautions to ensure that ONLY the 1.1x version is being used.  (There
> may be
> > an openssl10 for compatibility that will need to be blacklisted.)
> >
> > >     For CVE fixes, typically you would patch 1.0.2p, or update to the
> latest
> > >     (1.0.2t) as you go.  (If you have an OSV, this should be part of
> the services
> > >     that they offer you.)
> > >
> > >
> > >     In my opinion, 1.0.2 will be around for at least another 4-5 years
> due to the
> > >     number of people actively using it in the world.  Until 1.1/3.0
> (won't be a 2.0
> > >     from what I read) exists and has a FIPS-140-2 support available --
> people will
> > >     continue to use 1.0.2 and maintain it as necessary for security.
> > >
> > >     As an FYI:
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-openssl102/
> > >
> > >     This version is for thud, warrior, zeus and master.  It is
> intended to be
> > >     maintained until either 1.0.2 is no longer maintainable -- or the
> FIPS-140-2
> > >     needs have been met by OpenSSL.
> > >
> > >
> > > Great, that looks like a better option anyway, assuming it has the
> latest fixes
> > > I need, and doesn't give me the same build problem.  Thanks for
> pointing it out.
> > > I'll give it a go.
> >
> > It's better to work with the Sumo version for your needs.  I just posted
> that as
> > an example of openssl 1.0.2 being needed still by others, even as
> oe-core/Yocto
> > Project have changed their defaults.
>
> If you want an up to date openssl 1.0.2 recipe which is compatible
> with Sumo, you can find one here:
>
>   https://github.com/armcc/meta-plumewifi
>
> I'm only actively testing it with OE 1.6 (Daisy) and OE 2.7 (Warrior)
> but it should work for all versions in between (and if it doesn't I'll
> accept patches or try to fix it).
>

Thanks! It looks similar to the tree Mark Hatle pointed out to me. Two
diffs jump out:

- Your repo adds the RPROVIDES for openssl-bin to "Be compatible with the
openssl 1.1.x recipe".
- Mark's repo has two extra patches:
           file://0001-Fix-BN_LLONG-breakage.patch \
           file://0001-Fix-DES_LONG-breakage.patch \

Regards,
Ryan.

[-- Attachment #2: Type: text/html, Size: 4284 bytes --]

Re: How to backport openssl to Sumo

[Andre McCurdy]

On Wed, Nov 20, 2019 at 11:44 AM Ryan Harkin <ryan.harkin@linaro.org> wrote:
>
> Hi Andre,
>
> On Wed, 20 Nov 2019 at 19:27, Andre McCurdy <armccurdy@gmail.com> wrote:
>>
>> On Wed, Nov 20, 2019 at 11:09 AM Mark Hatle
>> <mark.hatle@kernel.crashing.org> wrote:
>> > On 11/20/19 1:06 PM, Ryan Harkin wrote:
>> > > On Wed, 20 Nov 2019 at 18:36, Mark Hatle <mark.hatle@kernel.crashing.org
>> > > <mailto:mark.hatle@kernel.crashing.org>> wrote:
>> > >
>> > >     You know that 1.0.2 and 1.1 APIs are not compatible?  So you will need to update
>> > >     everything that needs OpenSSL to understand the new API.
>> > >
>> > >
>> > > So far, we're only using it in a shell script to sign an image and later verify
>> > > the image, so I've assumed, perhaps naively, that the API changes won't matter...
>> >
>> > Correct, but there may be other components of the system that could be using the
>> > API that you are unaware of.  On a system as old as Sumo, you will need to take
>> > precautions to ensure that ONLY the 1.1x version is being used.  (There may be
>> > an openssl10 for compatibility that will need to be blacklisted.)
>> >
>> > >     For CVE fixes, typically you would patch 1.0.2p, or update to the latest
>> > >     (1.0.2t) as you go.  (If you have an OSV, this should be part of the services
>> > >     that they offer you.)
>> > >
>> > >
>> > >     In my opinion, 1.0.2 will be around for at least another 4-5 years due to the
>> > >     number of people actively using it in the world.  Until 1.1/3.0 (won't be a 2.0
>> > >     from what I read) exists and has a FIPS-140-2 support available -- people will
>> > >     continue to use 1.0.2 and maintain it as necessary for security.
>> > >
>> > >     As an FYI:  http://git.yoctoproject.org/cgit/cgit.cgi/meta-openssl102/
>> > >
>> > >     This version is for thud, warrior, zeus and master.  It is intended to be
>> > >     maintained until either 1.0.2 is no longer maintainable -- or the FIPS-140-2
>> > >     needs have been met by OpenSSL.
>> > >
>> > >
>> > > Great, that looks like a better option anyway, assuming it has the latest fixes
>> > > I need, and doesn't give me the same build problem.  Thanks for pointing it out.
>> > > I'll give it a go.
>> >
>> > It's better to work with the Sumo version for your needs.  I just posted that as
>> > an example of openssl 1.0.2 being needed still by others, even as oe-core/Yocto
>> > Project have changed their defaults.
>>
>> If you want an up to date openssl 1.0.2 recipe which is compatible
>> with Sumo, you can find one here:
>>
>>   https://github.com/armcc/meta-plumewifi
>>
>> I'm only actively testing it with OE 1.6 (Daisy) and OE 2.7 (Warrior)
>> but it should work for all versions in between (and if it doesn't I'll
>> accept patches or try to fix it).
>
>
> Thanks! It looks similar to the tree Mark Hatle pointed out to me. Two diffs jump out:
>
> - Your repo adds the RPROVIDES for openssl-bin to "Be compatible with the openssl 1.1.x recipe".

Yes. Makes the transition between 1.0.2 and 1.1.x a little easier.

> - Mark's repo has two extra patches:
>            file://0001-Fix-BN_LLONG-breakage.patch \
>            file://0001-Fix-DES_LONG-breakage.patch \

Those patches are in my repo too - but only in the master-next branch.
They are not required for Sumo. (Since some might regard those patches
as a little "dubious" I don't pull them in unless they're necessary).

> Regards,
> Ryan.

Re: How to backport openssl to Sumo

[Ryan Harkin]

[-- Attachment #1: Type: text/plain, Size: 4313 bytes --]

On Wed, 20 Nov 2019 at 19:09, Mark Hatle <mark.hatle@kernel.crashing.org>
wrote:

>
>
> On 11/20/19 1:06 PM, Ryan Harkin wrote:
> >
> >
> > On Wed, 20 Nov 2019 at 18:36, Mark Hatle <mark.hatle@kernel.crashing.org
> > <mailto:mark.hatle@kernel.crashing.org>> wrote:
> >
> >
> >
> >     On 11/20/19 12:18 PM, Ryan Harkin wrote:
> >     > Hi all,
> >     >
> >     > I'm struggling with backporting OpenSSL to my Sumo build [1], so
> wondered if
> >     > anyone else had done something similar with success.
> >     >
> >     > I copied "meta/recipes-connectivity/openssl" from Poky master
> branch [2]
> >     into my
> >     > own layer [3]. It didn't pick up, so I discovered I needed to add
> >     > a PREFERRED_VERSION, eg:
> >     >
> >     > +PREFERRED_VERSION_openssl ?= "1.1.%"
> >     > +PREFERRED_VERSION_openssl-native ?= "1.1.%"
> >     > +PREFERRED_VERSION_nativesdk-openssl ?= "1.1.%"
> >     >
> >     > Now it builds fine. However, I no longer have /usr/bin/openssl in
> my disk
> >     image.
> >     >
> >     > It doesn't appear in FILES_${PN}, and adding it to the recipes
> doesn't seem to
> >     > make any difference.
> >     >
> >     > What am I missing?
> >     >
> >     > Thanks,
> >     > Ryan.
> >     >
> >     > [1] I'm looking for CVE fixes, 1.0.2p has a lot of CVEs.
> >
> >     You know that 1.0.2 and 1.1 APIs are not compatible?  So you will
> need to update
> >     everything that needs OpenSSL to understand the new API.
> >
> >
> > So far, we're only using it in a shell script to sign an image and later
> verify
> > the image, so I've assumed, perhaps naively, that the API changes won't
> matter...
>
> Correct, but there may be other components of the system that could be
> using the
> API that you are unaware of.  On a system as old as Sumo, you will need to
> take
> precautions to ensure that ONLY the 1.1x version is being used.  (There
> may be
> an openssl10 for compatibility that will need to be blacklisted.)
>

Good point. I'll check on it once I get it to work.


>
> >
> >     For CVE fixes, typically you would patch 1.0.2p, or update to the
> latest
> >     (1.0.2t) as you go.  (If you have an OSV, this should be part of the
> services
> >     that they offer you.)
> >
> >
> >     In my opinion, 1.0.2 will be around for at least another 4-5 years
> due to the
> >     number of people actively using it in the world.  Until 1.1/3.0
> (won't be a 2.0
> >     from what I read) exists and has a FIPS-140-2 support available --
> people will
> >     continue to use 1.0.2 and maintain it as necessary for security.
> >
> >     As an FYI:
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-openssl102/
> >
> >     This version is for thud, warrior, zeus and master.  It is intended
> to be
> >     maintained until either 1.0.2 is no longer maintainable -- or the
> FIPS-140-2
> >     needs have been met by OpenSSL.
> >
> >
> > Great, that looks like a better option anyway, assuming it has the
> latest fixes
> > I need, and doesn't give me the same build problem.  Thanks for pointing
> it out.
> > I'll give it a go.
>
> It's better to work with the Sumo version for your needs.  I just posted
> that as
> an example of openssl 1.0.2 being needed still by others, even as
> oe-core/Yocto
> Project have changed their defaults.
>

I pulled the whole openssl dir from your repo, added the layer.conf changes
to my layer.conf and rebuilt openssl and my image.

Unfortunately, I still have no /usr/bin/openssl in my disk image. So I've
added the RPROVIDES from Andre's in a vain attempt to get it to work:

RPROVIDES_${PN} += "openssl-bin"

... although I'm not hopeful it'll do the trick...


> --Mark
>
> > Thanks,
> > Ryan.
> >
> >
> >
> >     --Mark
> >
> >     > [2] http://git.yoctoproject.org/git/poky
> >     > I'm at SHA a616ffebdc, so I copied openssl_1.1.1d.bb
> >     <http://openssl_1.1.1d.bb> <http://openssl_1.1.1d.bb>
> >     > and all the other files in the directory.
> >     >
> >     > [3] I have a clone of Linaro's meta-backports. I'm trying to
> generate a
> >     patch to
> >     > submit for review there.
> >     > https://git.linaro.org/openembedded/meta-backports.git
> >     >
> >
>

[-- Attachment #2: Type: text/html, Size: 6464 bytes --]

Re: How to backport openssl to Sumo

[Ryan Harkin]

[-- Attachment #1: Type: text/plain, Size: 4694 bytes --]

On Wed, 20 Nov 2019 at 21:29, Ryan Harkin <ryan.harkin@linaro.org> wrote:

>
>
> On Wed, 20 Nov 2019 at 19:09, Mark Hatle <mark.hatle@kernel.crashing.org>
> wrote:
>
>>
>>
>> On 11/20/19 1:06 PM, Ryan Harkin wrote:
>> >
>> >
>> > On Wed, 20 Nov 2019 at 18:36, Mark Hatle <
>> mark.hatle@kernel.crashing.org
>> > <mailto:mark.hatle@kernel.crashing.org>> wrote:
>> >
>> >
>> >
>> >     On 11/20/19 12:18 PM, Ryan Harkin wrote:
>> >     > Hi all,
>> >     >
>> >     > I'm struggling with backporting OpenSSL to my Sumo build [1], so
>> wondered if
>> >     > anyone else had done something similar with success.
>> >     >
>> >     > I copied "meta/recipes-connectivity/openssl" from Poky master
>> branch [2]
>> >     into my
>> >     > own layer [3]. It didn't pick up, so I discovered I needed to add
>> >     > a PREFERRED_VERSION, eg:
>> >     >
>> >     > +PREFERRED_VERSION_openssl ?= "1.1.%"
>> >     > +PREFERRED_VERSION_openssl-native ?= "1.1.%"
>> >     > +PREFERRED_VERSION_nativesdk-openssl ?= "1.1.%"
>> >     >
>> >     > Now it builds fine. However, I no longer have /usr/bin/openssl in
>> my disk
>> >     image.
>> >     >
>> >     > It doesn't appear in FILES_${PN}, and adding it to the recipes
>> doesn't seem to
>> >     > make any difference.
>> >     >
>> >     > What am I missing?
>> >     >
>> >     > Thanks,
>> >     > Ryan.
>> >     >
>> >     > [1] I'm looking for CVE fixes, 1.0.2p has a lot of CVEs.
>> >
>> >     You know that 1.0.2 and 1.1 APIs are not compatible?  So you will
>> need to update
>> >     everything that needs OpenSSL to understand the new API.
>> >
>> >
>> > So far, we're only using it in a shell script to sign an image and
>> later verify
>> > the image, so I've assumed, perhaps naively, that the API changes won't
>> matter...
>>
>> Correct, but there may be other components of the system that could be
>> using the
>> API that you are unaware of.  On a system as old as Sumo, you will need
>> to take
>> precautions to ensure that ONLY the 1.1x version is being used.  (There
>> may be
>> an openssl10 for compatibility that will need to be blacklisted.)
>>
>
> Good point. I'll check on it once I get it to work.
>
>
>>
>> >
>> >     For CVE fixes, typically you would patch 1.0.2p, or update to the
>> latest
>> >     (1.0.2t) as you go.  (If you have an OSV, this should be part of
>> the services
>> >     that they offer you.)
>> >
>> >
>> >     In my opinion, 1.0.2 will be around for at least another 4-5 years
>> due to the
>> >     number of people actively using it in the world.  Until 1.1/3.0
>> (won't be a 2.0
>> >     from what I read) exists and has a FIPS-140-2 support available --
>> people will
>> >     continue to use 1.0.2 and maintain it as necessary for security.
>> >
>> >     As an FYI:
>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-openssl102/
>> >
>> >     This version is for thud, warrior, zeus and master.  It is intended
>> to be
>> >     maintained until either 1.0.2 is no longer maintainable -- or the
>> FIPS-140-2
>> >     needs have been met by OpenSSL.
>> >
>> >
>> > Great, that looks like a better option anyway, assuming it has the
>> latest fixes
>> > I need, and doesn't give me the same build problem.  Thanks for
>> pointing it out.
>> > I'll give it a go.
>>
>> It's better to work with the Sumo version for your needs.  I just posted
>> that as
>> an example of openssl 1.0.2 being needed still by others, even as
>> oe-core/Yocto
>> Project have changed their defaults.
>>
>
> I pulled the whole openssl dir from your repo, added the layer.conf
> changes to my layer.conf and rebuilt openssl and my image.
>
> Unfortunately, I still have no /usr/bin/openssl in my disk image. So I've
> added the RPROVIDES from Andre's in a vain attempt to get it to work:
>
> RPROVIDES_${PN} += "openssl-bin"
>
> ... although I'm not hopeful it'll do the trick...
>

It didn't work. Once thing that's puzzling me: where is the package
"openssl-bin"? I can only find references to it, but no package.


>
>> --Mark
>>
>> > Thanks,
>> > Ryan.
>> >
>> >
>> >
>> >     --Mark
>> >
>> >     > [2] http://git.yoctoproject.org/git/poky
>> >     > I'm at SHA a616ffebdc, so I copied openssl_1.1.1d.bb
>> >     <http://openssl_1.1.1d.bb> <http://openssl_1.1.1d.bb>
>> >     > and all the other files in the directory.
>> >     >
>> >     > [3] I have a clone of Linaro's meta-backports. I'm trying to
>> generate a
>> >     patch to
>> >     > submit for review there.
>> >     > https://git.linaro.org/openembedded/meta-backports.git
>> >     >
>> >
>>
>

[-- Attachment #2: Type: text/html, Size: 7210 bytes --]

Re: How to backport openssl to Sumo

[Andre McCurdy]

On Wed, Nov 20, 2019 at 2:41 PM Ryan Harkin <ryan.harkin@linaro.org> wrote:
> On Wed, 20 Nov 2019 at 21:29, Ryan Harkin <ryan.harkin@linaro.org> wrote:
>>
>> I pulled the whole openssl dir from your repo, added the layer.conf changes to my layer.conf and rebuilt openssl and my image.
>>
>> Unfortunately, I still have no /usr/bin/openssl in my disk image. So I've added the RPROVIDES from Andre's in a vain attempt to get it to work:
>>
>> RPROVIDES_${PN} += "openssl-bin"
>>
>> ... although I'm not hopeful it'll do the trick...
>
> It didn't work. Once thing that's puzzling me: where is the package "openssl-bin"? I can only find references to it, but no package.

The "openssl-bin" package is created by the openssl 1.1.x recipe.

Adding "openssl-bin" to RPROVIDES in the openssl 1.0.2 recipe is a
solution for users who are switching from openssl 1.1.x back to 1.0.2
and have an image which is tries to include the new openssl-bin
package. I don't think that's what you are trying to do (?).

If you are using openssl 1.0.2 then the openssl command line tool is
in the openssl package... so to include the openssl command line tool,
add the "openssl" package to your image.

If you are using openssl 1.1.x then the openssl command line tool is
in the openssl-bin package... so to include the openssl command line
tool, add the "openssl-bin" package to your image.

But anyway, in all cases, the way to debug what's going on isn't to
try random recipe changes and then rebuild the final image. Instead
you should build your chosen version of openssl, look in the
packages-split directory to see which package includes the openssl
command line tool and then add that package to your image.

Re: How to backport openssl to Sumo

[Mikko.Rapeli]

On Wed, Nov 20, 2019 at 03:53:14PM -0800, Andre McCurdy wrote:
> But anyway, in all cases, the way to debug what's going on isn't to
> try random recipe changes and then rebuild the final image. Instead
> you should build your chosen version of openssl, look in the
> packages-split directory to see which package includes the openssl
> command line tool and then add that package to your image.

Or enable buildhistory, build openssl and/or image(s), cd build/buildhistory
and git grep for the binaries needed to find out which binary package
they belong to.

-Mikko

Re: How to backport openssl to Sumo

[Ross Burton]

On 21/11/2019 08:05, Mikko.Rapeli@bmw.de wrote:
> On Wed, Nov 20, 2019 at 03:53:14PM -0800, Andre McCurdy wrote:
>> But anyway, in all cases, the way to debug what's going on isn't to
>> try random recipe changes and then rebuild the final image. Instead
>> you should build your chosen version of openssl, look in the
>> packages-split directory to see which package includes the openssl
>> command line tool and then add that package to your image.
> 
> Or enable buildhistory, build openssl and/or image(s), cd build/buildhistory
> and git grep for the binaries needed to find out which binary package
> they belong to.

packages-split doesn't work with rm_work or where sstate was used. 
buildhistory needs to be enabled and you need to dig manually.

It's better to use the tools that come out of the box:

$ oe-pkgdata-util find-path /usr/bin/openssl
openssl-bin: /usr/bin/openssl

That's a glob search, so **/*.py will find all built packages that ship 
Python code for example.

Ross

Re: How to backport openssl to Sumo

[Ryan Harkin]

[-- Attachment #1: Type: text/plain, Size: 2572 bytes --]

On Wed, 20 Nov 2019 at 23:53, Andre McCurdy <armccurdy@gmail.com> wrote:

> On Wed, Nov 20, 2019 at 2:41 PM Ryan Harkin <ryan.harkin@linaro.org>
> wrote:
> > On Wed, 20 Nov 2019 at 21:29, Ryan Harkin <ryan.harkin@linaro.org>
> wrote:
> >>
> >> I pulled the whole openssl dir from your repo, added the layer.conf
> changes to my layer.conf and rebuilt openssl and my image.
> >>
> >> Unfortunately, I still have no /usr/bin/openssl in my disk image. So
> I've added the RPROVIDES from Andre's in a vain attempt to get it to work:
> >>
> >> RPROVIDES_${PN} += "openssl-bin"
> >>
> >> ... although I'm not hopeful it'll do the trick...
> >
> > It didn't work. Once thing that's puzzling me: where is the package
> "openssl-bin"? I can only find references to it, but no package.
>
> The "openssl-bin" package is created by the openssl 1.1.x recipe.
>
> Adding "openssl-bin" to RPROVIDES in the openssl 1.0.2 recipe is a
> solution for users who are switching from openssl 1.1.x back to 1.0.2
> and have an image which is tries to include the new openssl-bin
> package. I don't think that's what you are trying to do (?).
>

Correct. I only tried it because the 1.0.2t recipe wasn't working.

To be clear - I have /usr/bin/openssl in my image when using 1.0.2p from
the Poky Sumo branch. When I add the 1.0.2t recipe to my own layer, openssl
builds without errors, but I don't get the binary.


> If you are using openssl 1.0.2 then the openssl command line tool is
> in the openssl package... so to include the openssl command line tool,
> add the "openssl" package to your image.
>
> If you are using openssl 1.1.x then the openssl command line tool is
> in the openssl-bin package... so to include the openssl command line
> tool, add the "openssl-bin" package to your image.
>
> But anyway, in all cases, the way to debug what's going on isn't to
> try random recipe changes and then rebuild the final image. Instead
> you should build your chosen version of openssl, look in the
> packages-split directory to see which package includes the openssl
> command line tool and then add that package to your image.
>

I don't have a packages-split. I was unaware of it, and reading the manual,
it seems I should have one. But I don't. Running 'bitbake -e openssl | grep
"PKGDEST="' tells me I should have one, but there are no instances in a
directory called "packages-split" in my tmp dir.

Anyway, I'm giving up for now. I'll come back to another time... or more
likely, get someone smarter than me to sort it out ;-)

[-- Attachment #2: Type: text/html, Size: 3493 bytes --]

Re: How to backport openssl to Sumo

[Nicolas Dechesne]

On Thu, Nov 21, 2019 at 2:15 PM Ryan Harkin <ryan.harkin@linaro.org> wrote:
>
>
>
> On Wed, 20 Nov 2019 at 23:53, Andre McCurdy <armccurdy@gmail.com> wrote:
>>
>> On Wed, Nov 20, 2019 at 2:41 PM Ryan Harkin <ryan.harkin@linaro.org> wrote:
>> > On Wed, 20 Nov 2019 at 21:29, Ryan Harkin <ryan.harkin@linaro.org> wrote:
>> >>
>> >> I pulled the whole openssl dir from your repo, added the layer.conf changes to my layer.conf and rebuilt openssl and my image.
>> >>
>> >> Unfortunately, I still have no /usr/bin/openssl in my disk image. So I've added the RPROVIDES from Andre's in a vain attempt to get it to work:
>> >>
>> >> RPROVIDES_${PN} += "openssl-bin"
>> >>
>> >> ... although I'm not hopeful it'll do the trick...
>> >
>> > It didn't work. Once thing that's puzzling me: where is the package "openssl-bin"? I can only find references to it, but no package.
>>
>> The "openssl-bin" package is created by the openssl 1.1.x recipe.
>>
>> Adding "openssl-bin" to RPROVIDES in the openssl 1.0.2 recipe is a
>> solution for users who are switching from openssl 1.1.x back to 1.0.2
>> and have an image which is tries to include the new openssl-bin
>> package. I don't think that's what you are trying to do (?).
>
>
> Correct. I only tried it because the 1.0.2t recipe wasn't working.
>
> To be clear - I have /usr/bin/openssl in my image when using 1.0.2p from the Poky Sumo branch. When I add the 1.0.2t recipe to my own layer, openssl builds without errors, but I don't get the binary.
>
>>
>> If you are using openssl 1.0.2 then the openssl command line tool is
>> in the openssl package... so to include the openssl command line tool,
>> add the "openssl" package to your image.
>>
>> If you are using openssl 1.1.x then the openssl command line tool is
>> in the openssl-bin package... so to include the openssl command line
>> tool, add the "openssl-bin" package to your image.
>>
>> But anyway, in all cases, the way to debug what's going on isn't to
>> try random recipe changes and then rebuild the final image. Instead
>> you should build your chosen version of openssl, look in the
>> packages-split directory to see which package includes the openssl
>> command line tool and then add that package to your image.
>
>
> I don't have a packages-split. I was unaware of it, and reading the manual, it seems I should have one. But I don't. Running 'bitbake -e openssl | grep "PKGDEST="' tells me I should have one, but there are no instances in a directory called "packages-split" in my tmp dir.

most likely because you are using rm_work.

>
> Anyway, I'm giving up for now. I'll come back to another time... or more likely, get someone smarter than me to sort it out ;-)
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: How to backport openssl to Sumo

[Ryan Harkin]

[-- Attachment #1: Type: text/plain, Size: 3215 bytes --]

On Thu, 21 Nov 2019 at 13:39, Nicolas Dechesne <nicolas.dechesne@linaro.org>
wrote:

> On Thu, Nov 21, 2019 at 2:15 PM Ryan Harkin <ryan.harkin@linaro.org>
> wrote:
> >
> >
> >
> > On Wed, 20 Nov 2019 at 23:53, Andre McCurdy <armccurdy@gmail.com> wrote:
> >>
> >> On Wed, Nov 20, 2019 at 2:41 PM Ryan Harkin <ryan.harkin@linaro.org>
> wrote:
> >> > On Wed, 20 Nov 2019 at 21:29, Ryan Harkin <ryan.harkin@linaro.org>
> wrote:
> >> >>
> >> >> I pulled the whole openssl dir from your repo, added the layer.conf
> changes to my layer.conf and rebuilt openssl and my image.
> >> >>
> >> >> Unfortunately, I still have no /usr/bin/openssl in my disk image. So
> I've added the RPROVIDES from Andre's in a vain attempt to get it to work:
> >> >>
> >> >> RPROVIDES_${PN} += "openssl-bin"
> >> >>
> >> >> ... although I'm not hopeful it'll do the trick...
> >> >
> >> > It didn't work. Once thing that's puzzling me: where is the package
> "openssl-bin"? I can only find references to it, but no package.
> >>
> >> The "openssl-bin" package is created by the openssl 1.1.x recipe.
> >>
> >> Adding "openssl-bin" to RPROVIDES in the openssl 1.0.2 recipe is a
> >> solution for users who are switching from openssl 1.1.x back to 1.0.2
> >> and have an image which is tries to include the new openssl-bin
> >> package. I don't think that's what you are trying to do (?).
> >
> >
> > Correct. I only tried it because the 1.0.2t recipe wasn't working.
> >
> > To be clear - I have /usr/bin/openssl in my image when using 1.0.2p from
> the Poky Sumo branch. When I add the 1.0.2t recipe to my own layer, openssl
> builds without errors, but I don't get the binary.
> >
> >>
> >> If you are using openssl 1.0.2 then the openssl command line tool is
> >> in the openssl package... so to include the openssl command line tool,
> >> add the "openssl" package to your image.
> >>
> >> If you are using openssl 1.1.x then the openssl command line tool is
> >> in the openssl-bin package... so to include the openssl command line
> >> tool, add the "openssl-bin" package to your image.
> >>
> >> But anyway, in all cases, the way to debug what's going on isn't to
> >> try random recipe changes and then rebuild the final image. Instead
> >> you should build your chosen version of openssl, look in the
> >> packages-split directory to see which package includes the openssl
> >> command line tool and then add that package to your image.
> >
> >
> > I don't have a packages-split. I was unaware of it, and reading the
> manual, it seems I should have one. But I don't. Running 'bitbake -e
> openssl | grep "PKGDEST="' tells me I should have one, but there are no
> instances in a directory called "packages-split" in my tmp dir.
>
> most likely because you are using rm_work.
>

Yes, I am! Thanks, Nico.


>
> >
> > Anyway, I'm giving up for now. I'll come back to another time... or more
> likely, get someone smarter than me to sort it out ;-)
> > --
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

[-- Attachment #2: Type: text/html, Size: 4691 bytes --]

Re: How to backport openssl to Sumo

[Andre McCurdy]

On Thu, Nov 21, 2019 at 5:53 AM Ryan Harkin <ryan.harkin@linaro.org> wrote:
> On Thu, 21 Nov 2019 at 13:39, Nicolas Dechesne <nicolas.dechesne@linaro.org> wrote:
>> On Thu, Nov 21, 2019 at 2:15 PM Ryan Harkin <ryan.harkin@linaro.org> wrote:
>> > On Wed, 20 Nov 2019 at 23:53, Andre McCurdy <armccurdy@gmail.com> wrote:
>> >> On Wed, Nov 20, 2019 at 2:41 PM Ryan Harkin <ryan.harkin@linaro.org> wrote:
>> >> > On Wed, 20 Nov 2019 at 21:29, Ryan Harkin <ryan.harkin@linaro.org> wrote:
>> >> >>
>> >> >> I pulled the whole openssl dir from your repo, added the layer.conf changes to my layer.conf and rebuilt openssl and my image.
>> >> >>
>> >> >> Unfortunately, I still have no /usr/bin/openssl in my disk image. So I've added the RPROVIDES from Andre's in a vain attempt to get it to work:
>> >> >>
>> >> >> RPROVIDES_${PN} += "openssl-bin"
>> >> >>
>> >> >> ... although I'm not hopeful it'll do the trick...
>> >> >
>> >> > It didn't work. Once thing that's puzzling me: where is the package "openssl-bin"? I can only find references to it, but no package.
>> >>
>> >> The "openssl-bin" package is created by the openssl 1.1.x recipe.
>> >>
>> >> Adding "openssl-bin" to RPROVIDES in the openssl 1.0.2 recipe is a
>> >> solution for users who are switching from openssl 1.1.x back to 1.0.2
>> >> and have an image which is tries to include the new openssl-bin
>> >> package. I don't think that's what you are trying to do (?).
>> >
>> > Correct. I only tried it because the 1.0.2t recipe wasn't working.
>> >
>> > To be clear - I have /usr/bin/openssl in my image when using 1.0.2p from the Poky Sumo branch. When I add the 1.0.2t recipe to my own layer, openssl builds without errors, but I don't get the binary.
>> >
>> >> If you are using openssl 1.0.2 then the openssl command line tool is
>> >> in the openssl package... so to include the openssl command line tool,
>> >> add the "openssl" package to your image.
>> >>
>> >> If you are using openssl 1.1.x then the openssl command line tool is
>> >> in the openssl-bin package... so to include the openssl command line
>> >> tool, add the "openssl-bin" package to your image.
>> >>
>> >> But anyway, in all cases, the way to debug what's going on isn't to
>> >> try random recipe changes and then rebuild the final image. Instead
>> >> you should build your chosen version of openssl, look in the
>> >> packages-split directory to see which package includes the openssl
>> >> command line tool and then add that package to your image.
>> >
>> > I don't have a packages-split. I was unaware of it, and reading the manual, it seems I should have one. But I don't. Running 'bitbake -e openssl | grep "PKGDEST="' tells me I should have one, but there are no instances in a directory called "packages-split" in my tmp dir.
>>
>> most likely because you are using rm_work.
>
> Yes, I am! Thanks, Nico.

It looks like Mark's openssl 1.0.2 recipe has added the openssl-bin
package (ie Mark's openssl 1.0.2 recipe behaves the same as the
openssl 1.1.x recipe).

My openssl 1.0.2 recipe keeps the original packaging rules (as they
were when openssl 1.0.2 was the default in oe-core).

Re: How to backport openssl to Sumo

[Mikko.Rapeli]

On Wed, Nov 20, 2019 at 06:18:05PM +0000, Ryan Harkin wrote:
> I'm struggling with backporting OpenSSL to my Sumo build [1], so wondered
> if anyone else had done something similar with success.

I've done it by backporting following changes to poky (sorry for subject only):

openssh: upgrade 7.6p1 -> 7.7p1
openssh: drop sshd support for DSA host keys
openssh: stop adding -D__FILE_OFFSET_BITS=64 to CFLAGS
openssh: drop RCONFLICTS for openssh-keygen
openssh: minor indent cleanup for sshd init script
openssh: sync local ssh_config + sshd_config files with upstream 7.7p1
openssh: only create sshd host keys which have been enabled
openssh: update from 7.7p1 to 7.8p1
openssh: upgrade 7.8p1 -> 7.8p1+git to support openssl 1.1.x
openssl-1.1: rework packaging
openssl-1.1: /etc/ssl location compatibility
openssl: minor reformatting to align the 1.0 and 1.1 recipes
openssl: move the libdir openssl.cnf symlink into the openssl package
openssl: fix path in nativesdk environment-setup script
openssl: drop obsolete no-afalgeng workaround for aarch64
openssl: fix hardcoded paths in native for openssl 1.1
openssl: remove dependency on relative_symlinks class
openssl: rename openssl 1.0.x to openssl10 and make openssl 1.1.x the default version
openssl: update to 1.1.1
openssl: do not tweak so names, use PRIVATE_LIBS instead
openssl: Handle -conf package file conflicts
openssl: rename PV to 1.1.1~pre9 to avoid future versions from going backwards
openssl_1.1.1: Fix Musl build by disabling async during configure
openssl: update to 1.1.1 final
openssl10: fix compile error for debian-mips64
openssl: skip ptest case `test_symbol_presence'
openssl: use deterministic perl Text::Template module bundled by openssl source
openssl: correct license comment
openssl: fix ptest
openssl: do an out-of-tree build
openssl: fix CVE-2018-0734 for both 1.0.2p and 1.1.1
openssl: fix CVE-2018-0735 for 1.1.1
openssl-1.1.1: remove build path from version info
openssl: update to 1.1.1a
openssl: correct bad path on package preprocess
python3{,-native}: backport openssl 1.1.1 compatibility changes
python3: fix openssl 1.1.1 changes
cryptodev-tests: port to openssl 1.1

Plus a patch to allow overriding openssl version in default-versions.inc,
and one hack to drop perl RDEPENDS from openssl-bin. This is still missing
the latest CVEs and letter releases.

Then meta-openembedded needed at least:

asio: Upgrade to 1.12.1
mailx: support openssl 1.1.x
cyrus-sasl: add UPSTREAM_CHECK_REGEX
cyrus-sasl: CLEANBROKEN = "1"
cyrus-sasl: Update to 2.1.27-rc7
cyrus-sasl: do not set CLEANBROKEN
cyrus-sasl: fix build out of source tree failed while configuring with `--enable-ldapdb'
cyrus-sasl: fix parallel build issue

I could submit these too if someone wants to setup a communit maintenance branch for sumo.

Cheers,

-Mikko

Re: How to backport openssl to Sumo

[Adrian Bunk]

On Wed, Nov 20, 2019 at 09:39:51PM +0000, Mikko.Rapeli@bmw.de wrote:
>...
> I could submit these too if someone wants to setup a communit maintenance branch for sumo.

I would not consider this appropriate for a stable branch. With such 
invasive changes it would no longer be reasonably safe for users to 
follow the branch to receive security updates for other recipes.

In Ubuntu 18.04 security support for OpenSSL 1.0.2 is provided until at 
least April 2023. Similar schedules exist for other LTS distributions.
This provides sources for piggy-backing security support for a few years
after upstream support ends.

> Cheers,
> 
> -Mikko

cu
Adrian

Re: How to backport openssl to Sumo

[Mikko.Rapeli]

On Thu, Nov 21, 2019 at 01:05:55AM +0200, Adrian Bunk wrote:
> On Wed, Nov 20, 2019 at 09:39:51PM +0000, Mikko.Rapeli@bmw.de wrote:
> >...
> > I could submit these too if someone wants to setup a communit maintenance branch for sumo.
> 
> I would not consider this appropriate for a stable branch. With such 
> invasive changes it would no longer be reasonably safe for users to 
> follow the branch to receive security updates for other recipes.
> 
> In Ubuntu 18.04 security support for OpenSSL 1.0.2 is provided until at 
> least April 2023. Similar schedules exist for other LTS distributions.
> This provides sources for piggy-backing security support for a few years
> after upstream support ends.

Yes, I agree to this. The reasons for the large intrusive backport are:

 * openssl version 1.1.0 in sumo is no longer supported by upstream
   developers, see https://www.openssl.org/policies/releasestrat.html
   "Version 1.1.0 will be supported until 2019-09-11." but 1.1.1
   is an LTS with support unit 2023-09-11

 * many recipes like openssh in sumo do not support openssl 1.1.x and an
   update is needed to cover the API breakage. The backported pathes
   fixes most of the issues in poky and meta-openembedded and I've been
   able to use the set in multiple projects with different BSP stacks.

So in sumo, openssl 1.0.2 could still be maintainable with Ubuntu etc
help even when upstream openssl.org support has now ended. Same could
apply to openssl 1.1.0 there, but if one suffers and fixes the API
changes, then it is maybe better for users to jump directly to the next
openssl 1.1.1x LTS version. The patches I mentioned achieve this,
but I agree they are intrucive and not following stable policies.

In my case, openssl 1.1.x transition is one of the major blockers
for doing more yocto updates and running closer to master. The backport
has helped there and a following jump to zeus was really straight
forward (ignoring lots of issues in BSP layers but that's life).

Then a note on openssl 1.1.x impact to various BSP layers, some scripting and
bbclasses related to signing etc may need to be updated but also
those changes are simple. I wish there was more open source community
approach so share changes like these among users of various BSPs.

Cheers,

-Mikko