1. Forum
  2. Usenet
  3. LINUX.GENTOO.DEV

  • [gentoo-dev] [PATCH 1/3] profiles/desc: add curl_quic

    From kangie@gentoo.org@21:1/5 to All on Fri Jun 21 15:20:01 2024
    From: Matt Jolly <kangie@gentoo.org>

    The CURL_QUIC USE_EXPAND enables us to sanely manage QUIC (RFC 9000)
    backends as they are added to cURL in the future: currently there are
    two supported implementations, OpenSSL and ngtcp2, however it's likely
    that other popular TLS libraries will expose QUIC APIs over time,
    and that these will be eventually be supported by cURL (see CURL_SSL
    for examples of TLS libraries that we support) - we may as well
    get ahead of the curve here.

    There are already a number of other small players (i.e. OpenSSL Forks)
    exposing QUIC support for quite a while, however these have not been
    available in ::gentoo and we've only needed the one USE to enable
    for HTTP/3 and QUIC to this point.

    Signed-off-by: Matt Jolly <kangie@gentoo.org>
    ---
    profiles/desc/curl_quic.desc | 7 +++++++
    1 file changed, 7 insertions(+)
    create mode 100644 profiles/desc/curl_quic.desc

    diff --git a/profiles/desc/curl_quic.desc b/profiles/desc/curl_quic.desc
    new file mode 100644
    index 000000000000..372bb9ce8f83
    --- /dev/null
    +++ b/profiles/desc/curl_quic.desc
    @@ -0,0 +1,7 @@
    +# Copyright 1999-2024 Gentoo Authors
    +# Distributed under the terms of the GNU General Public License v2
    +
    +# This file contains descriptions of CURL_QUIC USE_EXPAND flags for net-misc/curl
    +
    +openssl - Use OpenSSL
    +ngtcp2 - Use ngtcp2
    --
    2.45.2

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jaco Kroon@21:1/5 to kangie@gentoo.org on Fri Jun 21 16:50:01 2024
    Hi,

    On 2024/06/21 15:15, kangie@gentoo.org wrote:

    From: Matt Jolly <kangie@gentoo.org>

    The CURL_QUIC USE_EXPAND enables us to sanely manage QUIC (RFC 9000)
    backends as they are added to cURL in the future: currently there are
    two supported implementations, OpenSSL and ngtcp2, however it's likely
    that other popular TLS libraries will expose QUIC APIs over time,
    and that these will be eventually be supported by cURL (see CURL_SSL
    for examples of TLS libraries that we support) - we may as well
    get ahead of the curve here.

    There are already a number of other small players (i.e. OpenSSL Forks) exposing QUIC support for quite a while, however these have not been available in ::gentoo and we've only needed the one USE to enable
    for HTTP/3 and QUIC to this point.

    Signed-off-by: Matt Jolly <kangie@gentoo.org>
    ---
    profiles/desc/curl_quic.desc | 7 +++++++
    1 file changed, 7 insertions(+)
    create mode 100644 profiles/desc/curl_quic.desc

    diff --git a/profiles/desc/curl_quic.desc b/profiles/desc/curl_quic.desc
    new file mode 100644
    index 000000000000..372bb9ce8f83
    --- /dev/null
    +++ b/profiles/desc/curl_quic.desc
    @@ -0,0 +1,7 @@
    +# Copyright 1999-2024 Gentoo Authors
    +# Distributed under the terms of the GNU General Public License v2
    +
    +# This file contains descriptions of CURL_QUIC USE_EXPAND flags for net-misc/curl
    +
    +openssl - Use OpenSSL
    +ngtcp2 - Use ngtcp2

    May I suggest simply calling this USE_EXPAND QUIC_IMPL so that other
    packages can potentially re-use as well?

    looking through ::gentoo at least net-dns/dnsdist and net-dns/knot also
    has a quic support, using ngtcp2 and/or net-libs/quiche.

    With openssl 3.2 hopefully approaching stable at some point I suspect
    the number of projects that will be adding quic support via one or
    another channel (possibly with alternative implementations) will only
    increase, thus pinning the USE_EXPAND on a single package seems
    potentially short-sighted.

    Kind regards,
    Jaco

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Matt Jolly@21:1/5 to All on Mon Jun 24 04:10:01 2024
    Hi Jaco,

    May I suggest simply calling this USE_EXPAND QUIC_IMPL so that other
    packages can potentially re-use as well?

    looking through ::gentoo at least net-dns/dnsdist and net-dns/knot also
    has a quic support, using ngtcp2 and/or net-libs/quiche.

    With openssl 3.2 hopefully approaching stable at some point I suspect
    the number of projects that will be adding quic support via one or
    another channel (possibly with alternative implementations) will only increase, thus pinning the USE_EXPAND on a single package seems
    potentially short-sighted.

    My knee-jerk response was to claim that cURL is unique in the
    number of backends supported (and way that it tends to support
    configuring for multiple implementations at once), but then I took the
    time to look at the various TLS USE flags for things like web servers
    and I've warmed up to the suggestion.

    I can certainly see some benefit to having a generic USE_EXPAND that
    covers QUIC implementations (and maybe one for TLS impls?). We could
    probably replace CURL_SSL and CURL_QUIC with the generics, though I'd
    still need to retain the existing global USE that this would deprecate
    (at least as local USE in net-misc/curl) as the current ebuild logic
    relies on both USE and USE_EXPAND for TLS implementation selection.

    I'm interested in hearing some other opinions though - is there some
    reason this hasn't already been done?

    The alternative (doing nothing) still seems appealing given that OpenSSL
    seems likely to remain the 'default' implementation as QUIC adoption
    rises, and the existing USE (and profile) settings have proven
    sufficient (and not too confusing) so far.

    Ideally, if the generic USE_EXPAND option is pursued I imagine that
    we would want to hit all of the ebuilds (etc) at once and ensure that
    an appropriate news item concerning the migration has been distributed.
    There's nothing stopping us from implementing this solution as a
    separate change that doesn't block the cURL updates while we decide
    whether one (or more) generic USE_EXPAND variables make sense.

    Thanks,

    Matt

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)