Builder curl-ares-solaris11-sparc Build #6052

Results:

Build successful

SourceStamp:

BuildSlave:

Reason:

The SingleBranchScheduler scheduler named 'schedule-curl-ares-solaris11-sparc' triggered this build

Steps and Logfiles:

1. git update ( 1 secs )
   1. stdio
2. Runtest './tests/testcurl.pl --nogitpull ...' ( 2 mins, 40 secs )
   1. stdio
   2. resultlog
3. Mail result 'cat resultlog ...' ( 0 secs )
   1. stdio

Build Properties:

Forced Build Properties:

Responsible Users:

1. Daniel Stenberg

   danielohnoyoudont@haxx.se
2. Dave Walker

   daveohnoyoudont@daviey.com
3. Stefan Eissing

   stefanohnoyoudont@eissing.org
4. Tobias Frauenschläger

   tobiasohnoyoudont@wolfssl.com

Timing:

All Changes:

:

1. Change #271222

   Category	curl
   Changed by	Tobias Frauenschläger <tobiasohnoyoudont@wolfssl.com>
   Changed at	Mon 15 Jun 2026 22:18:29
   Repository	https://github.com/curl/curl.git
   Project	curl
   Branch	master
   Revision	50ffc359e943b2b55268b6c8507524fb0c23dc9c

   Comments

   tls: wolfssl: fixes for PQC key shares
   This PR makes the wolfssl TLS backend work properly for PQC key
   exchanges. The following issues are fixed:
   * WOLFSSL_HAVE_KYBER is not present anymore in upstream wolfssl (for a
     long time actually), so it has no use and the ML-KEM functionality was
     never turned on properly.
   * Key share group selection (via --curves) is now handled via the
     generic wolfSSL_CTX_set1_groups_list() method instead of the prior
     wolfSSL_CTX_set1_curves_list() and the additonal PQC handling. This
     removes a lot of PQC related special handling and the behavior now
     matches the OpenSSL backend.
   * The default QUIC group setting has been removed. For QUIC, the key
     share as well as the list in the supported_groups extension is now
     handled all within wolfssl. This also supports --curves properly now.
   
   Closes #22030

   Changed files

   • lib/vtls/wolfssl.c

2. Change #271226

   Category	curl
   Changed by	Dave Walker <daveohnoyoudont@daviey.com>
   Changed at	Mon 15 Jun 2026 22:30:14
   Repository	https://github.com/curl/curl.git
   Project	curl
   Branch	master
   Revision	b9702f8c487135695ee07a69a24d85e4f7eba40e

   Comments

   cookie: use origin scheme for secure context check
   `Curl_secure_context()` checked `conn->scheme` to determine if Secure
   cookies may be sent. Since 73daec6, `conn->scheme` is set to the proxy's
   scheme when using an HTTPS forwarding proxy, causing the function to
   return TRUE for HTTP origins. This leaked Secure cookies over the
   plaintext connection between proxy and origin.
   
   Use `data->state.origin->scheme` instead, which always reflects the
   origin's scheme regardless of proxy configuration.
   
   Not an approved vulnerability because the regression was introduced
   after the last release and is not present in any released version.
   
   Verified by test 3401
   
   Follow-up to 73daec6620bf9983df89e8df3660bfa3b8fd501d
   Reported-by: daviey on hackerone
   URL: https://hackerone.com/reports/3803415
   Closes #22024

   Changed files

   • lib/cookie.c
   • lib/cookie.h
   • lib/http.c
   • tests/data/Makefile.am
   • tests/data/test3401

3. Change #271227

   Category	curl
   Changed by	Stefan Eissing <stefanohnoyoudont@eissing.org>
   Changed at	Mon 15 Jun 2026 22:32:15
   Repository	https://github.com/curl/curl.git
   Project	curl
   Branch	master
   Revision	bb72413b03c8f74f1bc88c7292a53a15db74cd20

   Comments

   cf-https-connect: do not engage on proxy origin
   When talking to a forwarding proxy, do not start HTTPS Eyeballing.
   We might support this in the future, but for now, the --httpx.x
   arguments to do not apply to such a setup.
   
   Add a test case for forward proxying without use of ALPN.
   
   Closes #22033

   Changed files

   • lib/cf-https-connect.c
   • tests/http/test_10_proxy.py

4. Change #271228

   Category	curl
   Changed by	Daniel Stenberg <danielohnoyoudont@haxx.se>
   Changed at	Mon 15 Jun 2026 22:35:33
   Repository	https://github.com/curl/curl.git
   Project	curl
   Branch	master
   Revision	7f57aeec40926dce22d997cf05810fb9c9c721d3

   Comments

   verify-release: don't unpack in git repo
   - Clarify that the tarball to verify should be put in the same dir you
     run the script.
   
   - Verify that the curl version number in the file name matches the
     version number within the tarball. To reduce risk for mistakes.
   
   - When verifying using git, do not unpack the tarball. It avoids the
     security risk with malicious tarball contents playing tricks on git.
   
   - Only unpack the tarball for git-less verfication.
   
   - Move the source tarball into _tarballs/ instead of overwriting it,
     which can be useful in case the verification fails
   
   Closes #22032

   Changed files

   • scripts/verify-release