Advantages of Open Source

Thinking retrospectively, I think I missed two things really important on my latest post, so this one is meant to fill the gap.

The good thing from the "bug hunt"

While I didn't like the bug hunt and even criticized it, there's a really good side on this, thanks to the Portuguese Ministry of Justice.

• They're trying to make their best, or at least it seems so. They didn't just spit out some silly website (I was tempted to have links for "silly website", but we had enough examples from Portugal in the last few weeks, so they're really not needed) that only works on IE or something like that. Even this issue - the site works on Mozilla browsers (SeaMonkey and Firefox) but those browsers aren't able to see the security certificate as a valid one, and they're trying to fix that. While this could be qualified as "just doing their job", unfortunately this care isn't common, so they' deserve some kudos from that.


• They're avoiding one slow bureocratic process of opening a public request, having people/companies wanting to do the job, choosing "the right one" and so on. Instead, they've seen an easier and better opportunity: since anyone can fiddle with the (open) code, they're just saying "Hey, there's this thing over here that would be really cool if someone did it. Why don't you have a try? If you make it we'll give you 1000 €!".

An advantage of Open Source

And the latest point leads me to another, perheaps the most important lesson to take out of this example: this is only possible because Mozilla's browsers are Open Source. See, since the code is open and freely available, anyone (at all!) is elegible to do the job - and that's great for every side: the Ministry of Justice can have their problem solved without having to contact some vendor and convince them that their piece of software does something that they don't like and have a virtually unlimited number of possible coders (if this was IE, for instance, do you think that anyone but Microsoft employees were to do the job?). Even Mozilla ends winning, because they don't have to do anything but reviewing a patch when the fix is done. Awsome, right?

It's scary the number of times I still get to hear stuff like "but are there any real companies betting/using Open Source software?"... It's not only a number that is rising, but finaly companies are starting to see the real power behind Open Source. Also, I remember talking with some Siemens' workers that said stuff like "yeah, we use Open Source stuff internally, but why do you think that they would let us contribute with bug fixes or enhancements? That would be giving our work to the other companies in the field!" What is missing here is that, even if you don't care a little bit about Open Source, there are lot's of advantages on contributing, and giving back. Let's get real - forking software is a pain in the ass. If you keep changing the original code and never merge stuff with the original branch, you'll end loosing endless hours of porting changes from the original branch into yourse, or, even worse, you'll stop looking into the original branch, which includes loosing lots of security or bug fixes, enhancements and new features. If you give back your changes, they're automaticly maintained - by the community. In other scenario, if you contribute fresh code (a new project, a new functionality, whatever) by releasing it in an Open Source model, you'll eventually get more users testing, helping, and enhancing your code. For free.

Well, this post is getting bigger than I wanted it to, so I'll shut up by now and have some sleep ;-)

Bug 245609 – Mozilla not getting certificate issuer from Authority Information Access CA Issuers

Some people alerted me on a "bug bounty" for Firefox (even if the issue is with Mozilla Core and not on Firefox): the Portuguese Ministry of Justice will pay a 1000 Euro reward for those who fix this "bug". What's the catch?

Well, first of all, this is not a bug. It is correctly tagged as a RESOLVED as INVALID enhancement, and it is. It could be, if anyone cares to do so, a VALID enhancement, simply by changing the context: something like "there's nothing that can happen wrong if we emulate the behaviour of the other browsers, and it would be better for users", explained, would suffice.

Now, the problem is that the message that announces the bounty says:

But somehow that doesnt seem enough to justify the problem.
First because it seems really stupid for Firefox not to
implement something that all other browsers implement and just
saying "lets wait till the standard is clear".
Second because its not a solution if you just say "reconfigure
the server and make sure that the intermediate certificate is
served". The other browsers dont need that.
Third because even if you install the certificates locally
in your browser, the problem continues. It seems to be
related to a possible problem with comparisons of fields
encoded in UTF-8 in one certificate and encoded in quoted
printable in others.

Well, if you're trying to convince those who maintain a piece of software that they should implement an enhancement, you shouldn't start by calling the actual behaviour as "really stupid", specially when that behaviour is RFC compliant, thus not a bug. Then, the problem, as described in the bug page, isnt that "the standard isn't clear": if you actually read the RFC's, you'll see that the https server has the obligation to send a complete certificate chain.

Now, IMHO the target should be "have the issue properly solved", so, since the issue is that, by RFC, the https server must do something that isn't doing nowadays, then having a "bug bounty" over Firefox isn't helping. If the target is to have Firefox with the same behaviour as the other browsers, then it would be nice to have a proper enhancement request submitted and aprooved, and only after that a "patch bounty" for an implementation of the solution. I could do some more work on this issue - heck, I could even go after that bounty. Presented the way it is, I'm just not interested: seems to me that the solution proposed is ignoring the fact that the target website is broken since it is not complying with the standards involved. Supporting a broken web by changing the behaviour of one web browser is plain blindness, specially because you can't garantee that (1) every browser acts the same way, and (2) in five years you have a major browser out there that implements everything well but still does not support broken cert chains.


Useful links:
http://www.ietf.org/rfc/rfc2246.txt;
http://www.ietf.org/rfc/rfc2459.txt;
http://www.ietf.org/rfc/rfc3280.txt;
http://www.ietf.org/rfc/rfc4346.txt;
http://tools.ietf.org/id/draft-ietf-tls-ssl-version3-00;
http://www.ietf.org/html.charters/tls-charter.html.


From RFC 4346:

certificate_list
   This is a sequence (chain) of X.509v3 certificates.  The sender's
   certificate must come first in the list.  Each following
   certificate must directly certify the one preceding it.  Because
   certificate validation requires that root keys be distributed
   independently, the self-signed certificate that specifies the root
   certificate authority may optionally be omitted from the chain,
   under the assumption that the remote end must already possess it
   in order to validate it in any case.