info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1011391: openssl: please support quictls patchset
149 views
Skip to first unread message
Jérémy Lal
May 21, 2022, 1:10:03 PM5/21/22
to
Package: openssl
Version: 3.0.3-5
Severity: wishlist
There is a patchset for quic protocol
https://github.com/quictls/openssl
Many softwares are starting to use that copy of openssl,
meaning their debian maintainers are going to need to
disable QUIC support explicitely to be able to link to
debian's openssl shared library.
Or, if the feature is so crucial that it cannot be disabled,
they will statically link to the embedded copy of openssl+quic.
Non-exhaustive list: curl, apache, nodejs.
It'd be nice, (and IMO soon to be critical), to either get openssl+quic
by default, or at least build an alternate +quic package.
I open this wishlist bug to be able to track information about this.
Version: 3.0.3-5
Severity: wishlist
There is a patchset for quic protocol
https://github.com/quictls/openssl
Many softwares are starting to use that copy of openssl,
meaning their debian maintainers are going to need to
disable QUIC support explicitely to be able to link to
debian's openssl shared library.
Or, if the feature is so crucial that it cannot be disabled,
they will statically link to the embedded copy of openssl+quic.
Non-exhaustive list: curl, apache, nodejs.
It'd be nice, (and IMO soon to be critical), to either get openssl+quic
by default, or at least build an alternate +quic package.
I open this wishlist bug to be able to track information about this.
Sakirnth Nagarasa
May 22, 2022, 11:00:04 AM5/22/22
to
Hi
This patchset of OpenSSL is necessary to build the crypto helper
libraries for ngtcp2 with OpenSSL as well.
There was a pull request to support QUIC directly in OpenSSL, but it was
closed because OpenSSL wanted to implement a different QUIC
implementation. But according to the comments in the PR the community
seems not to be satisfied with this approach and it takes a while until
they implement it according to the OMC Release Requirements. So I assume
a lot of them will use this patchset like ngtcp2 already does.
URLs:
https://github.com/openssl/openssl/pull/8797 (Pull request)
https://www.mail-archive.com/openssl...@openssl.org/msg02585.html
(OMC Release Requirements)
So it would be really nice if one of the options Jérémy Lal described
could be implemented.
Thanks
Sakirnth
This patchset of OpenSSL is necessary to build the crypto helper
libraries for ngtcp2 with OpenSSL as well.
There was a pull request to support QUIC directly in OpenSSL, but it was
closed because OpenSSL wanted to implement a different QUIC
implementation. But according to the comments in the PR the community
seems not to be satisfied with this approach and it takes a while until
they implement it according to the OMC Release Requirements. So I assume
a lot of them will use this patchset like ngtcp2 already does.
URLs:
https://github.com/openssl/openssl/pull/8797 (Pull request)
https://www.mail-archive.com/openssl...@openssl.org/msg02585.html
(OMC Release Requirements)
So it would be really nice if one of the options Jérémy Lal described
could be implemented.
Thanks
Sakirnth
Vincent Bernat
Jun 7, 2022, 2:30:03 AM6/7/22
to
❦ 22 May 2022 16:50 +02, Sakirnth Nagarasa:
> This patchset of OpenSSL is necessary to build the crypto helper
> libraries for ngtcp2 with OpenSSL as well.
HAProxy is also a user of such a fork. It should be noted the fork is
backed by Akamai and Microsoft and is able to release updated versions
the same day as OpenSSL and they managed to make the library
coinstallable with the regular OpenSSL one. So, we could also provide a
libssl3-quick library.
Willy Tarreau already asked the team for QuicTLS packaging without an
answer:
https://alioth-lists.debian.net/pipermail/pkg-openssl-devel/2021-October/007668.html
My opinion is that we cannot rely on OpenSSL to provide a solution in
the near term (no work is currently done). As the number of downstream
projects increase, users will try to find a solution. It would be better
to have a solution backed at least partially by their distribution.
It would be nice to have some kind of feedback to know how things are on
the Debian side for this OpenSSL fork.
--
Make sure comments and code agree.
- The Elements of Programming Style (Kernighan & Plauger)
> This patchset of OpenSSL is necessary to build the crypto helper
> libraries for ngtcp2 with OpenSSL as well.
backed by Akamai and Microsoft and is able to release updated versions
the same day as OpenSSL and they managed to make the library
coinstallable with the regular OpenSSL one. So, we could also provide a
libssl3-quick library.
Willy Tarreau already asked the team for QuicTLS packaging without an
answer:
https://alioth-lists.debian.net/pipermail/pkg-openssl-devel/2021-October/007668.html
My opinion is that we cannot rely on OpenSSL to provide a solution in
the near term (no work is currently done). As the number of downstream
projects increase, users will try to find a solution. It would be better
to have a solution backed at least partially by their distribution.
It would be nice to have some kind of feedback to know how things are on
the Debian side for this OpenSSL fork.
--
Make sure comments and code agree.
- The Elements of Programming Style (Kernighan & Plauger)
Sebastian Andrzej Siewior
Jun 8, 2022, 1:50:03 AM6/8/22
to
On 2022-06-07 08:23:40 [+0200], Vincent Bernat wrote:
> Willy Tarreau already asked the team for QuicTLS packaging without an
> answer:
>
> https://alioth-lists.debian.net/pipermail/pkg-openssl-devel/2021-October/007668.html
there was an answer:
> Willy Tarreau already asked the team for QuicTLS packaging without an
> answer:
>
> https://alioth-lists.debian.net/pipermail/pkg-openssl-devel/2021-October/007668.html
https://alioth-lists.debian.net/pipermail/pkg-openssl-devel/2022-January/007702.html
Sebastian
Vincent Bernat
Jun 8, 2022, 2:50:04 AM6/8/22
to
❦ 8 June 2022 07:44 +02, Sebastian Andrzej Siewior:
>> Willy Tarreau already asked the team for QuicTLS packaging without an
>> answer:
>>
>> https://alioth-lists.debian.net/pipermail/pkg-openssl-devel/2021-October/007668.html
>
> there was an answer:
> https://alioth-lists.debian.net/pipermail/pkg-openssl-devel/2022-January/007702.html
Oh, sorry for saying otherwise. It seems pipermail does not provide
links when a thread span over two months.
As for the last paragraph, OpenSSL team said API compatibility with the
patchset is a non-goal and it was also said they would like to not use
the same approach by unifying the various way to handle TLS flavors. So
it seems likely QuicTLS will die at some point. However, QUIC support
will appear during a major version of OpenSSL, so previous version
supporting the QuicTLS patchset will continue to receive security
support and I suppose that it gives time for the few users to migrate
to the proper OpenSSL API.
I can relay your questions directly to QuicTLS on GitHub unless you want
to do it yourself.
--
Use library functions.
>> Willy Tarreau already asked the team for QuicTLS packaging without an
>> answer:
>>
>> https://alioth-lists.debian.net/pipermail/pkg-openssl-devel/2021-October/007668.html
>
> there was an answer:
> https://alioth-lists.debian.net/pipermail/pkg-openssl-devel/2022-January/007702.html
links when a thread span over two months.
As for the last paragraph, OpenSSL team said API compatibility with the
patchset is a non-goal and it was also said they would like to not use
the same approach by unifying the various way to handle TLS flavors. So
it seems likely QuicTLS will die at some point. However, QUIC support
will appear during a major version of OpenSSL, so previous version
supporting the QuicTLS patchset will continue to receive security
support and I suppose that it gives time for the few users to migrate
to the proper OpenSSL API.
I can relay your questions directly to QuicTLS on GitHub unless you want
to do it yourself.
--
Use library functions.
0 new messages