openssl10 unusable for many components

openssl10 unusable for many components

[Martin Jansa]

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

Does openssl10 work for anyone in real-world scenarios?

I was trying to fix at least some of the failures reported in last bitbake
world status:
http://lists.openembedded.org/pipermail/openembedded-core/2017-August/140829.html

But in most recipes if you update DEPENDS to use openssl10, it will get
openssl (1.1) somewhere in dependency tree as well, e.g. like qtbase
through python3:

OE qemux86@ ~/build/oe-core $ grep " -> \"openssl.*do_populate_sysroot"
task-depends.dot
"qtbase.do_prepare_recipe_sysroot" -> "openssl10.do_populate_sysroot"
"openssl10.do_prepare_recipe_sysroot" ->
"openssl-native.do_populate_sysroot"
"python3-native.do_prepare_recipe_sysroot" ->
"openssl-native.do_populate_sysroot"
"python3.do_prepare_recipe_sysroot" -> "openssl.do_populate_sysroot"

and then do_prepare_recipe_sysroot fails, because both dependencies provid
libssl.a:

ERROR: qtbase-5.9.0+gitAUTOINC+f6b36eaafe-r0 do_prepare_recipe_sysroot:
Error executing a python function in exec_python_func() autogenerated:

The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: <module>
     0001:
 *** 0002:extend_recipe_sysroot(d)
     0003:
File: '/OE/build/oe-core/openembedded-core/meta/classes/staging.bbclass',
lineno: 510, function: extend_recipe_sysroot
     0506:                    dest = newmanifest[l]
     0507:                    if l.endswith("/"):
     0508:                        staging_copydir(l, targetdir, dest,
seendirs)
     0509:                        continue
 *** 0510:                    staging_copyfile(l, targetdir, dest,
postinsts, seendirs)
     0511:
     0512:    for f in fixme:
     0513:        if f == '':
     0514:            staging_processfixme(fixme[f], recipesysroot,
recipesysroot, recipesysrootnative, d)
File: '/OE/build/oe-core/openembedded-core/meta/classes/staging.bbclass',
lineno: 151, function: staging_copyfile
     0147:        os.symlink(linkto, dest)
     0148:        #bb.warn(c)
     0149:    else:
     0150:        try:
 *** 0151:            os.link(c, dest)
     0152:        except OSError as err:
     0153:            if err.errno == errno.EXDEV:
     0154:                bb.utils.copyfile(c, dest)
     0155:            else:
Exception: FileExistsError: [Errno 17] File exists:
'/OE/build/oe-core/tmp-glibc/sysroots-components/i586/openssl/usr/lib/libssl.a'
->
'/OE/build/oe-core/tmp-glibc/work/i586-oe-linux/qtbase/5.9.0+gitAUTOINC+f6b36eaafe-r0/recipe-sysroot/usr/lib/libssl.a'

ERROR: qtbase-5.9.0+gitAUTOINC+f6b36eaafe-r0 do_prepare_recipe_sysroot:
Function failed: extend_recipe_sysroot
ERROR: Logfile of failure stored in:
/OE/build/oe-core/tmp-glibc/work/i586-oe-linux/qtbase/5.9.0+gitAUTOINC+f6b36eaafe-r0/temp/log.do_prepare_recipe_sysroot.6496
ERROR: Task (/OE/build/oe-core/meta-qt5/recipes-qt/qt5/qtbase_git.bb:do_prepare_recipe_sysroot)
failed with exit code '1'

And not just libssl.a, they both provide also identically named pkg-config
files:
openssl.pc, libcrypto.pc, libssl.pc
OE qemux86@ ~/build/oe-core $ find
/OE/build/oe-core/tmp-glibc/sysroots-components/i586/openssl10/ | grep pc
/OE/build/oe-core/tmp-glibc/sysroots-components/i586/openssl10/usr/lib/pkgconfig/openssl.pc
/OE/build/oe-core/tmp-glibc/sysroots-components/i586/openssl10/usr/lib/pkgconfig/libcrypto.pc
/OE/build/oe-core/tmp-glibc/sysroots-components/i586/openssl10/usr/lib/pkgconfig/libssl.pc
OE qemux86@ ~/build/oe-core $ find
/OE/build/oe-core/tmp-glibc/sysroots-components/i586/openssl | grep pc
/OE/build/oe-core/tmp-glibc/sysroots-components/i586/openssl/usr/lib/pkgconfig/openssl.pc
/OE/build/oe-core/tmp-glibc/sysroots-components/i586/openssl/usr/lib/pkgconfig/libcrypto.pc
/OE/build/oe-core/tmp-glibc/sysroots-components/i586/openssl/usr/lib/pkgconfig/libssl.pc

