Tag Archives: cURL and libcurl

cURL and libcurl, Open Source

Code re-use is fun

Back in 2003 I wrote up support for the HTTP NTLM authentication method for libcurl. Happy with my achievement, I later that year donated a GPL licensed version of my code to the Wget project (which also was my first contact with the signed paper stuff with the GNU/FSF to waive my copyright claims and instead hand them over). What was perhaps not so amusing with this code was when both curl and Wget 2005 were discovered to have the same security flaw due to my mistakes in this code shared by both projects!

Just recently, the neon project seems to be interested in taking on the version I adjusted somewhat for them, so possibly the third HTTP code is soon using this. Yeah I posted it on their mailing list back then so it has been sitting there in the archives maturing for some 6 years by now…

I also happened to fall over the SSH Tunnel Creator tool, which I’ve never used myself, that apparently snatched my neon donation (quite according to what the license allowed of course) and used it in their tool to do NTLM!

It’s actually not until recent years I discovered libntlm, and while I don’t know how good it was back in the days when I wrote my first NTLM stuff I generally think using existing libs is the better idea…

cURL and libcurl, Network, Open Source

murl for extended curlness

1 Comment

I’m a firm believer in the old unix mantra of letting each tool do its job and do it well, and pass on the rest of the work to the next tool. I’ve always stated that curl should remain this way and that it should remain within its defined walls and not try to do everything.

But time passes and more and more ideas are thrown up in the air, or in some cases directly at me, and the list of things that we could do but don’t due to this philosophical limit of remaining focused has grown. It currently includes at least:

  • metalink support
  • recursive HTML downloads
  • recursive/wildcard FTP transfers
  • bittorrent support
  • automatic proxy configuration
  • simultaneous/parallel download support

Educated readers of course immediately detect that this list (if implemented) would make a tool that basically does what wget already does (and a lot more) and I’ve explicitly said for a decade that curl is not a wget clone. Maybe it is time for us (me?) to reevaluate that sentiment – at least in some sense.

I don’t want to sacrifice the concepts that have worked so fine for curl under so many years, so I’m still firmly against stuffing all this into curl (or libcurl). That simply will not happen with me at the wheel.

A much more interesting alternative would be to instead start working on a second tool within the curl project: murl. A tool that does basically everything that curl already does, but also opens the doors for adding just about everything else we can cram in and that is still related to data transfers. That would include, but not be restricted to, all the fancy stuff mentioned in the list above!

No the name murl is not set in stone, nor is this whole idea anything but plain and early thoughts thrown out at this point so it may or may not actually take off. It will probably depend on if I get support and help from fellow hackers to get started and moving along.

cURL

cURL and libcurl, Security

curl 7.19.4

curl and libcurl 7.19.4 has just been released! This time I think the perhaps most notable fix is the CVS-2009-0037 security fix which this release addresses. A little over 600 days passed since the previous vulnerability was announced.

Other than that major event, there are a bunch of interesting changes in this release:

  • Added CURLOPT_NOPROXY and the corresponding –noproxy
  • the OpenSSL-specific code disables TICKET (rfc5077) which is enabled by default in openssl 0.9.8j
  • Added CURLOPT_TFTP_BLKSIZE
  • Added CURLOPT_SOCKS5_GSSAPI_SERVICE and CURLOPT_SOCKS5_GSSAPI_NEC – with the corresponding curl options –socks5-gssapi-service and –socks5-gssapi-nec
  • Improved IPv6 support when built with with c-ares >= 1.6.1
  • Added CURLPROXY_HTTP_1_0 and –proxy1.0
  • Added docs/libcurl/symbols-in-versions
  • Added CURLINFO_CONDITION_UNMET
  • Added support for Digest and NTLM authentication using GnuTLS
  • CURLOPT_FTP_CREATE_MISSING_DIRS can now be set to 2 to retry the CWD even when MKD fails
  • GnuTLS initing moved to curl_global_init()
  • Added CURLOPT_REDIR_PROTOCOLS and CURLOPT_PROTOCOLS

We also did at least 15 documented bugfixes in this release and 25 people are credited for their help to make it happen.

cURL and libcurl

Saying lib out loud

9 Comments

Not being a native English speaker, I’ve always pronounced libcurl with a ‘lib’ part as if it was part of ‘liberty’, and ‘curl’ with a K sound and ending with ‘earl’. I don’t know of any Swedes who would not pronounce ‘lib’ like that, but when speaking Swedish we’re of course highly influenced by other things so it’s not really relevant.

It wasn’t until I got on FLOSS Weekly that I fully realized that some English speakers would actually pronounce the ‘lib’ part as the first syllable of ‘library’ and that does make sense considering lib is short for library.

