You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Joe Orton <jo...@redhat.com> on 2021/11/01 14:24:27 UTC
Re: openssl 3.0 when
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
Posted by "stefan@eissing.org" <st...@eissing.org>.
> Am 02.11.2021 um 11:56 schrieb Ruediger Pluem <rp...@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 <jo...@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
Re: openssl 3.0 when
Posted by Ruediger Pluem <rp...@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 <jo...@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
Posted by Joe Orton <jo...@redhat.com>.
On Tue, Nov 02, 2021 at 09:23:32AM +0100, stefan@eissing.org wrote:
>
> > Am 01.11.2021 um 15:24 schrieb Joe Orton <jo...@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
Posted by "stefan@eissing.org" <st...@eissing.org>.
> Am 01.11.2021 um 15:24 schrieb Joe Orton <jo...@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.
>>
>>
>>
>