We may not get a very warm and sunny summer this year in Sweden, but now at least we have the Haxx towels to use the very brief moments on the beach! It measures 140 x 70 centimeters and if you click on the image you’ll get a higher resolution version to browse.
I got this awesome curl sighting from the US101, near SFO posted to me (click for a slightly larger version) a few days ago – showing curl on a very large billboard in an ad for Dice.
It is clearly meant to look like a unix style command line that invokes curl. The command line would only be syntactically correct if the user truly has two host names named “techJobs” and “SanFran” and curl would attempt to get their root HTTP document off them on port 80.
It gets followed by that C++/C99 comment that really is an odd added context.
To me, all the sign shows is a company that desperately tries to look techy but in trying too hard it fails really miserably. I’m really honored my work found its way to such a high profile spot though!
Follow-up, September 11th:
Much to my surprise, today I received an email from Dice responding to my “critique” above. I have to say that this response was much more than I expected and I tip my hat to them for this response:
I’m the marketing director for Dice.com and I wanted to reach out to you to thank you for spotting our billboard error on the 101. We are deeply embarrassed by this mistake to say the least. In a classic coding scenario, our QA failed us. Unfortunately for us, we bought this spot long-term and we are trying to figure out how quickly we can replace the content.
We’ve been working this year to do a better job communicating in a more authentic way in our marketing efforts. Obviously, making a mistake like this makes it look pathetically inauthentic. At the end of the day, getting it wrong is inexcusable, particularly in such a visible way.
(photo by Stan van de Burgt)
For the readers of my blog, this is a copy of what I posted to the httpbis mailing list on July 12th 2012.
This is a response to the httpis call for expressions of interest
I am the project leader and maintainer of the curl project. We are the openÂ source project that makes libcurl, the transfer library and curl the commandÂ line tool. It is among many things a client-side implementation of HTTP andÂ HTTPS (and some dozen other application layer protocols). libcurl is veryÂ portable and there exist around 40 different bindings to libcurl for virtuallyÂ all languages/enviornments imaginable. We estimate we might have upwards 500
million users or so. We’re entirely voluntary driven without any paidÂ developers or particular company backing.
HTTP/1.1 problems I’d like to see adressed
Pipelining – I can see how something that better deals with increasingÂ bandwidths with stagnated RTT can improve the end users’ experience. It is notÂ easy to implement in a nice manner and provide in a library like ours.
Many connections – to avoid problems with pipelining and queueing on theÂ connections, many connections are used and and it seems like a general wasteÂ that can be improved.
We’ve implemented HTTP/1.1 and we intend to continue to implement any and allÂ widely deployed transport layer protocols for data transfers that appear onÂ the Internet. This includes HTTP/2.0 and similar related protocols.
curl has not yet implemented SPDY support, but fully intends to do so. TheÂ current plan is to provide SPDY support with the help of spindly, aÂ separate SPDY library project that I lead.
We’ve selected to support SPDY due to the momentum it has and the multipleÂ existing implementaions that A) have multi-company backing and B) prove it toÂ be a truly working concept. SPDY seems to address HTTP’s pipelining and many-connections problems in a decent way that appears to work in reality too. IÂ believe SPDY keeps enough HTTP paradigms to be easily upgraded to for mostÂ parties, and yet the ones who can’t or won’t can remain with HTTP/1.1 withoutÂ too much pain. Also, while Spindly is not production-ready, it has still givenÂ me the sense that implementing a SPDY protocol engine is not rocket scienceÂ and that the existing protocol specs are good.
By relying on external libs for protocol and implementation details, my hopesÂ is that we should be able to add support for other potentially comingÂ HTTP/2.0-ish protocols that gets deployed and used in the wild. In the curlÂ project we’re unfortunately rarely able to be very pro-active due to theÂ nature of our contributors, which tends to make us follow the rest andÂ implement and go with what others have already decided to go with.
I’m not aware of any competitors to SPDY that is deployed or used to anyÂ particular and notable extent on the public internet so therefore no otherÂ “HTTP/2.0 protocol” has been considered by us. The two biggest protocolÂ details people will keep mention that speak against SPDY is SSL and theÂ compression requirements, yet I like both of them.Â I intend to continue to participate in dicussions and technical arguments onÂ the ietf-http-wg mailing list on HTTP details for as long as I have time andÂ energy.
curl currently supports Basic, Digest, NTLM and Negotiate for both host andÂ proxy.
Similar to the HTTP protocol, we intend to support any widely adoptedÂ authentication protocols. The HOBA, SCRAM and Mutual auth suggestions all seemÂ perfectly doable and fine in my perspective.
However, if there’s no proper logout mechanism provided for HTTP auth I don’tÂ forsee any particular desire from browser vendor or web site creators to useÂ any of these just like they don’t use the older ones either to any significantÂ extent. And for automatic (non-browser) uses only, I’m not sure there’sÂ motivation enough to add new auth protocols to HTTP as at least historicallyÂ we seem to rarely be able to pull anything through that isn’t pushed for by atÂ least one of the major browsers.
The “updated HTTP auth” work should be kept outside of the HTTP/2.0 work asÂ far as possible and similar to how RFC2617 is separate from RFC2616 it shouldÂ be this time around too. The auth mechnism should not be too tightly knit toÂ the HTTP protocol.
The day we can clense connection-oriented authentications like NTLM from theÂ HTTP world will be a happy day, as it’s state awareness is a pain to deal withÂ in a generic HTTP library and code.
I’m a fan of static code analyzing. With the use of fancy scanner tools we can get detailed reports about source code mishaps and quite decently pinpoint what source code that is suspicious and may contain bugs. In the old days we used different lint versions but they were all annoying and very often just puked out far too many warnings and errors to be really useful.
Out of coincidence I ended up getting analyses done (by helpful volunteers) on the curl 7.26.0 source base with three different tools. An excellent opportunity for me to compare them all and to share the outcome and my insights of this with you, my friends. Perhaps I should add that the analyzed code base is 100% pure C89 compatible C code.
Some general observations
First out, each of the three tools detected several issues the other two didn’t spot. I would say this indicates that these tools still have a lot to improve and also that it actually is worth it to run multiple tools against the same source code for extra precaution.
Secondly, the libcurl source code has some known peculiarities that admittedly is hard for static analyzers to figure out and not alert with false positives. For example we have several macros that look like functions and on several platforms and build combinations they evaluate as nothing, which causes dead code to be generated. Another example is that we have several cases of vararg-style functions and these functions are documented to work in ways that the analyzers don’t always figure out (both clang-analyzer and Coverity show problems with these).
Thirdly, the same lesson we knew from the lint days is still true. Tools that generate too many false positives are really hard to work with since going through hundreds of issues that after analyses turn out to be nothing makes your eyes sore and your head hurt.
The first report I got was done with Fortify. I had heard about this commercial tool before but I had never seen any results from a run but now I did. The report I got was a PDF containing 629 pages listing 1924 possible issues among the 130,000 lines of code in the project.
Fortify claimed 843 possible buffer overflows. I quickly got bored trying to find even one that could lead to a problem. It turns out Fortify has a very short attention span and warns very easily on lots of places where a very quick glance by a human tells us there’s nothing to be worried about. Having hundreds and hundreds of these is really tedious and hard to work with.
If we’re kind we call them all false positives. But sometimes it is more than so, some of the alerts are plain bugs like when it warns on a buffer overflow on this line, warning that it may write beyond the buffer. All variables are ‘int’ and as we know sscanf() writes an integer to the passed in variable for each %d instance.
sscanf(ptr, "%d.%d.%d.%d", &int1, &int2, &int3, &int4);
I ended up finding and correcting two flaws detected with Fortify, both were cases where memory allocation failures weren’t handled properly.
Given the exact same code base, clang-analyzer reported 62 potential issues. clang is an awesome and free tool. It really stands out in the way it clearly and very descriptive explains exactly how the code is executed and which code paths that are selected when it reaches the passage is thinks might be problematic.
The reports from clang-analyzer are in HTML and there’s a single file for each issue and it generates a nice looking source code with embedded comments about which flow that was followed all the way down to the problem. A little snippet from a genuine issue in the curl code is shown in the screenshot I include above.
Given the exact same code base, Coverity detected and reported 118 issues. In this case I got the report from a friend as a text file, which I’m sure is just one output version. Similar to Fortify, this is a proprietary tool.
As you can see in the example screenshot, it does provide a rather fancy and descriptive analysis of the exact the code flow that leads to the problem it suggests exist in the code. The function referenced in this shot is a very large function with a state-machine featuring many states.
Out of the 118 issues, many of them were actually the same error but with different code paths leading to them. The report made me fix at least 4 accurate problems but they will probably silence over 20 warnings.
From this test of a single source base, I rank them in this order:
- Coverity – very accurate reports and few false positives
- clang-analyzer – awesome reports, missed slightly too many issues and reported slightly too many false positives
- Fortify – the good parts drown in all those hundreds of false positives
Whenever libcurl saves cookies to a file, it saves them in the old “Netscape cookie format”.
Since ages ago libcurl has written a comment at the top of that cookie file (the file we refer to as the cookie jar in curl lingo) that explains that it is a cookie netscape cookie file format and then a URL pointing to the original Netscape document describing what cookies are and how they work. To be perfectly honest, we pointed to a local copy of that document since the original is since long removed and gone and now only available through archive.org.
The web page pointed to were never a perfect match since the page never explained the file format or its use, only the cookie protocol – as it was originally described to work and not even like cookies works today.
Starting with curl 7.27.0, it will write the header to point to another URL: http://curl.haxx.se/docs/http-cookies.html
There are many, sorry very many, different SSL libraries today that various programs may want to use. In the open source world at least, it is more and more common that SSL (and other crypto) using programs offer build options to build with either at least OpenSSL or GnuTLS and very often they also offer optinal build with NSS and possibly a few other SSL libraries.
In the curl project we just added support for library number nine. In the libcurl source code we have an internal API that each SSL library backend must provide, and all the libcurl source code is internally using only that single and fixed API to do SSL and crypto operations without even knowing which backend library that is actually providing the functionality. I talked about libcurl’s internal SSL API before, and I asked about this on the libcurl list back in Feb 2011.
So, a common problem should be able to find a common solution. What if we fixed this in a way that would be possible for many projects to re-use? What if one project’s ability to select from 9 different provider libraries could be leveraged by others. A single SSL API with a simplified API but that still provides the functionality most “simple” SSL-using applications need?
Marc Hörsken and I have discussed this a bit, and pidgin/libpurble came up as a possible contender that could use such a single SSL. I’ve also talked about it with Claes Jakobsson and Magnus Hagander for postgresql and I know since before that wget certainly could use it. When I’ve performed my talks on the seven SSL libraries of libcurl I’ve been approached by several people who have expressed a desire in seeing such an externalized API, and I remember the guys from cyassl among those. I’m sure there will be a few other interested parities as well if this takes off.
What remains to be answered is if it is possible to make it reality in a decent way.
- will reduce code from the libcurl code base – in the amount of 10K or more lines of C code, and it should be a decreased amount of “own” code for all projects that would decide to use thins single SSL library
- will allow other projects to use one out of many SSL libraries, hopefully benefiting end users as a result
- should get more people involved in the code as more projects would use it, hopefully ending up in better tested and polished source code
There are several downsides with a unified library, from the angle of curl/libcurl and myself:
- it will undoubtedly lead to more code being added and implemented that curl/libcurl won’t need or use, thus grow the code base and the final binary
- the API of the unified library won’t be possible to be as tightly integrated with the libcurl internals as it is today, so there will be some added code and logic needed
- it will require that we produce a lot of documentation for all the functions and structs in the API which takes time and effort
- the above mention points will deduct time from my other projects (hopefully to benefit others, but still)
Some problems that would have to dealt with:
- how to deal with libraries that don’t provide functionality that the single SSL API does
- how to draw the line of what functionality to offer in the API, as the individual libraries will always provide richer and more complete APIs
- What is actually needed to get the work on this started for real? And if we do, what would we call the project…
PS, I know the term is more accurately “TLS” these days but somehow people (me included) seem to have gotten stuck with the word SSL to cover both SSL and TLS…