Age | Commit message (Collapse) | Author |
|
|
|
- Disable ALPN on Wine.
- Don't pass input secbuffer when ALPN is disabled.
When ALPN support was added a change was made to pass an input secbuffer
to initialize the context. When ALPN is enabled the buffer contains the
ALPN information, and when it's disabled the buffer is empty. In either
case this input buffer caused problems with Wine and connections would
not complete.
Bug: https://github.com/curl/curl/issues/983
Reported-by: Christian Fillion
|
|
Serialise the call to PK11_FindSlotByName() to avoid spurious errors in
a multi-threaded environment. The underlying cause is a race condition
in nssSlot_IsTokenPresent().
Bug: https://bugzilla.mozilla.org/1297397
Closes #985
|
|
... when we are not asked to use a certificate from file
|
|
|
|
|
|
|
|
|
|
- unknown protocols probably won't send more headers (e.g. WebSocket)
- improved comments and moved them to the correct case statements
Closes #899
|
|
synced with OpenSSL git master commit cc06906707
|
|
|
|
... instead of relying on the pkg-config autoconf macros to be present.
Fixes #972 (again...)
|
|
.. also remove same from scp
|
|
When we're uploading using FTP and the server issues a tiny pause
between opening the connection to the client's secondary socket, the
client's initial poll() times out, which leads to second poll() which
does not wait for POLLIN on the secondary socket. So that poll() also
has to time out, creating a long (200ms) pause.
This patch adds the correct flag to the secondary socket, making the
second poll() correctly wait for the connection there too.
Signed-off-by: Ales Novak <alnovak@suse.cz>
Closes #978
|
|
|
|
With commit c2f9b78 we added a new dependency on pkg-config for
developers which may be unwanted. This change make the configure script
still work as before if pkg-config isn't installed, it'll just use the
old zlib detection logic without pkg-config.
Reported-by: Marc Hörsken
Fixes #972
|
|
This reverts commit 9cb1059f92286a6eb5d28c477fdd3f26aed1d554.
As discussed in #835 SOCKS5 supports IPv6 proxies and destinations.
|
|
Closes #820
|
|
Only choose the GSSAPI authentication mechanism when the user name
contains a Windows domain name or the user is a valid UPN.
Fixes #718
|
|
Completing commit 00417fd66c and 2708d4259b.
|
|
From commit 2708d4259b.
|
|
Instead of displaying the requested hostname the one returned
by the SOCKS5 proxy server is used in case of connection error.
The requested hostname is displayed earlier in the connection sequence.
The upper-value of the port is moved to a temporary variable and
replaced with a 0-byte to make sure the hostname is 0-terminated.
|
|
As of 7.25.0 and commit 5430007222.
|
|
Replace custom string formatting with Curl_printable_address.
Add additional debug and error output in case of failures.
|
|
Calling sscanf is not required since the raw IPv4 address is
available and the protocol can be detected using ai_family.
|
|
Made by Visual Studio's auto-correct feature and missed by me in my own
code reviews!
|
|
Hooked up the HTTP authentication layer to query the new 'is mechanism
supported' functions when deciding what mechanism to use.
As per commit 00417fd66c existing functionality is maintained for now.
|
|
|
|
|
|
Hooked up the SASL authentication layer to query the new 'is mechanism
supported' functions when deciding what mechanism to use.
For now existing functionality is maintained.
|
|
|
|
|
|
As Windows SSPI authentication calls fail when a particular mechanism
isn't available, introduced these functions for DIGEST, NTLM, Kerberos 5
and Negotiate to allow both HTTP and SASL authentication the opportunity
to query support for a supported mechanism before selecting it.
For now each function returns TRUE to maintain compatability with the
existing code when called.
|
|
|
|
...and removed some old ones
|
|
RFC7512 provides a standard method to reference certificates in PKCS#11
tokens, by means of a URI starting 'pkcs11:'.
We're working on fixing various applications so that whenever they would
have been able to use certificates from a file, users can simply insert
a PKCS#11 URI instead and expect it to work. This expectation is now a
part of the Fedora packaging guidelines, for example.
This doesn't work with cURL because of the way that the colon is used
to separate the certificate argument from the passphrase. So instead of
curl -E 'pkcs11:manufacturer=piv_II;id=%01' …
I instead need to invoke cURL with the colon escaped, like this:
curl -E 'pkcs11\:manufacturer=piv_II;id=%01' …
This is suboptimal because we want *consistency* — the URI should be
usable in place of a filename anywhere, without having strange
differences for different applications.
This patch therefore disables the processing in parse_cert_parameter()
when the string starts with 'pkcs11:'. It means you can't pass a
passphrase with an unescaped PKCS#11 URI, but there's no need to do so
because RFC7512 allows a PIN to be given as a 'pin-value' attribute in
the URI itself.
Also, if users are already using RFC7512 URIs with the colon escaped as
in the above example — even providing a passphrase for cURL to handling
instead of using a pin-value attribute, that will continue to work
because their string will start 'pkcs11\:' and won't match the check.
What *does* break with this patch is the extremely unlikely case that a
user has a file which is in the local directory and literally named
just "pkcs11", and they have a passphrase on it. If that ever happened,
the user would need to refer to it as './pkcs11:<passphrase>' instead.
|
|
|
|
This allows for better memmory debugging and torture tests.
|
|
This fixes tests that were added after 113f04e664b as the tests would
fail otherwise.
We bring back "Proxy-Connection: Keep-Alive" now unconditionally to fix
regressions with old and stupid proxies, but we could possibly switch to
using it only for CONNECT or only for NTLM in a future if we want to
gradually reduce it.
Fixes #954
Reported-by: János Fekete
|
|
This reverts commit 113f04e664b16b944e64498a73a4dab990fe9a68.
|
|
Follow-up to a96319ebb9 (document the new behavior)
|
|
|
|
|
|
Follow up to a96319ebb93
|
|
|
|
I discovered some people have been using "https://example.com" style
strings as proxy and it "works" (curl doesn't complain) because curl
ignores unknown schemes and then assumes plain HTTP instead.
I think this misleads users into believing curl uses HTTPS to proxies
when it doesn't. Now curl rejects proxy strings using unsupported
schemes instead of just ignoring and defaulting to HTTP.
|
|
|
|
Third commit to fix issue #944 regarding SOCKS5 error handling.
Reported-by: David Kalnischkies
|
|
Second commit to fix issue #944 regarding SOCKS5 error handling.
Reported-by: David Kalnischkies
|
|
First commit to fix issue #944 regarding SOCKS5 error handling.
Reported-by: David Kalnischkies
|