Mailing List Archive: openssl 3.0 when

openssl 3.0 when

Oct 31, 2021, 5:35 AM

Post #1 of 6 (556 views)

I would like us to come to an understanding what our roadmap in
regard to OpenSSL 3.0 is. People keep on asking about it.

Yesterday, I spent some hours hacking at mod_ssl and mod_md to
get it running. I managed to compile it, but it was not working
reliably. Maybe I took some wrong turns somewhere. My observations
below.

With my RM hat on, I see the next release in early December. We
have some fixes to ship and maybe the new http2 implementation.

Personally, I do not see a need for OpenSSL 3.0 in that one. But
if anyone has plans to do it, it would be good to know.

Kind Regards,
Stefan

---------------
Observations hacking on OpenSSL 3.0 compatibility:

- SRP seems to be gone.
- the ENGINE API seems to be gone
- RSA*, DH* and friends are no longer wanted.
Instead, the PKEY API offers replacements.
- This affects reading key parameter from files, afaict.
- Some minor annoyances with BIO_set_callback and
ERR_peek_last..
- I changed EC key generation in mod_md to the new API,
but generation failed at runtime. Maybe a minor glitch
on my part.
- The code overall does not become prettier.

Re: openssl 3.0 when [ In reply to ]

jorton at redhat

Nov 1, 2021, 7:24 AM

Post #2 of 6 (556 views)

Permalink

On Sun, Oct 31, 2021 at 01:35:09PM +0100, stefan@eissing.org wrote:
> I would like us to come to an understanding what our roadmap in
> regard to OpenSSL 3.0 is. People keep on asking about it.
>
> Yesterday, I spent some hours hacking at mod_ssl and mod_md to
> get it running. I managed to compile it, but it was not working
> reliably. Maybe I took some wrong turns somewhere. My observations
> below.

What are you talking about exactly here? trunk should compile and run
fine already with 3.0 except if you build OpenSSL without deprecated
functions which AFAIK nobody sane will do, or at least, no sane
distributor will do, because the world is not ready.

> With my RM hat on, I see the next release in early December. We
> have some fixes to ship and maybe the new http2 implementation.
>
> Personally, I do not see a need for OpenSSL 3.0 in that one. But
> if anyone has plans to do it, it would be good to know.

I would still like to get a Travis job testing against 3.0, on my TODO,
but I don't know of any compatilibity problems not covered in trunk /
https://github.com/apache/httpd/pull/258 (outside use of deprecated
functions anyway).

Regards, Joe

>
> Kind Regards,
> Stefan
>
> ---------------
> Observations hacking on OpenSSL 3.0 compatibility:
>
> - SRP seems to be gone.
> - the ENGINE API seems to be gone
> - RSA*, DH* and friends are no longer wanted.
> Instead, the PKEY API offers replacements.
> - This affects reading key parameter from files, afaict.
> - Some minor annoyances with BIO_set_callback and
> ERR_peek_last..
> - I changed EC key generation in mod_md to the new API,
> but generation failed at runtime. Maybe a minor glitch
> on my part.
> - The code overall does not become prettier.
>
>
>

Re: openssl 3.0 when [ In reply to ]

stefan at eissing

Nov 2, 2021, 1:23 AM

Post #3 of 6 (555 views)

Permalink

> Am 01.11.2021 um 15:24 schrieb Joe Orton <jorton@redhat.com>:
>
> On Sun, Oct 31, 2021 at 01:35:09PM +0100, stefan@eissing.org wrote:
>> I would like us to come to an understanding what our roadmap in
>> regard to OpenSSL 3.0 is. People keep on asking about it.
>>
>> Yesterday, I spent some hours hacking at mod_ssl and mod_md to
>> get it running. I managed to compile it, but it was not working
>> reliably. Maybe I took some wrong turns somewhere. My observations
>> below.
>
> What are you talking about exactly here? trunk should compile and run
> fine already with 3.0 except if you build OpenSSL without deprecated
> functions which AFAIK nobody sane will do, or at least, no sane
> distributor will do, because the world is not ready.

