Every programmer ever born thinks whatever idea just popped out of their head into their editor is the most generalized, most flexible, most one-size-fits all solution that has ever been conceived. We think we've built software that is a general purpose solution to some set of problems, but we are almost always wrong. We have the delusion of reuse. Don't feel bad. It's an endemic disease among software developers. An occupational hazard, really.

If I have learned anything in my programming career, it is this: building reusable software, truly reusable software, is an incredibly hard problem – right up there with naming things and cache invalidation. My ideas on this crystallized in 2004 when I read Facts and Fallacies of Software Engineering for the first time. It's kind of a hit-or-miss book overall, but there are a few gems in it, like fact #18:

There are two "rules of three" in [software] reuse:

It is three times as difficult to build reusable components as single use components, and
a reusable component should be tried out in three different applications before it will be sufficiently general to accept into a reuse library.

Yes, this is merely a craftsman's rule of thumb, but the Rule of Three is an incredibly powerful and effective rule of thumb that I have come to believe deeply in. It's similar to the admonition to have at least one other person review your code, another rule of thumb that is proven to work. To build something truly reusable, you must convince three different audiences to use it thoroughly first.

OK, so you built a solution that scratches your itch … but does anyone else care? How many other people have the problem that your software or website addresses? How many other competing solutions are there to choose from? Outside of your personal patient zero case, can you convince anyone to willingly, or even enthusiastically, adopt your solution? That's your first hurdle. Can you even get to number one?

How deeply do I believe in the Rule of Three? So deeply that I built two whole companies around the concept.

With Stack Overflow, we didn't set out to build a general purpose Q&A engine. We only wanted to solve the problem of programmers looking for fast, solid technical answers to their programming problems, instead of the endless pages of opinions and arguments they usually got. Oh yeah, and also to deal with that hyphenated site. One of the greatest pleasures of my life is meeting programmers that have never heard of this hyphenated site now. I hope you can forgive me, but I mentally superimpose a giant Dubya-style "Mission Accomplished" banner over their heads when they say this. I grin a mile wide every time.

We launched Stack Overflow to the public in August 2008. It was such a runaway early hit that I started to get curious whether it actually would work for different audiences, even though that was never the original idea. But we decided to play the six degrees of Kevin Bacon game and take some baby steps to find out. Less than a year later we had Stack Overflow for programmers, Server Fault for system administrators, and Super User for computer power users – the full trilogy. Three sites with three distinct audiences, all humming right along.

One customer or user or audience might be a fluke. Two gives you confidence that maybe, just maybe, you aren't getting lucky this time. And three? Well, three is a magic number. Yes it is.

Once we proved that the Stack Overflow engine could scale to these three distinct communities, I was comfortable pursuing Stack Exchange, which is now a network of over 100 community-driven Q&A sites. The programming audience derived assumptions that the engine was originally designed around means it can never scale to all communities – but for communities based on topics that can be understood via questions about science, facts, and data, there is no finer engine in the world. Not that I'm biased or anything, but it's stone cold truth. Don't believe me? Ask Google.

When we launched Discourse in February, I had zero illusions that we had actually built workable general purpose forum software, even after eight months of hard work. That's why the "buy it" page still has this text at the top:

Unfortunately, you can't [buy Discourse] … yet.

Our immediate plan is to find three great partners willing to live on the bleeding beta edge and run forums with us, so that we can be confident we've built a discussion platform that works for a variety of different communities. We promise to do everything we can to host your forum and make it awesome for two years. In return, you promise to work with us on ironing out all the rough edges in Discourse and making sure it scales successfully – both socially and technologically – to those three very different audiences.

Hey, there's that magic number again!

Even now, months later, we're not even pretending that we have open source discussion software that works for most communities. Hell, the FAQ literally tells you not to use Discourse. Instead, we're spending all our effort slowly, methodically herding the software through these three select partners, one by one, tweaking it and adapting it for each community along the way, making sure that each of our partners is not just happy with our discussion software but ecstatically happy, before we proceed to even tentatively recommend Discourse as any kind of general purpose discussion solution.

Because I worship at the altar of the Rule of Three, it's pretty much been my full time job to say "no" to people every day for the last 6 months:

Hey, Discourse looks great, can you host an instance for us?

Sorry, not yet. Probably in 2014!

We desperately need great forum software for our community! Can you help us set up Discourse?

Sorry, I can't. We're focused on building the software. It is 100% open source, and we do have a pretty good install guide if you want to grab the code and set it up!

We'll pay you to host Discourse for us! Shut up and take my money!

Sorry, I wish I could. It's not complete enough yet, and the last person I want to disappoint is a paying customer, and we don't even have a billing system! We plan to get to hosting in early-ish 2014.