So you cannot just select which openssl implementation you want for given
component, unless it's very simple component with small dependency tree.

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

Re: openssl10 unusable for many components

[Alexander Kanavin]

On 08/17/2017 01:31 PM, Martin Jansa wrote:
> So you cannot just select which openssl implementation you want for 
> given component, unless it's very simple component with small dependency 
> tree.

Unfortunately yes. The header names clash, and there's no way to have 
them both in the sysroot at the same time.

The only solution I see is the hard one: first update the component to 
latest upstream version, and see if that version compiles with 1.1.
If not, then Fedora probably has a vendor patch for the API fixing, as 
they've already moved to 1.1 as default.

FWIW, qt5 has merged openssl 1.1 support 
https://codereview.qt-project.org/#/c/189399/, but I don't know if 
there's a release with it included.

Alex

Re: openssl10 unusable for many components

[Richard Purdie]

On Thu, 2017-08-17 at 12:31 +0200, Martin Jansa wrote:
> Does openssl10 work for anyone in real-world scenarios?

Depends what "real-world" means really.

I've strongly pushed for OE-Core to have at least some spectrum of
coverage of various elements of the software stacks people use so we
can use it as an indicator of changes readiness to be merged. This goes
against those who want it stripped to the bare bones.

There was a strong desire to keep qt5 out of OE-Core and I've gone
along with that, this is one of the downsides, it doesn't get testing
when changes like this get integrated. We did test openssl 1.1 as far
as we reasonably could before it merged and it was posted on the list
for quite a while and discussed.

There is a problem here and I don't know how we solve it to be honest
(other than the obvious upgrading of problematic recipes).

I can imagine some fancy sstate code in the openssl recipes where they
could prune their populate_sysroot data depending on the dependency
chains being installed. Equally, that code would be hard to right and
would only stop another subset of issues, not solve the problem. For
example, if python3 references the openssl headers, there could be
ABI/API issues if QT uses python3 openssl functions, depending on how
the headers are structured.

So I'm not sure how we move forward here, one plus point is that there
are 1.1 patches for qt5 which is something at least.