I was trying to make it work without deprecated functions. Sorry,
to have not been more clear. If we regard 3.0 conformance including
those, then this is a non-issue, aside from actually testing that
it still works.

>> With my RM hat on, I see the next release in early December. We
>> have some fixes to ship and maybe the new http2 implementation.
>>
>> Personally, I do not see a need for OpenSSL 3.0 in that one. But
>> if anyone has plans to do it, it would be good to know.
>
> I would still like to get a Travis job testing against 3.0, on my TODO,
> but I don't know of any compatilibity problems not covered in trunk /
> https://github.com/apache/httpd/pull/258 (outside use of deprecated
> functions anyway).
>
> Regards, Joe
>
>
>>
>> Kind Regards,
>> Stefan
>>
>> ---------------
>> Observations hacking on OpenSSL 3.0 compatibility:
>>
>> - SRP seems to be gone.
>> - the ENGINE API seems to be gone
>> - RSA*, DH* and friends are no longer wanted.
>> Instead, the PKEY API offers replacements.
>> - This affects reading key parameter from files, afaict.
>> - Some minor annoyances with BIO_set_callback and
>> ERR_peek_last..
>> - I changed EC key generation in mod_md to the new API,
>> but generation failed at runtime. Maybe a minor glitch
>> on my part.
>> - The code overall does not become prettier.
>>
>>
>>
>

Re: openssl 3.0 when [ In reply to ]

jorton at redhat

Nov 2, 2021, 2:31 AM

Post #4 of 6 (555 views)

Permalink

On Tue, Nov 02, 2021 at 09:23:32AM +0100, stefan@eissing.org wrote:
>
> > Am 01.11.2021 um 15:24 schrieb Joe Orton <jorton@redhat.com>:
> >
> > On Sun, Oct 31, 2021 at 01:35:09PM +0100, stefan@eissing.org wrote:
> >> I would like us to come to an understanding what our roadmap in
> >> regard to OpenSSL 3.0 is. People keep on asking about it.
> >>
> >> Yesterday, I spent some hours hacking at mod_ssl and mod_md to
> >> get it running. I managed to compile it, but it was not working
> >> reliably. Maybe I took some wrong turns somewhere. My observations
> >> below.
> >
> > What are you talking about exactly here? trunk should compile and run
> > fine already with 3.0 except if you build OpenSSL without deprecated
> > functions which AFAIK nobody sane will do, or at least, no sane
> > distributor will do, because the world is not ready.
>
> I was trying to make it work without deprecated functions. Sorry,
> to have not been more clear. If we regard 3.0 conformance including
> those, then this is a non-issue, aside from actually testing that
> it still works.

IMO at least it's a non-issue in the "short"-ish term. Other opinions
are available ;)

Maybe a good transition plan would be to drop use of the deprecated
functions at the same time we drop support for versions < 3.0, to ease
the pain of having to support both? Upstream say they will support
1.1.1 until the late 2023, since OS vendors will support it beyond that
I'd expect there's consensus here to support it for longer. Thoughts?

https://www.openssl.org/policies/releasestrat.html

Regards, Joe

Re: openssl 3.0 when [ In reply to ]

rpluem at apache

Nov 2, 2021, 3:56 AM

Post #5 of 6 (555 views)

Permalink

