Buy commercial curl support. We
help you work out your issues, debug your libcurl applications, use the API,
port to new platforms, add new features and more. With a team lead by the
curl founder Daniel himself.
Re: Help us out in the curl project!
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Stephen Farrell <stephen.farrell_at_cs.tcd.ie>
Date: Thu, 3 Apr 2025 11:58:30 +0100
Hiya,
On 31/03/2025 22:32, Samuel Henrique via curl-library wrote:
> I couldn't enable ECH as that requires a fork of OpenSSL and GnuTLS doesn't
> support it yet.
I've a question if that's ok...
We're working with the OpenSSL maintainers on getting ECH
upstreamed. At present ECH code is going into a "feature
branch" [1] with the intent that that'll later end up in
the "master" branch and eventually a release.
We're on the cusp(*) of having that ECH feature branch be
capable of doing all the client side of ECH, so we could
v. easily submit a PR to curl that documents to use that
branch for your OpenSSL build, when testing ECH.
That's of course not the same as having ECH in an OpenSSL
release, but my question is: would doing that enable you
to test ECH sooner? (If so, we'd be happy to prioritise
the curl PR mentioned above as soon as makes sense - it
should just be a bit of documentation change and testing
as the ECH APIs for OpenSSL aren't changing now.)
Cheers,
S.
(*) I have two maintainer approvals for ECH client code
for the feature branch, which is what the OpenSSL project
policy requires, so the OpenSSL PR, [2] that needs to be
merged to enable the above plan, should be merged "soon";-)
[1] https://github.com/openssl/openssl/tree/feature/ech
[2] https://github.com/openssl/openssl/pull/26011
Received on 2025-04-03
Date: Thu, 3 Apr 2025 11:58:30 +0100
Hiya,
On 31/03/2025 22:32, Samuel Henrique via curl-library wrote:
> I couldn't enable ECH as that requires a fork of OpenSSL and GnuTLS doesn't
> support it yet.
I've a question if that's ok...
We're working with the OpenSSL maintainers on getting ECH
upstreamed. At present ECH code is going into a "feature
branch" [1] with the intent that that'll later end up in
the "master" branch and eventually a release.
We're on the cusp(*) of having that ECH feature branch be
capable of doing all the client side of ECH, so we could
v. easily submit a PR to curl that documents to use that
branch for your OpenSSL build, when testing ECH.
That's of course not the same as having ECH in an OpenSSL
release, but my question is: would doing that enable you
to test ECH sooner? (If so, we'd be happy to prioritise
the curl PR mentioned above as soon as makes sense - it
should just be a bit of documentation change and testing
as the ECH APIs for OpenSSL aren't changing now.)
Cheers,
S.
(*) I have two maintainer approvals for ECH client code
for the feature branch, which is what the OpenSSL project
policy requires, so the OpenSSL PR, [2] that needs to be
merged to enable the above plan, should be merged "soon";-)
[1] https://github.com/openssl/openssl/tree/feature/ech
[2] https://github.com/openssl/openssl/pull/26011
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
- application/pgp-signature attachment: OpenPGP digital signature