On Tue, 24 Mar 2020, Daniel Stenberg wrote:
> The current git master of OpenSSL gives us some clues of what's going to
> happen when OpenSSL version 3 ships, planned for Q3 2020 I believe. I make a
> curl build against that every once in a while to see if anything falls over.
>
> Now for the one
On Mon, 8 Aug 2016, Rod Widdowson wrote:
> What's the story with the projects\vcXXX tree. I think that it is less
> capable> than the command line, but we are trying to move our projects that
> way
It was always going to be work in progress, however, my initial aim was to add
support for
On Mon, 8 Aug 2016, Daniel Stenberg wrote:
> I was prompted by a recent PR [1] to once again revisit this idea: I want to
> remove the nmake build files for Windows (all the files named
> Makefile.vc[number]). I want to have windows users wanting to build curl on
> the command line to use the
On Sun, 7 Aug 2016, Daniel Stenberg wrote:
> > I also appreciate this is a little subjective but I would have thought
> > adding support for NTLM with mbedTLS is also a new functionality -
> > previously NTLM wasn't supported with mbedTLS so I wouldn't class that as a
> > bug fix.
>
> That's
> On Sat, 6 Aug 2016, Daniel Stenberg wrote:
> > I've already push Bill's mbedTLS NTLM addition and I'm hoping to get
> > Sergei's LDAP change pushed this weekend (although I might to step up and
> > finish the documentation side off!). Is this enough for a major bump as I
> > probably need to
On Tue, 2 Aug 2016, Daniel Stenberg wrote:
> It is quite possible that the next release following 7.50.1 also will become
> a
> patch release since we don't have any particular changes queued up (that would
I've already push Bill's mbedTLS NTLM addition and I'm hoping to get Sergei's
LDAP
Hi all,
We recently received a Pull Request [1] to add support for ldap_bind_s() on
Windows and as such use more secure authentication mechanisms.
With this came the ability for the user / programmer to specify the required
authentication mechanism to use via --basic, --digest and --ntlm
On Mon, 30 May 2016, Martin wrote:
> "dev1" is working correct.
> "dev2" is not working correct.
>
> As you can see on "dev2" the outgoing IMAP commands are different -->
> "B
CAPABILITY" versus "dev1" --> "A001 CAPABILITY"
"dev2" is using the command identifier format prior to me changing it in
On Mon, 23 May 2016, andreas graeper wrote:
> i try to send emails and get 252 as response to vrfy. then quit is sent and
> curl_easy_perform() returns CURLE_OK is there a way to avoid vrfy or not to
> stop when receiving 252. why perform returns OK when message actually has
> not been sent ?
On Thu, 19 May 2016, Jan Ehrhardt wrote:
> A little bit later in the process I am running into this error:
>
> C:\php-sdk\curl-src\lib\vauth\vauth.c : fatal error C1083: Cannot open
> compiler generated file:
>
On Tue, 5 Apr 2016, Patrick Seiter wrote:
> After many Google searches and many attempts at building, I am
> officially flummoxed trying to build 64-bit libcurl for Windows. I
> finished the code for my project months ago, but I need to distribute
> both 32 and 64-bit copies for release.
Dear team,
I have started to push my long awaited "vauth" reorganisation of the
authentication code that I started well over a year ago, continued last autumn
and finally finished off this month.
In summary, this change moves the built-in, Windows SSPI based, and GSS-API
based authentication
On Wed, 23 Mar 2016, Isaac Boukris wrote:
> When libcurl is used in server-side application which runs transfers
> on behalf of different users, it would be useful to be able to specify
> different Kerberos credential-cache for each transfer.
Okay - Although I wrote the SASL Kerberos integration
Hi Team,
Over the last couple of years I've been slowly getting on top of the build
warnings that are flagged up from our various autobuilds... and during the last
week or so I have picked that work up as I slowing get back into curl related
development ;-)
However, I see that the Solaris
On Thu, 10 Mar 2016, Henri Hein wrote:
> I forked the curl sources and implemented CURLOPT_SSL_CTX_FUNCTION for
> the SSPI/Schannel build. Would there be any interest in a pull
> request for this? It's just a few lines of code that I took from the
> cyassl source. For my purposes, I needed
On Wed, 2 Dec 2015, Kamil Dudka wrote:
> Tests 842, 843, 844, 845, 887, 888, 889, 890, 946, 947, 948, and 949 fail if
> a custom port number is specified by the -b option of runtests.pl. Is this
> expected?
Cheers - I thought they would but I wasn't sure how to overcome this :(
> If so,
On Wed, 1 Jul 2015, John E. Malmberg wrote:
I have built binary install kits for VMS, can the download page be
updated with the new links? Thanks for the builds and sorry I've been away
from my curl duties for the last few months - I'm just starting to get back
into things again and as
On Thu, 26 Feb 2015, Tatsuhiro Tsujikawa wrote:
As an effort to improve error handling of http2 code...
Many thanks - pushed as commit 48b5374e65.
Kind Regards
Steve
---
List admin: http://cool.haxx.se/list/listinfo/curl-library
On Wed, 25 Feb 2015, Daniel Stenberg wrote:
You all know how I (and some of you) have insisted that people should
not do pull request on github and instead post them here for review etc.
I'm slowly beginning to realize that I'm fighting an uphill battle that I
will lose.
I believe pull
On Wed, 25 Feb 2015, bch wrote:
I'm trying to add CURLINFO_NEGOTIATED_SSL (string) and
my test builds are failing on doc generation
I appreciate you've not submitted your patch yet but I just wanted to note down
some of my own thoughts whilst it is fresh in my head so my apologies if I am
On Wed, 25 Feb 2015, Jonathan C. wrote:
So I take it the fix in the pull request fixes the problem for you?
It does. In reality I just saw the pull request after you posted the
release notes.
I have now commented on the bug report and await feedback from Grant (The
author of the report and
On Tue, 17 Feb 2015, Wenlong Dong wrote:
* I'd rather support this across all of our mechanisms that use
a SPN (such as Socks 5, SPNEGO, Kerberos, Digest) in each of
the GSS-API, SSPI and Native implementations
* Possibly deprecate CURLOPT_SOCKS5_GSSAPI_SERVICE (I
would suggest a new
On Tue, 17 Feb 2015, Steve Holme wrote:
As you have found out it isn't too hard to do this. However,
* I'd rather support this across all of the server name authentication
mechanisms
* Possibly deprecate CURLOPT_SOCKS5_GSSAPI_SERVICE
* The code hasn't also changed quite a bit since v7.36
On Tue, 17 Feb 2015, Wenlong Dong wrote:
I investigated this further and could not find out a good way
to set the service identiy/name.
Unfortunately there isn't at the moment - not at least for the HTTP or SASL
based protocols.
The closest we have to it at the moment is
On Sat, 14 Feb 2015, Alessandro Ghedini wrote:
Just a small fix for the --cert-status description in the manpage.
Many thanks - now pushed.
Kind Regards
Steve
---
List admin: http://cool.haxx.se/list/listinfo/curl-library
On Tue, 10 Feb 2015, Alessandro Ghedini wrote:
Over the weekend I came to build curl on Centos and found that it
didn't build against the build in version of OpenSSL (v0.9.8b) :(
I appreciate this is a fairly old version but given we support 0.9.7+
(according to our docs) I decided to
On Mon, 9 Feb 2015, Isaac Boukris wrote:
From my knowledge in this area that doesn't seem quite right and if we
can save an extra round trip, and it is valid to do so, then great ;-)
It works well in my tests and according to RFC 4559 (SPNEGO) it should be
perfectly valid.
It seems
On Tue, 10 Feb 2015, Daniel Stenberg wrote:
I was wondering should I be using HAVE_BORINGSSL or
OPENSSL_IS_BORINGSSL in some of my pre-processor checks -
or doesn't that matter?
That's not a big difference in reality:
Cheers for the clarification Daniel - much appreciated.
-
On Mon, 9 Feb 2015, GitHub wrote:
openssl: Disable OCSP in old versions of OpenSSL
Versions of OpenSSL prior to v0.9.8h do not support the necessary
functions for OCSP stapling.
As most of you know... I am predominately a Windows developer - although I do
have a CentOS 5 VM that I use for
On Sun, 8 Feb 2015, Isaac Boukris wrote:
When the app sets CURLOPT_HTTPAUTH to CURLAUTH_NEGOTIATE
(e.g. using curl --negotiate) it first sends an empty request and receives
a 401 unauthorized before invoking GSS-API to the 'Negotiate
Authorization' header.
Thank you for your email and
On Tue, 3 Feb 2015, Daniel Stenberg wrote:
Still, the claim was correct (even if those files are not built/used in
many build configurations) and I intend to replace the implementations
with two free ones that have no RSA copyrights.
Cool...
Slightly related but do you also know of any free
On Mon, 2 Feb 2015, Paul Broadhead wrote:
The seg fault occurs because by the time the code dump function is
called, the config-current pointer is null as all the configurations have
been executed.
Which version of curl are you using as my pointer is valid in the latest code?
Daniel fixed a
On Mon, 2 Feb 2015, Paul Broadhead wrote:
If the outfile for the --libcurl option cannot be created, curl seg faults:
curl http://www.google.com --libcurl test/c
Please find a very simple patch attached.
Thank you for your patch Paul - however, I would be interested to know why
On Tue, 27 Jan 2015, GitHub wrote:
sasl: implement EXTERNAL authentication mechanism.
Many thanks for adding this and for knocking another TODO off the list ;-)
I have often thought about adding this myself as I believed it was relatively
easy to do, due to the authentication identifier
On Wed, 28 Jan 2015, Patrick Monnerat wrote:
* Do we need to limit this to TLS upgraded sessions - the examples
in the RFC seem to use this as the EXTERNAL authentication
mechanism?
No, we should not: the spec tells this is not limited to TLS.
I must have missed that :(
Some other
On Wed, 28 Jan 2015, Mariusz Gogulski wrote:
Every time I try to send an E-Mail first command sent after authentication
is HELP
This happens if the recipient list is empty or upload has not been set to true.
recipients = curl_slist_append(recipients, TO);
recipients =
On Fri, 2 Jan 2015, Steve Holme wrote:
However, I have just converted the Java code that is given as an example
on the above website into C, and tested it with SMTP (against my Exchange
Server) and SMB and all appears to be good as well. I have debugged the
code to make sure that the parity
On Thu, 22 Jan 2015, Daniel Stenberg wrote:
Is it the DES_set_odd_parity() function that BoringSSL doesn't have?
If so, I have written our own parity function based off of the Java
code over at:
Yes. It doesn't have that function and it modified the API for DES_set_key()
so we'd need
On Mon, 26 Jan 2015, John E. Malmberg wrote:
The lib/vtls/openssl.c verifystatus() can not be compiled using
OpenSSL builds that define the macro OPENSSL_NO_TLSEXT in
opensslconf.h.
I've just pushed commit a268a804b7 which hopefully fixes it. I tried to compile
OpenSSL here with 'no-tlsext'
On Mon, 26 Jan 2015, Brad Spencer wrote:
It seems that the HTTP_ONLY macro in curl_setup.h didn't learn
about the new SMB/CIFS support and thus doesn't disable it.
Attached is a tiny patch against 7.40.0 to make it do this.
Many thanks - I've turned this into a git patch against the latest
On Thu, 22 Jan 2015, Daniel Stenberg wrote:
You'll see that I modified your patch slightly to make it smaller and use the
#define to empty-macros approach just to avoid #ifdefs within code a little
more.
BoringSSL has an incompatible DES API with missing functions. It doesn't seem
to have
On Fri, 16 Jan 2015, John E. Malmberg wrote:
Can you check whether commit bb12d44471 fixes the issue for you
please?
... and commit a2f8887b79.
I copied curl_endian.c over the 7.40 source download and successfully
built curl.
Cool - thank you.
I noticed earlier that another
On Sun, 18 Jan 2015, John E. Malmberg wrote:
This is what I had to add for VAX to compile lib/curl_ntlm_core.c
for the daily build back in the November/December time frame
where I submitted the patch.
I have not checked if it is still needed for 7.40.0.
My attempt to fix NTLM by falling
On Sun, 18 Jan 2015, John E. Malmberg wrote:
I tried to find all the instances and fix them for the last release,
as I realised I had broken non 64-bit compiler builds, but as I don't
such a compiler myself I unfortunately missed some :(
Which file did you notice this in as I'd like
On Thu, 15 Jan 2015, John E. Malmberg wrote:
Some curl modules including lib/curl_endian.c are using 64 bit
integers with out checking to curl_config.h to see if they are available.
That's a bug we should fix. We should still build and run on 32-bit only
systems. Can you paste us some
Quanah Gibson-Mount
Unfortunately, it appears that curl is still not tested against Heimdal
Kerberos.
7.40.0 fails to build unless the following patch is applied:
Does commit 5c0e66d632.fix the problem as described in:
http://curl.haxx.se/bug/view.cgi?id=1469
Kind Regards
Steve
On Fri, 16 Jan 2015, Steve Holme wrote:
Can you check whether commit bb12d44471 fixes the issue for you
please?
... and commit a2f8887b79.
Kind Regards
Steve
---
List admin: http
On Sat, 3 Janc 2015, Sam wrote:
I forgot to mention in my previous email that whilst I'm happy
with the patch, the pending version of 7.40.0 is hopefully only
a few days away, so I'll push this after release.
Thanks, Steve.
Pushed as commit 659d252b6f.
Thanks again
Steve
On Sun, 4 Jan 2015, Steve Holme wrote:
Option 2: The more involved approach
This can be broken down into three parts:
[cut]
C) curl outputs the resulting data incorrectly
s u p p o r t e d S A S: GSSAPI
s u p p o r t e d S A S: GSS-SPNEGO
s u p p o r t e d S A S
On Mon, 5 Jan 2015, Marc Hörsken wrote:
Do we have any strategy to resolve such issues on x64 /
64-bit builds?
Yes - to fix 'em ;-)
In all seriousness, I've not looked at these particular issues yet - I've been
trying to minimise the warnings in the main curl and libcurl source code and
Hiya Marc,
On Mon, 5 Jan 2015, Marc Hörsken wrote:
Yes - to fix 'em ;-)
okay, so I will just go ahead and try to fix some of them one after
another. ;-)
If we can - I think it would be worth it.
If we are doing things like int... or long len = strlen(string); then we
should be using the
On Sun, 4 Jan 2015, Sergei Nikulov wrote:
Since nobody objects, could you please merge my changes?
Apologies for being a little quiet myself...
I think a lot of people have been on holiday over the seasonal period
unfortunately and whilst Václav checked your patch, for me, a build test wasn't
Dear friends,
Back in August Gisle raised an issue that our ldap module (ldap.c) when
compiled under Windows with Unicode had compilation warnings:
http://curl.haxx.se/mail/lib-2014-08/0066.html
At the time I proposed a fix, which fixed the warnings, but we weren't sure
if this patch was needed
Dear friends,
On Tue, 16 Dec 2014, Steve Holme wrote:
The ideas I've had so far involve extending the existing --crlf
option but I hope to be able to post more on my ideas when
I have a little bit more time towards the end of the week.
I've not forgotten about this...
As the release
On Tue, 30 Dec 2014, Steve Holme wrote:
The other adds support for linking against c-ares, and enabling its
use through the USE_ARES symbol definition.
This patch looks pretty good to me.
I forgot to mention in my previous email that whilst I'm happy with the patch,
the pending version
Dear friends,
This is something Bill Nagel raised with my during the SMB development and
not something I have had chance to look at really until now...
The non-OpenSSL encryption routines in curl_ntlm_core.c - setup_des_key()
and encrypt_des() don't appear to be applying the odd parity that is
On Tue, 30 Dec 2014, Sam wrote:
I'm submitting the attached patches for consideration, which I
have used for my own build. I am building on Windows 8, using
nmake from the developer console supplied with Visual Studio
2013 Express.
Thank you for your submission and work on this.
One
On Tue, 30 Dec 2014, Sam wrote:
What version of OpenSSL are you using and what commands
did you use to build OpenSSL?
I am using OpenSSL 1.01j. I actually did not build it, but rather took
the lazy shortcut and downloaded binaries from
On Mon, 29 Dec 2014, Sergei Nikulov wrote:
Could you please review and integrate?
I took a brief look at the patch but unfortunately, like the other
administrators here, I'm not an expert in cmake :(
If any of the other cmake users, are able to take a look and give the patch a
thumbs up then
On Sun, 28 Dec 2014, Gisle Vanem wrote:
'-lgdi32' must come after the libs using it. So:
-L/usr/local/ssl/lib ../lib/.libs/libcurl.a -lssl -lcrypto -lgdi32 -lws2_32
should work. No idea why that isn't done already.
I'm certainly no configure expert, and don’t run MinGW either, but looking
On Sun, 28 Dec 2014, Félix Robles wrote:
This is out of my area of expertise, but I've tried option a) and it
doesn't seem to solve it. I mean, with that -lgdi32 still shows up
before -lssl -lcrypto . So unfortunately I still have the same problem.
Are you working with a download of the curl
On Mon, 22 Dec 2014, Daniel Stenberg wrote:
I intend to otherwise keep the set dates for future releases though,
which will make our feature window following 7.40.0 roughly one
week shorter than normally. The feature window for post-7.40.0
will close on January 28th as per the release
On Thu, 18 Dec 2014, Patrick Monnerat wrote:
It looks like the Guenter' s Android and Tor's AIX and Tru64 auto
builds have been broken since this commit:
if2ip.c:194: error: too few arguments to function 'Curl_if2ip'
Should be fixed now:
The last couple of Android auto builds have been
On Wed, 17 Dec 2014, Patrick Monnerat wrote:
I just applied the fix to https://sourceforge.net/p/curl/bugs/1449/
but I have no permission to close the bug report...
May somebody who has this permission will do it please? Thanks.
I was able to access SF on my phone whilst on the train home
On Tue, 16 Dec 2014, GitHub wrote:
There was a confusion between these: this commit tries to disambiguate
them.
It looks like the Guenter' s Android and Tor's AIX and Tru64 auto builds have
been broken since this commit:
if2ip.c:194: error: too few arguments to function 'Curl_if2ip'
It
On Mon, 15 Dec 2014, Patrick Monnerat wrote:
What do we do ?
As there are only two weeks until release I think we should:
* Hold off on automatic conversion until after the release of 7.40.0 -
this gives others time to contribute and assist in the debate about
whether this should or
everyone - it's quite an achievement when you consider it’s the most
for 10 years ;-)
Steve Holme authored over half of them at about 132.
...and I see from the stats today that yesterday saw my 365th active day - a
whole year of active commits!!
Kind Regards
Steve
Hi everyone,
Somewhere between commit 91669584cf and cedf996073 test 1235 started failing
:(
This can be seen in most of the auto builds that run this test:
Guenter's OpenSuSE builds
Daniel's OS/X builds
Some of Marc's Win32 builds
Tor's Tru64, Solaris and Aix builds
...anyway you get the idea
On Mon, 15 Dec 2014, Daniel Stenberg wrote:
I guess it's something to do with the tool_urlglob.c changes but at
this time of night I can't figure out the issue so could be looking in
the wrong place :(
Thanks for your heads up, Steve.
No problem - sorry I couldn't see what the issue
On Mon, 15 Dec 2014, Steve Holme wrote:
I'll work on a fix.
Many thanks - and at this time of night.
I see from the auto builds that have run since - that this test now runs again
successfully.
Kind Regards
Steve
---
List
On Tue, 16 Dec 2014, Michael Wood wrote:
- An additional empty mail bug (currently transmitted as an empty line)
fixed.
I wasn't aware of an issue here either.
Well, there's a CRLF after the DATA command :)
I hadn't thought of it like that ;-)
What do we do ?
I think that if
On Fri, 12 Dec 2014, Patrick Monnerat wrote:
However, I think that the topic of whether non CRLF line ending
conversion should be performed automatically by curl or not for
certain protocols whilst related to the bug report is a different
conversation and one that I think should be
On Fri, 12 Dec 2014, Patrick Monnerat wrote:
I have worked on my side too for a much global solution, but I
have a clash now you've committed :-/
I'm guessing from what you've just said about the clash and from your previous
email that you've performed this in smtp.c. I think we should take a
On Sun, 14 Dec 2014, Marc Hoersken wrote:
would someone who has been working on SMB mind taking a look
at the following warning for line 320 in smb.c while building for
Windows 64-bit using VS2012:
That was me that implemented that to fix an issue with large file transfers.
warning C6297:
On Sun, 14 Dec 2014, Marc Hoersken wrote:
Is there anything I can enable in the generated project files to see what
you're seeing?
I used the code analysis feature of Visual Studio Premium 2012 and ran it
against the whole solution.
Ah - I'm not using the Premium version :(
I read the
On Sun, 14 Dec 2014, Marc Hoersken wrote:
Are you able to try it using the code analysis feature - please - to
see if you still get the warning?
Yep, just applied this small change and it looks good. The warning is
gone using the code analysis.
Cheers Marc - committed and pushed.
Kind
On Fri, 12 Dec 2014, Patrick Monnerat wrote:
A very quick comment as I'm quite busy this afternoon and just saw your
email:
I haven't been able to reproduce any other problems around b) now
that the fixes for a) are present, but the user has, and for that reason
I re-opened the bug report
On Fri, 12 Dec 2014, Patrick Monnerat wrote:
I've reproduced it: please find the mail data in attachment.
However I don't believe that was the user's issue - I understand he
was using my fix and specifying --crlf / CURLOPT_CRLF but was still
getting problems :(
Got it: the state is not
On Sat, 29 Nov 2014, Steve Holme wrote:
I think we (and I will need to double check this) have a breakage in the
ntlm code with write64_le() which is similar as is left over from the
NTLMv2 work from early this year. I have been meaning to check this
out and disable NTLMv2 if that is the case
On Thu, 11 Dec 2014, Patrick Monnerat wrote:
I'm about to commit a fix for SF bug 1456, but first, I request your
opinion.
Please note there are two bugs listed in this bug report:
a) That curl doesn't handle LF to CRLF conversion
b) That dot stuffing doesn't work
The fixes I pushed for a)
On Mon, 1 Dec 2014, Patrick Monnerat wrote:
Please find a big patch in attachment.
My... That is a big patch :-/
Are you able to split it up into more manageable / bisect'able chunks?
It factorizes most of the SASL code in IMAP, POP3 and SMTP into its
own state machine. This reduces the
On Sat, 29 Nov 2014, Daniel Stenberg wrote:
At the minimum I need to typedef a 64-bit int.
Right now the code seems to assume that we have long
long _or_ an __int64 type.
First, if that is really what you want I think you should have
a local typedef or something to avoid a series of
On Mon, 24 Nov 2014, Nagel, Bill wrote:
At the minimum I need to typedef a 64-bit int.
Ah yes - We can probably do something with:
#if defined(HAVE_LONGLONG)
Like in curl_ntlm_core.c:407 but it depends on how many 64-bit values there are
- which could make the code quite messy :(
I can
On Wed, 19 Nov 2014, Peter Wu wrote:
Based on recent configure patches:
eda919f configure: Added krb5 to the supported features
f0d860d configure: Fixed NTLM missing from features when CURL_DISABLE_HTTP
defined
fe0f896 configure: assume krb5 when gss-api works
676d62f
On Tue, 18 Nov 2014, Daniel Stenberg wrote:
Thanks! I pushed this now with a slightly modified commit message.
I've pushed a follow up commit (34cb17b930) to fix up the infof() type
specifiers as we were discussing ;-)
Kind Regards
Steve
On Tue, 18 Nov 2014, Daniel Stenberg wrote:
Attached a new patch. I went ahead and also fixed this test in
curl_multi_remove_handle and then that whole function by removing the
silly pipeline test and fixing easy_owns_conn, as mentioned on IRC;
that part then fixes the correct closing
On Mon, 17 Nov 2014, Brad King wrote:
+1
This just updates the CMake logic to match what configure is now doing.
Please note that the supported features string needs to be Kerberos and not
krb5 following the changes I pushed yesterday.
Kind Regards
Steve
Dear friends,
As some of you are aware krb4 support was dropped from curl and libcurl in
7.33.
However, there have been a few references to this feature left around either
in source code or documentation - some of which I have been cleaning out or
marking as deprecated recently.
There is one
On Sat, 15 Nov 2014, Dan Fandrich wrote:
I have prepared a patch to remove this (see attached), however, from
reading the libcurl code (security.c) and associated comments it seems
more of a generic Kerberos option. Does anyone know if it is used
for Kerberos 5 at all?
I don't know
On Sat, 15 Nov 2014, Dan Fandrich wrote:
From a curl command line point of view my patch really doesn't do anything
different as the current code checks for the presence of
CURL_VERSION_KERBEROS4 which won't be there (when = 7.33.0 ).
The difference is curl aborting because of an unknown
On Tue, 11 Nov 2011, Nagel, Bill wrote:
However, and this is more for my own curiosity, but I couldn’t find
any mention of it in the manpages :(
I'm not sure if it in the docs, it just something I've noticed.
No problem.
I don't want to sound funny about this, but you might prefer to
On Sat, 15 Nov 2014, Michael Osipov wrote:
I have prepared a patch to remove this (see attached), however, from
reading the libcurl code (security.c) and associated comments it seems
more of a generic Kerberos option. Does anyone know if it is used
for Kerberos 5 at all?
It isn't,
On Sat, 15 Nov 2014, Dan Fandrich wrote:
I though you were removing support of the option from the curl tool, in which
case it
work abort with curl: option --krb: is unknown.
Ultimately I was trying to determine if this option is used and whether I need
to support it in the SASL Kerberos 5
On Tue, 4 Oct 2011, Carlo Wood wrote:
'connection_id' is a 'long', not an 'int', needs a '%ld' format
specifier.
True, and num_connections is a size_t which is an unsigned long.
As I'm sure you're aware a size_t is 32-bits on x86 platforms and 64-bits on
x64, however, a long is always
On Sun, 9 Nov 2011, Steve Holme wrote:
On Tue, 4 Oct 2011, Carlo Wood wrote:
You'd think by now I would have learnt to update the dates :(
S.
---
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http
On Sun, 9 Nov 2011, Carlo Wood wrote:
Attached updated patch enclosed.
I can't open this anyone in my mailer, so now I can't reply to it with
quotes from the patch :p
Odd :(
Now we have identified a problem of only enclosing attachments and not
performing inline patches :-P
Can you
On Sun, 9 Nov 2011, Carlo Wood wrote:
Now we have identified a problem of only enclosing attachments and not
performing inline patches :-P
I can now... opening it an xterm with 'less'.
Woosh - that's gone completely over my head =-/
Ah ok - I added that in the other patches (all being
On Mon, 6 Oct 2014, Steve Holme wrote:
Thank you for splitting the patch up.
My fullest of apologies for not getting back to you sooner - as you're probably
seen it has been a hectic few weeks here getting the 7.39.0 release out and
starting to push my next batch of changes / additions
On Fri, 7 Nov 2014, Tural Ismayilzade wrote:
Please don't top post - I appreciate you may be new to the mailing list but
please see the mailing list etiquette link at the bottom of this email.
yes QUIT command is sent.
Weird - Are you able to debug your libcurl as something isn't quite right?
On Fri, 7 Nov 2014, Brad King wrote:
Here is a patch series to fix it.
Many thanks for your efforts on this - it is much appreciate especially as our
cmake builds have lacked in functionality for quite a while now.
I'm sure Daniel will review this along with Peter's recent changes however I
1 - 100 of 644 matches
Mail list logo