I agree, but nobody said or inferred that

That seems like an interesting thing to say, given what you said next.

even if you do have "many eyes" (and the vast majority of projects do not) and even if you assume they are the right ones looking in the right place at the right time you will likely find at least some bugs at some point in time.

First, "I agree, but nobody said or [implied] [otherwise]"; the argument is that many eyes make bugs shallow, not spontaneously and instantaneously evaporate. Second, of course "you" will find some bugs at some point. The whole idea is that people will find bugs at some point, and in fact at some sooner point, because more people are looking.

it's hardly a reliable and practical advantage, more of a shot in the dark

I'd say it's an unreliable but highly fucking practical advantage, actually, because when there's only one target it's more likely you'll hit the guy with a thousand shots in the dark than just one or two.

in this case

In this case, the specific bug found seems by all accounts to be something very difficult to find via code review, especially given the OpenSSL codebase.

given the profile of the project this is an absolute best-case scenario

The fact it is a high profile project seems to be the only positive factor in this case, apart from the bare minimum fact that it is open source. There are many, many problems with this case that make it more difficult for this bug to have been found any earlier than it was. A new feature that passed review by one person on the core team was included, then found and fixed less than three years later. It was found by people outside the core team who only had access to the codebase because it was open source. The guts of OpenSSL are heavily compromised by eons of feature creep, which seems to be common to every major/widespread TLS package on the planet. While the wisdom in secure coding of the core team is open to question, for a number of reasons, the team at least seems to be universally pretty clear on some basic concepts of not relying on magic security-through-obscurity fairy dust. The best case scenario for pretty much every closed source TLS package that competes with it differs from these conditions mostly in one or two ways: they are not open source, so they would not have been backed up by the people who found the bug in OpenSSL; they may use magic security-through-obscurity fairy dust to make their code "secure". On top of that, the public nature of the discovery combined with the necessarily public nature of the project's handling of bug patching ensures that the bug got fixed very damned quickly.

Now . . . not all bugs (even critical security bugs) will be found more quickly just because it's open source. See above where I paraphrased: "nobody said or [implied]" that it's always perfect all the time immediately with zero delays so nobody ever has bugs in their software. The actual, reasonable, rational claim is that it provides enough of a benefit, often enough, to make smart open source development processes a very good idea, especially for security software. I think it's pretty reasonable to say that, given the exact same conditions apart from the things that would necessarily be different just due to the intrinsic nature of open vs. closed development models, the best you could reasonably expect from a closed source project in the same situation is almost exactly what happened -- but, much more realistically, it would have taken longer, because someone would have to have nailed down the particulars of the problem without access to the source code.

. . . so no, I don't agree with your point.

it didn't work effectively enough to stop this from being extremely widely distributed.

This is true for this one specific case. I'm going to assume that is not your actual point, now, because if it is, that's a fucking stupid point. Your point should not be "This one slipped through the cracks, in some ways." If that is really the whole of your point, your "I Am Not A Hypocrite" card just got revoked.

I'm not endorsing OpenSSL. I think its best endorsement is "It's probably 3% worse than the major competing options, both open source and closed, which all universally suck -- at least until something like LibreSSL is release-worthy." That's a pretty sucky endorsement, but it's the best we can do for OpenSSL -- to say that it's the (marginally) least awful of a pretty uniformly awful category of software.

I just think it's beyond stupid to say "This bug was found, therefore the software's development methodology ensures we never find bugs!" or some such twaddle.

The (lack of) constraints on who can see the code is not the only difference. There's another difference, that for some reason gets explicitly denied as a difference by the preceding anonymous coward:

I would, in fact, expect that the passion and interest of coders in the open source world is actually far greater on average than in the closed source world, rather than exactly the same as the anonymous coward suggests. I have met many "professional" coders who write closed source software for some part of their typical eight hour workdays, and never think about code outside of that time if they can avoid it. Many of them hate coding, in fact, but do it for the paycheck, then go watch American Idol in the evenings and try to avoid having anything "boring" like computer programming intrude on their off-time.

Open source developers are the people who are interested and passionate enough about what they do to do it on their own time, or even to seek out jobs where they're allowed to contribute to open source projects on company time. That takes more dedication and honest interest in producing something good than just working in a cubicle for eight hours a day where they honestly couldn't give a shit whether what they were doing was writing code or picking their noses, as long as the paycheck keeps coming in.

Thus, I think there are some distinct benefits to open source software above and beyond the mere fact that given enough eyes, all bugs are shallow.

