Deveops types aren't the kind of people to be crawling around under desks or helping directly to push for a release milestone.

They're the go-betweeners, sort of a cross between senior sysadmin and development project management assistant. They are the internal toolsmiths, depending on the blacksmiths to produce effective metal so they can hone the tools for the carpenters' needs. They are broadly skilled and know how to at least muddle along in both a developer and a sysadmin job, but prefer the big picture of orchestration. They're the ones who figure out where the shortcomings are, and are broadly skilled enough to jump in and provide possible avenues and solutions, seeing where one side can't fix a problem, and the other may have a solution.

Exactly.

This "there is no role for devops in a mature company" attitude cries back to the age of isolated business units with isolated departmental goals, often where sales sells products that don't exist and engineering produces products nobody wants. The money to run the company will come from somewhere!

In short, developers don't want to dogfood, because that's hard. It's much easier to not challenge yourself with divergent ideas from what you and your brainfund coworkers cook up: after all, developers made it, so it must be good.

And yes, devops is an integral part of dogfooding. It makes sure the left hand is talking to the right, Support is able to effectively move issues laterally, operations can effectively provision IT infrastructure budgets, and Engineering can focus on the real issues that impact the product. It's called teamwork. If you can't get this part done right - at the very least, making sure your product works in an operational capacity internally - how can you expect it to be a commercially viable option out of house?

Fixed within, 24 hours on 187 servers running open source openssl libraries, f and earlier versions.

I still do not have fixes for about 5 proprietary customer products, and there has been no word from 3 of them if they intend to fix them.

I have informed my customers that they should consider moving from the proprietary products IF they have the cash to do so.

I really do not see your point in asking the question.

You cannot design and build secure software to begin with.

You need to have the source code for the forseeable future now because of the world we live in.

Very very bad people are coming out of the pit and they want your infrastructure, your data and your intellectual property.

But above all, they want control of you.

Open Source can prevent a world like that from taking hold, but it cannot save a fool from his foolishness.

... ask yourself a question, why is it that everything in USA was done "up until the 1970s" and then all of a sudden there was a gigantic decline (from building, to meaningful manufacturing jobs, to wage disparity, to ability to afford anything, etc.etc.etc.)?

So what is it that happened in the 70s that changed the USA economy so much? 1971 - Nixon defaults on the gold US dollar. The reason? Inflation that was caused by the Fed, all the massive government that could never be paid for with any amount of taxes (never mind the insane tax rates before that time).

It's the government, my dear, USA government has destroyed USA economy.

The reality is that it doesn't matter WHAT the law says. If they obtain the data, they can and will do anything they want with it. I knew this long before the whole NSA "expose`".

I am not saying we shouldn't make laws about it, or even try to enforce them, but I am saying that laws and enforcement are not enough. To some degree, the government (and businesses) simply should not have access to certain data in the first place because it is the ONLY way to prevent it from being used in an abusive way.

Not sure what the big news is.... like we didn't already know this? They probably already have access to every state's DMV records, which include photographs for every person who has a driver's license or ID card. I would estimate that is maybe 90% of every adult citizen, alone.

And yes, it upsets me.... far less than fingerprinting or DNA, however. The only privacy-friendly biometrics are those that we don't "leave" all over the place, and can't be collected or taken without our knowledge. That leaves things like retinal scans and deep vein pattern recognition.

Just like a malicious client can suck data out of a vulnerable server, the same can work in reverse, though clients tend not to keep an SSL connection open any longer than they need to (unless, it's IMAPS or FTPS or chat or some other application with persistent connections).

If you suck the private key out of a bank webserver's RAM, then perform a MITM attack on the bank users using the bank's own certificate, not only can you get their bank credentials (by them filling in the form and sending it to you), depending on the browser you may or may not be able to suck up other accounts from them (eg user logs into a credit card company site to see their bill, then logs into your fake bank to see if they can pay it).

Closed source is hazardous in many ways. Along with being more frequently targeted, the NSA revelations showed that Microsoft worked with the NSA when deciding how quickly to close some holes. Another hazard is the threat of being attacked and/or sued by companies whose products were found to have problems.

No question the heartbleed thing is a huge and embarassing problem. But you know? It's actually kind of hard to count the number of high-profile vulnerabilities in F/OSS software as not a whole lot come to mind. On the other hand, the list is enormous for closed source from large companies... also hard to count but for another reason.

It does highlight one important thing about F/OSS, though. Just because a project has enjoyed a long, stable and wide deployment, code auditing and other security practices are pretty important and just because it's a very mature project doesn't mean something hasn't been there a long time and had simply gone unnoticed for a long, long time. People need wakeup calls from time to time and F/OSS developers can be among the worst when it comes to their attitudes about their territories and kingdoms. (I can't ever pass up the opportunity to complain about GIMP and GNOME... jackasses, the lot of them.)

Closed source is not inherently safer. Raymond's proposition is theoretically sound, however in actual practice, the NSA has "many eyes"...

What if this was not 'OpenSSL' but instead it was some form of 'ClosedSSL' library that had this problem in it?

NSA would still have access to THAT code, you can bet your ass they would, they wouldn't leave a project like that alone. However nobody else would know (unless stumbling upon it by chance or being able to access the source OR if some insider SOLD that information to somebody on the outside and now you'd have a vulnerability that is exploited by the gov't and by shadiest of the organisations/people out there).

This does not change the discussion in terms of open source code being safer, this changes the discussion around certain practices of development / testing and also this may attract more attention of people towards the SECURITY of our information on the Internet and hopefully we'll move in the direction of working out the details of actually much more SECURE methods of communications.

I certainly have a few ideas of my own that I would like to implement now, but never mind that. The point is that this is good stuff, it finally shed a light on this topic, that should have had much more light on it for a much longer period of time in the first place.

We need better methods around building security within our systems and I think this raises the bar.

by "whining" are you implying that I do not vote in firehose? Is that your professional opinion, I mean, are you paid to believe that or is this just a result of being an ass, your statement here?

std::containers don't need to store their size as a separate variable

C strings don't either. It's the protocol that said "hey, rather than null terminating strings, let's put a length byte like Turbo Pascal never went out of style!"

The fun thing is that that design decision has lead to an entire CLASS of SSL bugs (in all stacks, not just openSSL) eg invalid certs validating because of a null byte in the Common Name. And heartbleed was just one more in that heap.

By the way, if we are already on the topic of taxes, anybody who is interested should listen to this show, not only does it discuss the illegality of taxes, but also it provides some insight on what the USA citizens doing today to reduce their taxes (offshore accounts, etc.etc.)

Americans, you need to listen to this of-course, you should eliminate your federal government, a good step towards that (before you end up shooting the bastards) is to stop paying your taxes.

Turn on your Heartbleed,
Let it shine, wherever you go
Let it make a happy glow
For the NSA to see...

this is of-course a dupe, but hey, what else is new.

Ted talk on this device.