On 11/2/21 10:31 AM, Joe Orton wrote:
> On Tue, Nov 02, 2021 at 09:23:32AM +0100, stefan@eissing.org wrote:
>>
>>> Am 01.11.2021 um 15:24 schrieb Joe Orton <jorton@redhat.com>:
>>>
>>> On Sun, Oct 31, 2021 at 01:35:09PM +0100, stefan@eissing.org wrote:
>>>> I would like us to come to an understanding what our roadmap in
>>>> regard to OpenSSL 3.0 is. People keep on asking about it.
>>>>
>>>> Yesterday, I spent some hours hacking at mod_ssl and mod_md to
>>>> get it running. I managed to compile it, but it was not working
>>>> reliably. Maybe I took some wrong turns somewhere. My observations
>>>> below.
>>>
>>> What are you talking about exactly here? trunk should compile and run
>>> fine already with 3.0 except if you build OpenSSL without deprecated
>>> functions which AFAIK nobody sane will do, or at least, no sane
>>> distributor will do, because the world is not ready.
>>
>> I was trying to make it work without deprecated functions. Sorry,
>> to have not been more clear. If we regard 3.0 conformance including
>> those, then this is a non-issue, aside from actually testing that
>> it still works.
>
> IMO at least it's a non-issue in the "short"-ish term. Other opinions
> are available ;)
>
> Maybe a good transition plan would be to drop use of the deprecated
> functions at the same time we drop support for versions < 3.0, to ease
> the pain of having to support both? Upstream say they will support

+1

> 1.1.1 until the late 2023, since OS vendors will support it beyond that
> I'd expect there's consensus here to support it for longer. Thoughts?

I think we should keep supporting 1.1.1 for longer as at least RedHat 8 and Ubuntu 20 ship with it.
Using a different OpenSSL lib, than the OS provided one becomes a real pain once you want to use
further OS packages for modules that in turn use the system provided OpenSSL library.
There are even still supported LTS distributions out there which still use 1.0.2.

Regards

Rüdiger

Re: openssl 3.0 when [ In reply to ]

stefan at eissing

Nov 2, 2021, 4:03 AM

Post #6 of 6 (555 views)

Permalink

> Am 02.11.2021 um 11:56 schrieb Ruediger Pluem <rpluem@apache.org>:
>
>
>
> On 11/2/21 10:31 AM, Joe Orton wrote:
>> On Tue, Nov 02, 2021 at 09:23:32AM +0100, stefan@eissing.org wrote:
>>>
>>>> Am 01.11.2021 um 15:24 schrieb Joe Orton <jorton@redhat.com>:
>>>>
>>>> On Sun, Oct 31, 2021 at 01:35:09PM +0100, stefan@eissing.org wrote:
>>>>> I would like us to come to an understanding what our roadmap in
>>>>> regard to OpenSSL 3.0 is. People keep on asking about it.
>>>>>
>>>>> Yesterday, I spent some hours hacking at mod_ssl and mod_md to
>>>>> get it running. I managed to compile it, but it was not working
>>>>> reliably. Maybe I took some wrong turns somewhere. My observations
>>>>> below.
>>>>
>>>> What are you talking about exactly here? trunk should compile and run
>>>> fine already with 3.0 except if you build OpenSSL without deprecated
>>>> functions which AFAIK nobody sane will do, or at least, no sane
>>>> distributor will do, because the world is not ready.
>>>
>>> I was trying to make it work without deprecated functions. Sorry,
>>> to have not been more clear. If we regard 3.0 conformance including
>>> those, then this is a non-issue, aside from actually testing that
>>> it still works.
>>
>> IMO at least it's a non-issue in the "short"-ish term. Other opinions
>> are available ;)
>>
>> Maybe a good transition plan would be to drop use of the deprecated
>> functions at the same time we drop support for versions < 3.0, to ease
>> the pain of having to support both? Upstream say they will support
>
> +1
>
>> 1.1.1 until the late 2023, since OS vendors will support it beyond that
>> I'd expect there's consensus here to support it for longer. Thoughts?
>
> I think we should keep supporting 1.1.1 for longer as at least RedHat 8 and Ubuntu 20 ship with it.
> Using a different OpenSSL lib, than the OS provided one becomes a real pain once you want to use
> further OS packages for modules that in turn use the system provided OpenSSL library.
> There are even still supported LTS distributions out there which still use 1.0.2.

+1

Do we have a common way to build against openssl 3.0 without the deprecations being errors? Just want to be sure we all use the same.

Cheers,
Stefan