So, yeah . . . your second paragraph, only more so. That's my opinion.

Are you sure you don't mean PostgreSQL?

FTFY

It's difficult to get enough eyes on the project when its design is such a mess that people who take a look at it have no idea what they're seeing.

Every major TLS software package available is crap, from what I've seen. OpenSSL only "proves" that with a sufficiently hyped marketing campaign, a bug in one package can ruin its reputation relative to others with similarly bad security issues that did not get the same marketing. In some respects, it could be argued that the recently discovered bugs in GnuTLS and Apple's TLS code were actually worse than the heartbeat feature's bug in OpenSSL, if only because the kind of coding stupidity that produced those bugs would almost certainly never have been made by someone who would even be capable of fixing the OpenSSL bug, while the OpenSSL heartbeat bug (aka "Heartbleed") is basically just a mistake made by an at least marginally competent coder.

So, take your pick: "Heartbleed", a bug introduced as a possibly understandable mistake by an at least marginally competent coder, but comes with tremendous marketing hype -- or the GnuTLS and Apple bugs of the "we check to make sure it's a verified connection, but then do nothing about it when it's not verified", which are the kinds of errors that require the relevant coders to actually be incompetent, drunk, or otherwise so out of whack that it makes those of us who understand the problem scratch our heads and wonder how that could ever possibly have happened, but did not come with tremendous marketing hype, so nobody really thinks about the shaky ground on which they're standing when using that software.

The key fact to keep in mind, though, is that basically every major, widely used TLS package in the world (open source or closed) seems to be rickety garbage mostly maintained by manifestly unqualified programmers. Worse, many of them don't seem to realize they're unqualified. OpenSSL appears, from what I've seen (which admittedly isn't enough to be sure of my conclusions), to be at least slightly less awful than Apple's, GNU's, and Microsoft's equivalents, but even optimistically it is the best of a bad breed. There is one ray of hope here, however: some people in the OpenBSD project have undertaken the herculean task of forking OpenSSL and rehabilitating it. Given the relatively high density of people with secure coding skills in the OpenBSD developer community, and the OpenBSD project's practice of performing extensive code reviews, as well as the early evidence that these guys are doing what it takes to make a good TLS package out of OpenSSL -- throwing away huge swaths of unnecessary code and cleaning up some horrendous bugs that have been around forever -- I have high expectations, assuming the fork project doesn't die before reaching stable release state.

What are you talking about? FreeBSD makes use of Linux-based technology all the damned time -- just as soon as it can port it (because for some reason Linux developers are increasingly hostile to software portability) or reimplement it (because the Linux community seems inextricably wedded to using licenses that create compatibility problems with other licenses, thus making it illegal for BSD Unix projects to use the original implementations). The fact not all technologies are deemed worthy for adoption does not mean that all Linux-based technologies are avoided just because they came from the Linux world, y'know.

I'm not sure it's possible to have a rational conversation with someone who makes comments like that as though intentionally creating a rift between participants in discussion as a pre-condition for conversation.

Vim potentially creates licensing problems for BSD Unix base systems.

citation needed

Also . . . licensing.

. . . by which point it will have already been deprecated in the community at large by something else half-created that is buggy and problematic. Some Linux distributions will of course be resisting the sudden jump to a new, unfinished replacement for the last unfinished replacement, but they'll have problems because other things that they want to use will jump to dependence on the new, unfinished toy.

I guess we can ignore all the stuff being created in "BSDland", including stuff that keeps getting ported to "Linuxland" because the Linux developers were too busy building half of something and making it technically very difficult to port to BSD Unix systems.

Say what? I suppose new capabilities of, say, pf "only exist and thrive because they run on Linux not because of BSD", even though pf isn't portable to Linux. Right? Then, of course, there's the BSD ACL framework on FreeBSD that is widely regarded as being as capable as SELinux and easier to use. I think you just don't know what the hell you're talking about.

. . . or maybe you're just an OS bigot, and what you're saying is complete claptrap.

You're kidding -- right? If it was true, SCO would have won its case rather than descending into blood-smeared bankruptcy, its CEO living in infamy with his reputation worth a bucket of feces, its shareholders' stock portfolios decimated, and its name a ludicrous joke.

I agree. Why are you so resentful and hateful?

I haven't really seen that on the mailing lists and in IRC. Maybe what you observe is a problem with the forum, specifically.

I think this statement of yours demonstrates that you're just looking for reasons to hate FreeBSD users.