But libcurl is just a smaller player here. How do you English speakers pronounce libc? libxml? libgcc?

And yes, this is another one of those really important issues in life. Almost as important as how to close parenthetical expressions with emoticons!


Open Source

Open source personal

I participate in a range of different open source projects. Of course I spend more time on some of them and only a very little time in most of them, but I’m currently listed as member of 18 projects on sourceforge and 16 on ohloh and I can easily figure out a bunch more than aren’t listed on either of those sites.

I’m just the kind of guy who tend to actually get the code and write up a patch for problems, and in fact also in many cases I’ll write an fresh application and publish it openly for the world (not that my typical programs get any particularly large audience but still). I’m not saying everyone has to be like this, I’m just describing me here.

It seems this is a troublesome concept for people to grasp.

I get a large amount of private mail where people talk about “your project” (as in a single one that I am supposed to understand which one they’re referring to) and just about all open source-related interview/questionnaire things I’ve filled in tend to assume My One Single Project. In the first case I can often guess which one they refer to by the phrasing of the mail, and in the second case I tend to answer for the project I’m involved the most in.

So I get this feed of private emails on projects I participate in, but I don’t like private emails about open source projects when people request and expect free support and help. If they want free support, I expect the people to post the questions publicly and open to allow others to reply and read both the question and the subsequent answer online, right there at the time they’re asked but also much later when searching for help on the same subject as then the answers will be around in mailing list archives etc.

These days I have a blanket reply form that I bounce back when I get private support mails and I will admit that most people respect that after having been told about the situation. Every now and then of course I get a violent refusal for sympathy and instead I get to learn I’m an arrogant bastard. This is also related to the fact that:

We (Haxx) run and offer commercial support around curl and libcurl, and for that purpose we have a dedicated support email address. Mail there if you’re willing to pay for support. That’s actually quite clearly spelled out everywhere where that address is displayed, but yet people seem to find that a good place to mail random questions and bug reports. Just today I got a very upset mail response after I mentioned the “paid support” part of the deal there expecting us (me?) to instantly fix bugs regardless since I’ve been told about them per email…

All in all, I’m not really complaining since I’m generally getting along fine with everyone and stuff around this.

Just everyone try to keep things apart: the projects, the people and the companies. They’re sometimes intertwined but sometimes not.

cURL and libcurl, Development

Some stats on curl development

Counting curl 6.0 and up to curl 7.19.3 we’ve done 78 releases during the 9.4 years it took.

In this time, we’ve mentioned 1259 bugfixes and 389 notable changes.

This makes one bugfix done every 2.7 days. One release done every 43rd day with an average of 16 bugfixes done in each. The longest interval ever between two curl releases was 139 days, back in 2000 when we worked to release the first version 7 release (known as 7.1).

To compare with how our work has been more recently, doing the same math limited to the 20 latest releases only (the 3.3 years since and including 7.15.0) shows that we’re still on 2.7 days per bugfix (although we know that the code base has grown steadily for years) but we’re now on 61 days between releases and 21 bugfixes/release…

All this info and more will be visible on a web page on the curl site soonish, I’m still working on polishing it up.

What other useful or useless but interesting numbers could be extracted from this?

cURL and libcurl

curl 7.19.3

I just now sent away the announcement of curl and libcurl 7.19.3. With some 30 bugfixes and only two actual changes I hope this will again be a solid release that’ll be appreciated and used all over.

The changes are:

  • CURLAUTH_DIGEST_IE bit added for CURLOPT_HTTPAUTH and CURLOPT_PROXYAUTH – as older Internet Explorers have an “interesting” take at the Digest authentication and servers that speak that dialect doesn’t like libcurl’s regular way
  • VC9 Makefiles were added to the release package, for the VS2008 users of the world

Download here.

cURL and libcurl, Linux, Security

Linux distros consolidate crypto libs

For a while already, the Fedora distribution has fought battles, done lots of work and pushed for a consolidation of all packages that use crypto libs to completely go with Mozilla’s NSS.

Now it seems to be OpenSUSE’s turn. The discussion I link to here doesn’t make any definite conclusions but they seem to lean towards NSS as well, claiming it has the most features. I wonder what they base that statement on – if there’s a public doc anywhere that state exactly which has what that makes any contender better than any other for them?

In the Fedora case it seems they’ve focused on the NSS FIPS license as the deciding factor but the license issue is also often brought up in this discussion.

I’ve personally been pondering on writing some kind of unified crypto layer that would expose a single API to an application and handle the different libs as backends, pretty much the same way we do it internally in libcurl at the moment. It hasn’t taken off (or even been started) since I’ve not had the time nor energy for it yet.