So yeah, I won't lie to you – I'm basically a total bummer. But I'm a total bummer with a plan.

The solution we constructed in Discourse was a decent start, but woefully incomplete – even wrong in some areas. The only way we can figure this out is by slowly running the solution through its paces with our three partners, to live in the same house of software they do as roommates, to walk alongside them as they grow their discussion communities and do everything we can to help build it into a community we enjoy as much as everyone else does. And when there were only one set of footsteps in the sand, well … that's because we were carrying you.

We haven't made it all the way through this process yet. We're only on partner #2; it takes the time it takes. But thanks to the Rule of Three, I'm confident that by the time we finish with partner #3, we will finally have a truly reusable bit of general purpose open source discussion software to share with the world – one that I can recommend unhesitatingly to (almost) anyone, because it'll probably work for their community, too.

So the next time you think "I've built a reusable thing!", stop, and think "how can I find three users, customers, or audiences, to prove that I've built something reusable?" instead.

[advertisement] Stack Overflow Careers matches the best developers (you!) with the best employers. You can search our job listings or create a profile and even let employers find you.

[…]

Dispute of Vulnerability CVE-2014-2734

May 9, 2014

We were recently informed about a possible security vulnerability that has been published as CVE-2014-2734. However, based on our detailed analysis below, we do not consider Ruby to be vulnerable.

This vulnerability could possibly allow an attacker to forge arbitrary root certificates by modifying the certificate’s signature, effectively replacing the certificate’s original private key with one chosen by the attacker.

Proof of Concept

The following is our analysis of CVE-2014-2734, we were able to reduce the original PoC, which we believe captures the essence of the proof of concept:

require 'openssl'

forge_key = OpenSSL::PKey::RSA.new(2048)
raw_certificate = File.read("arbitrary.cer")
cert = OpenSSL::X509::Certificate.new(raw_certificate)
resigned_cert = cert.sign(spoof, OpenSSL::Digest::SHA1.new)

resigned_cert.verify(key) #=> true

It may come as a surprise that X509Certificate#verify returns true. The original certificate may contain a Subject Public Key Info pointing to the original public key which is different from the public key of forge_key. Clearly, the public / private key pair that was used to re-sign the certificate no longer matches the original public key referenced in the Subject Public Key Info. Why does #verify return true?

How keys are verified

X509Certificate#verify uses OpenSSL’s X509_verify function internally, which delegates to ASN1_item_verify. These functions establish the validity of the signature given the public key that was presented. However, they will not verify if the given key actually matches any subject public key referenced in the certificate. This means that returning true is expected behavior for X509Certificate#verify in this scenario. Omitting this check has no significant impact on the overall security of the X.509 trust model.

Section 4.1.1.3 of RFC 5280 explicitly states that by computing a certificate’s signature, the CA confirms the correctness of the information contained in the certificate. While this principle is violated in the above example code, it poses no threat to security. A certificate forged or modified in this way cannot be exploited unless someone is able to convince you to explicitly trust a certificate that violates this principle.

Potential risks

There are two cases to consider:

Re-signing a root certificate

As users, we trust root certificates unconditionally. Even if they do not contain valid information, the status of being a publicly acknowledged root certificate alone is what keeps them pristine. They are preconfigured values in the trust stores of our browsers or operating systems. Simply possessing them establishes their status as valid trust anchors. For example, OpenSSL itself does not check the signature of self-signed root certificates by default for the same reasons, cf. X509_V_FLAG_CHECK_SS_SIGNATURE documentation.

A re-signed root certificate becomes a de facto “self-signed” certificate (albeit with incorrect Subject Public Key Info). This is not any more dangerous than a normal self-signed root certificate. In fact, anyone can produce self-signed root certificates which may completely match that of a valid root certificate - except for the signature. Since we trust root certificates merely by possession, such an imposter certificate is meaningless without a client’s active consent to trust it.

Re-signing an intermediate or leaf certificate

Also, re-signing a non-root certificate does not violate the security of the X.509 trust model. While we usually do not possess these kinds of certificates in advance, their forgery would be detected during the path validation procedure. Here, any non-root certificate’s signature is verified using the public key of the issuing certificate. At some point in the certificate chain, the forgery would be ultimately detected in the form of an invalid certificate signature value.

Conclusion

In conclusion, we believe that X509Certificate#verify operates as expected. Others have independently arrived at the same conclusion and we have therefore disputed CVE-2014-2734, and asked for its revocation. You can find our complete analysis of the original proof of concept including comments.

Posted by emboss on 9 May 2014

[…]

The Ruby Rails Aggregator