Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Martin Jansa <martin.jansa@gmail.com>
To: Alexander Kanavin <alex.kanavin@gmail.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 00/26] thud patch review
Date: Tue, 19 Mar 2019 18:07:36 +0100	[thread overview]
Message-ID: <20190319170736.GI1994@jama> (raw)
In-Reply-To: <8ECD4C1B-CF62-4D11-9757-F3176AEA4B50@gmail.com>

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

On Tue, Mar 19, 2019 at 05:31:52PM +0100, Alexander Kanavin wrote:
> For what it’s worth, OpenSSL is also being relicensed to Apache 2.0, so backporting their fixes may not be an option either. 
> https://license.openssl.org/
> 
> Please be careful with your language: I’m sure you know that recipe maintenance is a tedious, thankless task. Having it belittled doesn’t help.

I'm sorry, I don't want to belittle the recipe maintenance task.

I'm just saying that using OE to build commercial products is another
level of complexity and if we as a project ignore the issues companies
might have while upgrading to newer OE releases, then we shouldn't be
surprised that there are too many products built with really ancient and
unsupported OE releases.

I'm not recommending to anyone to use openssl10 forever, I've replied to
this thread mostly to warn other people (who might be in the same hole
with openssl10) that this is another pain point and suggested possible
way how to work around it.

More commercial users closer to master might also help with lack of
resources, upstreaming something from danny based build to master is
much less likely to happen than from e.g. thud. Having a bit easier
upgrade paths or at least a bit sympathy for people having troubles
persuading management that spending a lot of time and money to rebuild
all native apps, just to get newer build system (which no customer will
ever notice in the end product) might help as well.

With app store filled by native apps from 3rd party companies and
required backward compatibility with older products, the stable ABI
might be more important for some people than latest, greatest versions
and we shouldn't ignore such use-cases for OE (or at least not assume
that nobody needs openssl10 just because oe-core recipes can already
build without it).

Cheers,

> > On 19 Mar 2019, at 14.55, Martin Jansa <martin.jansa@gmail.com> wrote:
> > 
> >> On Tue, Mar 19, 2019 at 12:35:59PM +0100, Alexander Kanavin wrote:
> >> Just to remind once more, all upstream support for OpenSSL 1.0.2 ceases in 9 months, so shipping products with it may not be the best idea.
> > 
> > Just to remind once more, shipping products isn't as easy as building
> > the few recipes included in oe-core.
> > 
> > For example:
> > Believe it or not, some projects need to use old Qt 5.6 due to license
> > change in newer version and 5.6 doesn't support openssl 1.1,
> > backporting the necessary changes would violate the license as well.
> > Providing clean room re-implementation is also difficult, because there
> > aren't many other options how to implement this than how it was done in
> > newer qt already, see:
> > 
> > https://bugreports.qt.io/browse/QTBUG-71623
> > https://development.qt-project.narkive.com/RW4wxYXY/openssl-1-1-x-support-on-qt-5-6-5-9
> > 
> > Yes, it's not the best idea, but even backporting security fixes to old
> > openssl might be cheaper than buying commercial qt license...
> > 
> > Cheeers,

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

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

  reply	other threads:[~2019-03-19 17:07 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-19  2:36 [PATCH 00/26] thud patch review Armin Kuster
2019-03-19  8:55 ` Martin Jansa
2019-03-19 10:22   ` Alexander Kanavin
2019-03-19 10:40     ` Martin Jansa
2019-03-19 11:35       ` Alexander Kanavin
2019-03-19 13:55         ` Martin Jansa
2019-03-19 16:31           ` Alexander Kanavin
2019-03-19 17:07             ` Martin Jansa [this message]
2019-03-19 14:52   ` akuster808
2019-03-19 15:40     ` Alexander Kanavin
2019-03-19  9:05 ` Vincent Prince

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190319170736.GI1994@jama \
    --to=martin.jansa@gmail.com \
    --cc=alex.kanavin@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox