All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: Artem Panfilov <panfilov.artyom@gmail.com>
Cc: "Alex G." <mr.nuke.me@gmail.com>,
	"u-boot@lists.denx.de" <u-boot@lists.denx.de>
Subject: Re: [PATCH 1/1] lib/ecdsa: Fix LibreSSL before v2.7.0
Date: Wed, 28 Jul 2021 18:56:19 -0400	[thread overview]
Message-ID: <20210728225619.GB9379@bill-the-cat> (raw)
In-Reply-To: <34cdf0ed-c97d-e5ec-31ff-24e4ca085c4d@gmail.com>

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

On Thu, Jul 29, 2021 at 01:29:35AM +0300, Artem Panfilov wrote:
> 
> On 28.07.2021 23:07, Tom Rini wrote:
> > There is a fine line at least that I'm willing to walk in terms of
> > supporting ancient OSes directly and also not making things overly
> > complicated in our own tree.  That said, openssl tends to be one of the
> > ones where it does get hard to support old versions.  LibreSSL 2.7.5 was
> > released December 15th, 2018 and is the end of the 2.7.x line it seems.
> >
> > I'm interested to hear what the case is where the right call is the say
> > you're building modern software for real world use against such old
> > libraries.
> Hi Tom,
> I have a specific test case where I test if it's still possible to
> build upstream master u-boot on our infrastructure (progression testing).
> I also test runtime on our boards.
> 
> I understand that nowadays everyone uses docker container,
> but ​we have limited docker nodes right now on our site.
> 
> If you don't want to support OpenSSL < 1.1.0 and do not test it,
> then I suggest dropping it all over the tree because it doesn't
> make sense and looks misleading with such a partial solution.

Part of the question is then, were you enabling the SSL-related parts
before this change?  Or did the way the code is now being
enabled/disabled trigger this now being enabled when it wasn't before?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

  reply	other threads:[~2021-07-28 22:56 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-28 18:10 [PATCH 1/1] lib/ecdsa: Fix LibreSSL before v2.7.0 Artem Panfilov
2021-07-28 19:16 ` Alex G.
     [not found]   ` <CAFzqoFjxO8Ox5vCyU_oXc4=a=iKR7NHEY=rgNMppQ5760DL6Kw@mail.gmail.com>
2021-07-28 20:00     ` Alex G.
2021-07-28 20:07       ` Tom Rini
2021-07-28 22:29         ` Artem Panfilov
2021-07-28 22:56           ` Tom Rini [this message]
2021-07-28 23:37             ` Artem Panfilov
2021-07-28 23:43               ` Tom Rini
2021-07-29 10:40                 ` Artem Panfilov
2021-07-29 12:59                   ` Tom Rini
2021-07-29 14:52                     ` Artem Panfilov
2021-07-29 15:48                       ` Alex G.
  -- strict thread matches above, loose matches on Subject: below --
2021-07-28 18:04 Artem Panfilov
2021-07-29  5:13 ` Jonathan Gray
2021-07-31 16:59   ` Simon Glass

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=20210728225619.GB9379@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=mr.nuke.me@gmail.com \
    --cc=panfilov.artyom@gmail.com \
    --cc=u-boot@lists.denx.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.