How to get "delivery failed" messages in your inbox...

I guess I deserve every one of them for being such a smart ass.

Date: Thu, 1 Nov 2007 10:07:57 -0300
From: William Lachance <wrlach@gmail.com>
To: Air Canada <confirmation@aircanada.com>
Subject: Re: Air Canada - Booking confirmation

On 10/31/07, Air Canada <confirmation@aircanada.com> wrote:
>
>
>
>  ****** PLEASE DO NOT REPLY TO THIS E-MAIL ******

Ok.

-- 
William Lachance
wrlach@gmail.com

Syndicated 2007-11-11 08:58:58 from Ginger tea and channa masala

On the proper use of assert

I just posted an article to advogato on the proper use of assertions. Perhaps I'm wrongheaded, but I truly believe that the software I use on a regular basis would be of much higher quality if people actually read and used the advice contained therein. If you want to comment, but don't have an advogato account, you may do so here.

Syndicated 2007-10-03 15:13:44 from Ginger tea and channa masala

Re: More on expensive gasoline

apenwarr: Your bit of economic theory is interesting, but I'm still pretty certain the key driver here is supply and demand, not price optimization. See, for example, the testimony by Paul Sankey before the U.S. congress on the subject: "Gouging is an Idiotic Explanation".

The facts are simple: domestic demand in the U.S. for gasoline (refined crude oil) is about 22 million barrels per day, while supply is only about 17 million barrels per day (the difference is made up with imports from overseas). Most of the blame for this expensive discrepancy can be placed on the difficulties currently experienced by the U.S. refining industry (extended maintenance, tighter product specifications, safety concerns), rather than some kind of deliberate conspiracy by an oil oligopoly to restrict supply and/or fix the price.

The marketplace for energy is simply too complex, with too many stakeholders, for it to be treated as a monopoly. If only they could, I'm sure those U.S. refineries would very much like to be processing and reselling those 5 million barrels of gasoline that are currently being imported (who wouldn't given the current high prices?). Why invoke conspiracy and collusion when an alternative, well-sourced explanation works just as well?

Syndicated 2007-09-04 18:48:24 from Ginger tea and channa masala

Re: Climate change and objectivity

apenwarr: The lack of informed discussion on Global Warming is frustrating. Even granting the fact that temperature has been increasing over the last few decades, I haven't yet heard a convincing explanation on why this is necessarily due to carbon emissions as opposed to any number of other things. It seems like a probable explanation (CO2 is a greenhouse gas, after all, and the amount of it in the atmosphere has increased very substantially), but you need more than correlation to prove causality. Perhaps there's a convincing scientific explanation out there, but I read all the way through The Weather Makers (allegedly one of the best books available on the subject for the layman) without getting any answers on this.

Regarding gasoline prices, as I understand it the recent surge in the price has more to do with lack of refinery capacity in the United States than anything else. The high prices you mention in the late 70s were due to OPEC's oil embargo. However, this isn't to say that we might not be creeping up to a peak in supply of crude oil. Most of the major exporting nations have already hit their production peak and global supply has been flat at about 85 million barrels per day since 2005. Hand-waving about economics will not make this issue go away.

Syndicated 2007-08-20 17:45:01 from Ginger tea and channa masala

In which I explain what this thing does...

After announcing Pathfinder a week or so ago, it occurred to me that most people might not know what it's good for (or at least the subtleties thereof). I certainly wouldn't have before I started working on this project, and the information on its more esoteric features is sort of dispersed across the Internet (if available at all). I figured I might as well try to help this situation (as well as Pathfinder's prospects for world domination?) by writing a bit about what it does and in what circumstances it might be useful.

Let's start at the beginning: certificates. An X.509 certificate is a token asserting identity (and various properties corresponding to that identity). At minimum, such a certificate contains an RSA public key, a subject name (who this certificate represents), and an authority name (who's vouching for the authenticity and/or trustworthiness of this certificate by signing it with its RSA key). That's really only the beginning though: an X.509 certificate can contain lots of other stuff corresponding to the identity of its holder: more on that later.

When an SSL connection is established (the most common example of this is connecting to a website over https in Mozilla or IE), these certificates are exchanged between server and client. In most software these days, only the client does any kind of validation of the certificate provided by the server: specifically, it will check the certificate to see that it signed by a certificate in a local "trusted" store (Mozilla and IE provide a trusted store composed of various certificate authorities by default). If so, we proceed with a Diffie-Hellman key exchange using the RSA keys in the client and server certificates and then proceed exchanging data. If not, well... that's up to the application. Web browsers usually pop up a warning that most people click through and ignore (an oft-discussed issue in usability circles: see here, for example).

Although uncommon, it is within the perogative of the server side of the connection to insist that the client provide a certificate when the connection is established, and to reject the client if this certificate is not within its trust store. This is the sort of thing you'd use if you're really paranoid about who you want to allow to (for example) connect to your super-secure web site.

When I talk about verifying signatures, I'm really referring to something broader called "path validation". That is to say, given a sequence of certificates 1..N (where 1 is ultimately trusted), is each certificate signed by the previous one? In the basic cases we've been talking about, there's only two certificates in the path under consideration, and we're only talking about verifying signatures. Validation can get much more complicated and paranoid than this, for those who have higher expectations regarding security. RFC3280 has all the details, but to name just a few things:

• Certificate revocation lists (CRLs): A certificate is supposed to provide a set of CRL distribution points, which tells you where to find a certificate revocation list which indicates (signed by the signer of the certificate) whether or not a certificate has been revoked. This gives you added confidence that a certificate hasn't been compromised.
• Chains of trust: A certificate may be signed by a CA certificate which is not in the trust store, but which is in turn signed by a CA certificate which is in the trust store. This information may be looked up by chasing the AIA (authority information access) field of the certificate which commonly points to an LDAP and/or HTTP URI.
• Bridged trust: Two certificate authorities can elect to cross-sign each other over a PKI bridge. This further reduces the extent to which it is necessary to ultimately trust CA certificates: you can just elect to trust the CA certificates in (for example) your organization, and the appropriate software can validate a path that goes from the client certificate to your CA through a series of "bridge" certificates (the trust in which can easily be revoked, if required).
• Policies constraints: You can insist that a certificate conform to certain user-defined policies in validation.

Needless to say, writing the code to do all of this correctly is rather difficult and, moreover, goes rather beyond the scope of a library like OpenSSL when it comes to chasing down CRL and chains of trust over the Internet. Pathfinder centralizes handling all of these things in a single daemon (accessible from the callback that libnss and OpenSSL use when initializing an SSL connection), making it easier to write and deploy software in a Linux/Unix environment which imposes the stricter requirements on certificate validity that I describe above. At least at first, I only expect it to be useful in certain niche cases with complicated requirements (most likely mail and web servers that are expected to traffic in sensitive information), but perhaps eventually we might see this sort of thing in wider deployment, making the Internet a safer place for everyone. One can dream, anyway...

Oh yeah, did I mention that Pathfinder uses D-Bus? Look: shiny thing!

Syndicated 2007-08-17 04:02:57 from Ginger tea and channa masala