People could suggest more testing. The reason patches merge slowly in
OE-Core is the infrastructure struggles with the current range of
testing. I've actually "destroyed" one of the autobuilder clusters this
week and we're running on degraded infrastructure right now until we
fix the overloading problem I caused there :(. 

Cheers,

Richard

Re: openssl10 unusable for many components

[Martin Jansa]

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

The qtbase was just an example, the link with the last report:
http://lists.openembedded.org/pipermail/openembedded-core/2017-August/140829.html

shows that instead of 5 failures reported in previous one:
http://lists.openembedded.org/pipermail/openembedded-devel/2017-August/114108.html

we have around 40 failures (numbers differs for different MACHINEs) and
that's probably far from complete list of failing recipes, because many
recipes weren't built at all, because one of their dependencies failed
already.

I meant "real-world" as builds for any products on the market (which are
likely using one of the failing recipes) - e.g. in LGE we have many more
failures over all internal components, so I'll just undo this openssl
switch (renaming openssl_1.1 as openssl11 and openssl11_1.0 back as
openssl_1.0 with PROVIDES openssl11). We won't be able to use openssl-1.1
for long time anyway, because there are some 3rd party component which are
difficult (or expensive) to get rebuilt against new openssl ABI, but we
might be interested in some other improvements in oe-core/master.

I'm not saying that oe-core should be blocked until the oldest and slowly
moving project is updated to be compatible with it, just keep in mind that
"real-world" products are far more complicated than keeping oe-core
autobuilder green and that some companies might see it as blocker for
upgrading to newer oe-core.

Regards,

On Thu, Aug 17, 2017 at 1:33 PM, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> On Thu, 2017-08-17 at 12:31 +0200, Martin Jansa wrote:
> > Does openssl10 work for anyone in real-world scenarios?
>
> Depends what "real-world" means really.
>
> I've strongly pushed for OE-Core to have at least some spectrum of
> coverage of various elements of the software stacks people use so we
> can use it as an indicator of changes readiness to be merged. This goes
> against those who want it stripped to the bare bones.
>
> There was a strong desire to keep qt5 out of OE-Core and I've gone
> along with that, this is one of the downsides, it doesn't get testing
> when changes like this get integrated. We did test openssl 1.1 as far
> as we reasonably could before it merged and it was posted on the list
> for quite a while and discussed.
>
> There is a problem here and I don't know how we solve it to be honest
> (other than the obvious upgrading of problematic recipes).
>
> I can imagine some fancy sstate code in the openssl recipes where they
> could prune their populate_sysroot data depending on the dependency
> chains being installed. Equally, that code would be hard to right and
> would only stop another subset of issues, not solve the problem. For
> example, if python3 references the openssl headers, there could be
> ABI/API issues if QT uses python3 openssl functions, depending on how
> the headers are structured.
>
> So I'm not sure how we move forward here, one plus point is that there
> are 1.1 patches for qt5 which is something at least.
>
> People could suggest more testing. The reason patches merge slowly in
> OE-Core is the infrastructure struggles with the current range of
> testing. I've actually "destroyed" one of the autobuilder clusters this
> week and we're running on degraded infrastructure right now until we
> fix the overloading problem I caused there :(.
>
> Cheers,
>
> Richard
>
>
>

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

Re: openssl10 unusable for many components

[Alexander Kanavin]

On 08/17/2017 02:46 PM, Martin Jansa wrote:
> I meant "real-world" as builds for any products on the market (which are 
> likely using one of the failing recipes) - e.g. in LGE we have many more 
> failures over all internal components, so I'll just undo this openssl 
> switch (renaming openssl_1.1 as openssl11 and openssl11_1.0 back as 
> openssl_1.0 with PROVIDES openssl11). We won't be able to use 
> openssl-1.1 for long time anyway, because there are some 3rd party 
> component which are difficult (or expensive) to get rebuilt against new 
> openssl ABI, but we might be interested in some other improvements in 
> oe-core/master.

Yes, this will work for you as a quick fix, but it is merely postponing 
dealing with the issue properly to a later date. Make a plan for it and 
keep in mind that openssl 1.0 goes out of upstream support at the end of 
2019. Given its history of major security vulnerabilities, it will be 
removed from oe-core well before that time, so that it won't linger in 
supported YP releases.


Alex

Re: openssl10 unusable for many components

[Khem Raj]

On Thu, Aug 17, 2017 at 4:54 AM, Alexander Kanavin
<alexander.kanavin@linux.intel.com> wrote:
> On 08/17/2017 02:46 PM, Martin Jansa wrote:
>>
>> I meant "real-world" as builds for any products on the market (which are
>> likely using one of the failing recipes) - e.g. in LGE we have many more
>> failures over all internal components, so I'll just undo this openssl switch
>> (renaming openssl_1.1 as openssl11 and openssl11_1.0 back as openssl_1.0
>> with PROVIDES openssl11). We won't be able to use openssl-1.1 for long time
>> anyway, because there are some 3rd party component which are difficult (or
>> expensive) to get rebuilt against new openssl ABI, but we might be
>> interested in some other improvements in oe-core/master.
>
>
> Yes, this will work for you as a quick fix, but it is merely postponing
> dealing with the issue properly to a later date. Make a plan for it and keep
> in mind that openssl 1.0 goes out of upstream support at the end of 2019.
> Given its history of major security vulnerabilities, it will be removed from
> oe-core well before that time, so that it won't linger in supported YP
> releases.
>

I was trying nodejs and it seems its also broken by this openssl
upgrade. Meta-oe alone has amost 50 recipes that are broken. there are
hundreds of other layers.
Many large packages in external layers are now broken, and the fact
that openssl10
is almost useless since some package will pull in openssl11 and cause
conflicts. This
is not a a good solution at least it seems to early for release. It
might take a bit for packages to get working with openssl11, We should
have carefully thought and considered postponing using it as default
until next release ( april 2018). Its fine to keep it in if needed but
keep openssl 1.0 as default preferred version, I don't think whole
ecosystem is ready for it and we don't have man power to fix
everything. This alone has a potential to make
October release quite weak as far as external layers are concerned

If we want to keep openssl 1.1 in Oe-Core as default its fine, then
lets provide a way to downgrade it instead of openssl10 recipe which
is sub-optimal since OE does build from
source and not binary packages where such a solution might work.

Re: openssl10 unusable for many components

[Alexander Kanavin]

On 08/18/2017 08:56 AM, Khem Raj wrote:

> I was trying nodejs and it seems its also broken by this openssl
> upgrade. Meta-oe alone has amost 50 recipes that are broken. there are
> hundreds of other layers.
> Many large packages in external layers are now broken, and the fact
> that openssl10
> is almost useless since some package will pull in openssl11 and cause
> conflicts. This
> is not a a good solution at least it seems to early for release. It
> might take a bit for packages to get working with openssl11, We should
> have carefully thought and considered postponing using it as default
> until next release ( april 2018). Its fine to keep it in if needed but
> keep openssl 1.0 as default preferred version, I don't think whole
> ecosystem is ready for it and we don't have man power to fix
> everything. This alone has a potential to make
> October release quite weak as far as external layers are concerned

FWIW, nodejs from meta-oe does build just fine with openssl10 
dependency. So it's not exactly useless. And no one has established how 
many of the other 50 packages can be fixed by either doing that, or 
updating them to latest upstream releases.

I'll send a patch that renames openssl10 recipe back to openssl and sets 
that as a preferred version, so anyone can experiment with 1.1 without 
widespread breakage.

But at the start of next development cycle this will be reverted back; 
no more complaining then please, we have to do this at some point, and 
just after a new cycle has started is as good time as it gets.


Alex

Re: openssl10 unusable for many components

[Khem Raj]

On Fri, Aug 18, 2017 at 3:53 AM, Alexander Kanavin
<alexander.kanavin@linux.intel.com> wrote:
> On 08/18/2017 08:56 AM, Khem Raj wrote:
>
>> I was trying nodejs and it seems its also broken by this openssl
>> upgrade. Meta-oe alone has amost 50 recipes that are broken. there are
>> hundreds of other layers.
>> Many large packages in external layers are now broken, and the fact
>> that openssl10
>> is almost useless since some package will pull in openssl11 and cause
>> conflicts. This
>> is not a a good solution at least it seems to early for release. It
>> might take a bit for packages to get working with openssl11, We should
>> have carefully thought and considered postponing using it as default
>> until next release ( april 2018). Its fine to keep it in if needed but
>> keep openssl 1.0 as default preferred version, I don't think whole
>> ecosystem is ready for it and we don't have man power to fix
>> everything. This alone has a potential to make
>> October release quite weak as far as external layers are concerned
>
>
> FWIW, nodejs from meta-oe does build just fine with openssl10 dependency.

no it doesnt try building nodejs-native.

 So
> it's not exactly useless. And no one has established how many of the other
> 50 packages can be fixed by either doing that, or updating them to latest
> upstream releases.

Thats not going to solve everything. Neither does pointing to fedora patches.

>
> I'll send a patch that renames openssl10 recipe back to openssl and sets
> that as a preferred version, so anyone can experiment with 1.1 without
> widespread breakage.
>
> But at the start of next development cycle this will be reverted back; no
> more complaining then please, we have to do this at some point, and just
> after a new cycle has started is as good time as it gets.

Just putting random deadlines is not going to solve this, there has to
be some look
at upstream packages and other distros switching to openssl11 and
dropping openssl10
completely. People have fielded products to support and they need some
assurance of
forward path, their ecosystem might involve a lot larger package set
then just oe-core.

Re: openssl10 unusable for many components

[Martin Jansa]

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

Even with that patch to rename openssl10 back to openssl we still need to
solve the openssl-native which wasn't reverted back to 1.0.

Upstream nodejs isn't going to be openssl-1.1 for a bit longer as explained:
https://github.com/nodejs/node/pull/14761
https://github.com/nodejs/node/pull/11828
so it would make sense to revert native and nativesdk versions as well - if
it isn't done in oe-core, I'll do it in our own layers to keep the builds
going.

On Fri, Aug 18, 2017 at 4:41 PM, Khem Raj <raj.khem@gmail.com> wrote:

> On Fri, Aug 18, 2017 at 3:53 AM, Alexander Kanavin
> <alexander.kanavin@linux.intel.com> wrote:
> > On 08/18/2017 08:56 AM, Khem Raj wrote:
> >
> >> I was trying nodejs and it seems its also broken by this openssl
> >> upgrade. Meta-oe alone has amost 50 recipes that are broken. there are
> >> hundreds of other layers.
> >> Many large packages in external layers are now broken, and the fact
> >> that openssl10
> >> is almost useless since some package will pull in openssl11 and cause
> >> conflicts. This
> >> is not a a good solution at least it seems to early for release. It
> >> might take a bit for packages to get working with openssl11, We should
> >> have carefully thought and considered postponing using it as default
> >> until next release ( april 2018). Its fine to keep it in if needed but
> >> keep openssl 1.0 as default preferred version, I don't think whole
> >> ecosystem is ready for it and we don't have man power to fix
> >> everything. This alone has a potential to make
> >> October release quite weak as far as external layers are concerned
> >
> >
> > FWIW, nodejs from meta-oe does build just fine with openssl10 dependency.
>
> no it doesnt try building nodejs-native.
>
>  So
> > it's not exactly useless. And no one has established how many of the
> other
> > 50 packages can be fixed by either doing that, or updating them to latest
> > upstream releases.
>
> Thats not going to solve everything. Neither does pointing to fedora
> patches.
>
> >
> > I'll send a patch that renames openssl10 recipe back to openssl and sets
> > that as a preferred version, so anyone can experiment with 1.1 without
> > widespread breakage.
> >
> > But at the start of next development cycle this will be reverted back; no
> > more complaining then please, we have to do this at some point, and just
> > after a new cycle has started is as good time as it gets.
>
> Just putting random deadlines is not going to solve this, there has to
> be some look
> at upstream packages and other distros switching to openssl11 and
> dropping openssl10
> completely. People have fielded products to support and they need some
> assurance of
> forward path, their ecosystem might involve a lot larger package set
> then just oe-core.
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

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

Re: openssl10 unusable for many components

[Martin Jansa]

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

On Thu, Aug 17, 2017 at 02:54:37PM +0300, Alexander Kanavin wrote:
> On 08/17/2017 02:46 PM, Martin Jansa wrote:
> > I meant "real-world" as builds for any products on the market (which are 
> > likely using one of the failing recipes) - e.g. in LGE we have many more 
> > failures over all internal components, so I'll just undo this openssl 
> > switch (renaming openssl_1.1 as openssl11 and openssl11_1.0 back as 
> > openssl_1.0 with PROVIDES openssl11). We won't be able to use 
> > openssl-1.1 for long time anyway, because there are some 3rd party 
> > component which are difficult (or expensive) to get rebuilt against new 
> > openssl ABI, but we might be interested in some other improvements in 
> > oe-core/master.
> 
> Yes, this will work for you as a quick fix, but it is merely postponing 
> dealing with the issue properly to a later date. Make a plan for it and 
> keep in mind that openssl 1.0 goes out of upstream support at the end of 
> 2019. Given its history of major security vulnerabilities, it will be 
> removed from oe-core well before that time, so that it won't linger in 
> supported YP releases.

openssl 1.1 goes out of upstream support on 2018-08-31 _more than a year
before_ 1.0.2 support, see:

https://www.openssl.org/policies/releasestrat.html
Version 1.1.0 will be supported until 2018-08-31.
Version 1.0.2 will be supported until 2019-12-31 (LTS).

Given its history of major security vulnerabilities, I hope you'll
remove openssl-1.1.0 even sooner than openssl-1.0.2.

Regards,
-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 201 bytes --]

Re: openssl10 unusable for many components

[Mark Hatle]

On 8/18/17 12:29 PM, Martin Jansa wrote:
> Even with that patch to rename openssl10 back to openssl we still need to solve
> the openssl-native which wasn't reverted back to 1.0.
> 
> Upstream nodejs isn't going to be openssl-1.1 for a bit longer as explained:
> https://github.com/nodejs/node/pull/14761

I wanted to pull out a specific comment from the above link that shows one of
the reasons why OpenSSL 1.1 support is delayed by many:

7 days ago: shigeki commented:
> We're also waiting for FIPS support of 1.1.x. They are now working on it as https://www.openssl.org/blog/blog/2017/07/25/fips/.> ...

Until the OpenSSL 1.1.x FIPS work is further along, a lot of projects (and major
distributions) are going to wait to deploy it.

--Mark

> https://github.com/nodejs/node/pull/11828
> so it would make sense to revert native and nativesdk versions as well - if it
> isn't done in oe-core, I'll do it in our own layers to keep the builds going.
> 
> On Fri, Aug 18, 2017 at 4:41 PM, Khem Raj <raj.khem@gmail.com
> <mailto:raj.khem@gmail.com>> wrote:
> 
>     On Fri, Aug 18, 2017 at 3:53 AM, Alexander Kanavin
>     <alexander.kanavin@linux.intel.com
>     <mailto:alexander.kanavin@linux.intel.com>> wrote:
>     > On 08/18/2017 08:56 AM, Khem Raj wrote:
>     >
>     >> I was trying nodejs and it seems its also broken by this openssl
>     >> upgrade. Meta-oe alone has amost 50 recipes that are broken. there are
>     >> hundreds of other layers.
>     >> Many large packages in external layers are now broken, and the fact
>     >> that openssl10
>     >> is almost useless since some package will pull in openssl11 and cause
>     >> conflicts. This
>     >> is not a a good solution at least it seems to early for release. It
>     >> might take a bit for packages to get working with openssl11, We should
>     >> have carefully thought and considered postponing using it as default
>     >> until next release ( april 2018). Its fine to keep it in if needed but
>     >> keep openssl 1.0 as default preferred version, I don't think whole
>     >> ecosystem is ready for it and we don't have man power to fix
>     >> everything. This alone has a potential to make
>     >> October release quite weak as far as external layers are concerned
>     >
>     >
>     > FWIW, nodejs from meta-oe does build just fine with openssl10 dependency.
> 
>     no it doesnt try building nodejs-native.
> 
>      So
>     > it's not exactly useless. And no one has established how many of the other
>     > 50 packages can be fixed by either doing that, or updating them to latest
>     > upstream releases.
> 
>     Thats not going to solve everything. Neither does pointing to fedora patches.
> 
>     >
>     > I'll send a patch that renames openssl10 recipe back to openssl and sets
>     > that as a preferred version, so anyone can experiment with 1.1 without
>     > widespread breakage.
>     >
>     > But at the start of next development cycle this will be reverted back; no
>     > more complaining then please, we have to do this at some point, and just
>     > after a new cycle has started is as good time as it gets.
> 
>     Just putting random deadlines is not going to solve this, there has to
>     be some look
>     at upstream packages and other distros switching to openssl11 and
>     dropping openssl10
>     completely. People have fielded products to support and they need some
>     assurance of
>     forward path, their ecosystem might involve a lot larger package set
>     then just oe-core.
>     --
>     _______________________________________________
>     Openembedded-core mailing list
>     Openembedded-core@lists.openembedded.org
>     <mailto:Openembedded-core@lists.openembedded.org>
>     http://lists.openembedded.org/mailman/listinfo/openembedded-core
>     <http://lists.openembedded.org/mailman/listinfo/openembedded-core>
> 
> 
> 
> 

Re: openssl10 unusable for many components

[Alexander Kanavin]

On 08/18/2017 05:41 PM, Khem Raj wrote:
>> FWIW, nodejs from meta-oe does build just fine with openssl10 dependency.
> 
> no it doesnt try building nodejs-native.
> 

Just tried. nodejs-native compiled and installed perfectly against 
openssl10-native.


Alex

Re: openssl10 unusable for many components

[Alexander Kanavin]

On 08/18/2017 08:29 PM, Martin Jansa wrote:
> Even with that patch to rename openssl10 back to openssl we still need 
> to solve the openssl-native which wasn't reverted back to 1.0.

That was a simple oversight, I forgot to set PREFERRED_VERSION for 
native and nativesdk variants.

> Upstream nodejs isn't going to be openssl-1.1 for a bit longer as explained:
> https://github.com/nodejs/node/pull/14761
> https://github.com/nodejs/node/pull/11828
> so it would make sense to revert native and nativesdk versions as well - 
> if it isn't done in oe-core, I'll do it in our own layers to keep the 
> builds going.

I don't understand why nodejs fails for you with openssl10 dependency. 
Works totally fine for me here.

qtbase however does fail, but this will be solved in 5.10.

Alex

Re: openssl10 unusable for many components

[Alexander Kanavin]

On 08/18/2017 08:41 PM, Martin Jansa wrote:
> openssl 1.1 goes out of upstream support on 2018-08-31 _more than a year
> before_ 1.0.2 support, see:
> 
> https://www.openssl.org/policies/releasestrat.html
> Version 1.1.0 will be supported until 2018-08-31.
> Version 1.0.2 will be supported until 2019-12-31 (LTS).
> 
> Given its history of major security vulnerabilities, I hope you'll
> remove openssl-1.1.0 even sooner than openssl-1.0.2.

openssl 1.1.1 should be released as soon as final TLS 1.3 spec is 
published. I expect it will go out of support much later than 1.1.0. I 
do not expect a situation where 1.0 is supported but 1.1.something is not.


Alex

Re: openssl10 unusable for many components

[Alexander Kanavin]

On 08/18/2017 08:56 PM, Mark Hatle wrote:
>> Even with that patch to rename openssl10 back to openssl we still need to solve
>> the openssl-native which wasn't reverted back to 1.0.
>>
>> Upstream nodejs isn't going to be openssl-1.1 for a bit longer as explained:
>> https://github.com/nodejs/node/pull/14761
> 
> I wanted to pull out a specific comment from the above link that shows one of
> the reasons why OpenSSL 1.1 support is delayed by many:
> 
> 7 days ago: shigeki commented:
>> We're also waiting for FIPS support of 1.1.x. They are now working on it as https://www.openssl.org/blog/blog/2017/07/25/fips/.> ...
> 
> Until the OpenSSL 1.1.x FIPS work is further along, a lot of projects (and major
> distributions) are going to wait to deploy it.

What I don't understand is why node even cares about FIPS? FIPS 
compliance is needed to win software supplier contracts with one certain 
government; I haven't seen any other reasons.

Another point is that getting FIPS done will take a very long time, 
possibly two years or more, and this work is just starting now with no 
clear funding or completion date (see the openssl blog link). Meanwhile, 
all major desktop linux distros have 1.1 by default already; seems to me 
that they don't care.

Alex

Re: openssl10 unusable for many components

[Martin Jansa]

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

I don't know why they care about it, but yes it will take long time:
https://www.openssl.org/blog/blog/2017/08/17/fips/

On Fri, Aug 18, 2017 at 8:41 PM, Alexander Kanavin <
alexander.kanavin@linux.intel.com> wrote:

> On 08/18/2017 08:56 PM, Mark Hatle wrote:
>
>> Even with that patch to rename openssl10 back to openssl we still need to
>>> solve
>>> the openssl-native which wasn't reverted back to 1.0.
>>>
>>> Upstream nodejs isn't going to be openssl-1.1 for a bit longer as
>>> explained:
>>> https://github.com/nodejs/node/pull/14761
>>>
>>
>> I wanted to pull out a specific comment from the above link that shows
>> one of
>> the reasons why OpenSSL 1.1 support is delayed by many:
>>
>> 7 days ago: shigeki commented:
>>
>>> We're also waiting for FIPS support of 1.1.x. They are now working on it
>>> as https://www.openssl.org/blog/blog/2017/07/25/fips/.> ...
>>>
>>
>> Until the OpenSSL 1.1.x FIPS work is further along, a lot of projects
>> (and major
>> distributions) are going to wait to deploy it.
>>
>
> What I don't understand is why node even cares about FIPS? FIPS compliance
> is needed to win software supplier contracts with one certain government; I
> haven't seen any other reasons.
>
> Another point is that getting FIPS done will take a very long time,
> possibly two years or more, and this work is just starting now with no
> clear funding or completion date (see the openssl blog link). Meanwhile,
> all major desktop linux distros have 1.1 by default already; seems to me
> that they don't care.
>
> Alex
>

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

Re: openssl10 unusable for many components

[Mark Hatle]

On 8/18/17 1:41 PM, Alexander Kanavin wrote:
> On 08/18/2017 08:56 PM, Mark Hatle wrote:
>>> Even with that patch to rename openssl10 back to openssl we still need to solve
>>> the openssl-native which wasn't reverted back to 1.0.
>>>
>>> Upstream nodejs isn't going to be openssl-1.1 for a bit longer as explained:
>>> https://github.com/nodejs/node/pull/14761
>>
>> I wanted to pull out a specific comment from the above link that shows one of
>> the reasons why OpenSSL 1.1 support is delayed by many:
>>
>> 7 days ago: shigeki commented:
>>> We're also waiting for FIPS support of 1.1.x. They are now working on it as https://www.openssl.org/blog/blog/2017/07/25/fips/.> ...
>>
>> Until the OpenSSL 1.1.x FIPS work is further along, a lot of projects (and major
>> distributions) are going to wait to deploy it.
> 
> What I don't understand is why node even cares about FIPS? FIPS 
> compliance is needed to win software supplier contracts with one certain 
> government; I haven't seen any other reasons.

Many governments and private company require this certification.  FIPS-140-2 is
the US NIST name for this work, but the same work resolves ISO requirements in
Europe and other countries.

Medical devices often requires FIPS certification in order to conform the
privacy requirements (or to be sold into US Government funded hospitals.)  FIPS
is really a big deal for many industries.

> Another point is that getting FIPS done will take a very long time, 
> possibly two years or more, and this work is just starting now with no 
> clear funding or completion date (see the openssl blog link). Meanwhile, 
> all major desktop linux distros have 1.1 by default already; seems to me 
> that they don't care.

Yes it will.  It will likely take 6 months to a year of development and likely
another 6 months to a year of certification lab work.

This is part of the reason the 1.0.2 EOL was set to end of 2019, to help force
the move to 1.1.  However, if you look at the 1.0.2 FIPS module, it has January
2022 EOL.  (Note, that EOL has a slightly different meaning then the 2019 1.0.2
one.... but the reality is that there will be organizations that will continue
to publish security fixes for OpenSSL 1.0.2 through the FIPS module EOL...
simply our of necessity.)

One of the key thing with this is that work can accelerate (likely not less then
a year) if additional people step up and assist in the funding.  I'm aware of a
few commercial companies that are discussing doing this, but unfortunately
nothing more concrete then the blog referenced above.)

> Alex
> 

Re: openssl10 unusable for many components

[Richard Purdie]

On Fri, 2017-08-18 at 19:29 +0200, Martin Jansa wrote:
> Even with that patch to rename openssl10 back to openssl we still
> need to solve the openssl-native which wasn't reverted back to 1.0.
> 
> Upstream nodejs isn't going to be openssl-1.1 for a bit longer as
> explained:
> https://github.com/nodejs/node/pull/14761
> https://github.com/nodejs/node/pull/11828
> so it would make sense to revert native and nativesdk versions as
> well - if it isn't done in oe-core, I'll do it in our own layers to
> keep the builds going.

Hopefully we have a working 'revert' back to 1.0 in master now as there
was simply too much breakage for this release.

I would ask that people do try and figure out how to solve some of the
1.1 issues in the meantime, hopefully people can enable 1.1 with some
PREFERRED_VERSION tweaks.

Cheers,

Richard

Re: openssl10 unusable for many components

[Martin Jansa]

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

Yes, the 'revert' works for me, thanks.

On Mon, Aug 21, 2017 at 11:29 AM, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> On Fri, 2017-08-18 at 19:29 +0200, Martin Jansa wrote:
> > Even with that patch to rename openssl10 back to openssl we still
> > need to solve the openssl-native which wasn't reverted back to 1.0.
> >
> > Upstream nodejs isn't going to be openssl-1.1 for a bit longer as
> > explained:
> > https://github.com/nodejs/node/pull/14761
> > https://github.com/nodejs/node/pull/11828
> > so it would make sense to revert native and nativesdk versions as
> > well - if it isn't done in oe-core, I'll do it in our own layers to
> > keep the builds going.
>
> Hopefully we have a working 'revert' back to 1.0 in master now as there
> was simply too much breakage for this release.
>
> I would ask that people do try and figure out how to solve some of the
> 1.1 issues in the meantime, hopefully people can enable 1.1 with some
> PREFERRED_VERSION tweaks.
>
> Cheers,
>
> Richard
>

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