Ok, I actually think you, me, and Theo all agree
1) We don't think a specific technical change would have _prevented_ the issue.
2) We all agree that better software engineering practices would have found this bug sooner. Maybe even prevented it from ever getting checked in (e.g. suppose the codebase was using malloc primitives that that static analysis tools could "see across", and that the code was analysis clean. Could this bug have existed?)
Who has claimed that using the system allocator, all else being equal, would have prevented heartbleed?
Who has claimed that heartbleed was an allocation bug?
I understand what freelists are and do.
The point here is that rigorous software engineering practices -- including the use of evil allocators or static analyzers that could actually understand they were looking at heap routines -- would have pointed out that the code implicated in heartbleed was unreliable and incorrect.
If you read the link you pointed at, after making a modification to OpenSSL such that coverity could understand that the custom allocator was really just doing memory allocation, Coverity reported 173 additional "use after free" bugs.
There are bugs from years ago showing that openSSL fails with a system allocator.
Don't you suppose that in the process of fixing such bugs, it is likely that correctness issues like this one would have been caught?
Actually, it is you who are wrong.
Theo's point from the beginning is that a custom allocator was used here, which removed any beneficial effects of both good platform allocators AND "evil" allocator tools.
His response was a specific circumstance of the poor software engineering practices behind openSSL.
Furthermore, at some point, openSSL became behaviorally dependant on its own allocator -- that is, when you tried to use a system allocator, it broke -- because it wasn't handing you back unmodified memory contents you had just freed.
This dependency was known and documented. And not fixed.
IMO, using a custom allocator is a bit like doing your own crypto. "Normal people" shouldn't do it.
If you look at what open SSL is
1) crypto software
2) that is on by default
3) that listens to the public internet
4) that accepts data under the control of attackers
I would say that, "taking a hard dependence on my own custom allocator" and not investigating _why_ the platform allocator can no longer be used to give correct behavior is a _worst practice_. And its especially damning given how critical and predisposed to exploitability something like openSSL is.
Yet that is what the openSSL team did. And they knew it. And they didn't care. And it caught up with them.
The point of Theo's remarks is not to say "using a system allocator would have prevented bad code from being exploitable". The point is "having an engineering culture that ran tests using a system allocator and a debugging allocator would have prevented this bad code from staying around as long as it did"
Let people swap the "fast" allocator back in at runtime, if you must. But make damn sure the code is correct enough to pass on "correctness checking" allocators.
You guys are ALL wrong. Don't you know? It's sudo pacman -Syu.
Actually, that's not it. You fork the code from a point BEFORE it goes to hell.
I understand very clearly the difference between accumulated debt and rate of growth of debt (which is what the deficit is).
At the same time, you should understand that you can't "inherit" a deficit. The idea is poppycock. The budget for each year stands fresh on its own. You can change a massive deficit to a surplus in a single year just by adjusting the numbers in your budget. Yes, interest on the debt (which IS inherited), and a piss poor economic climate (which is inherited to some extent) are burdens on the budget, but it within the power of the budgeters to counteract these. I don't claim it would be an easy choice to do it, or to live with, but it is in point of fact utterly trivial procedurally to do.
A final point I'll throw in just to make the whole discussion even more fun. No President has any control over the budget beyond:
1) Submitting one, which can be mutilated or just replaced by the legislature.
2) Signing off on whatever budget DOES get passed by the legislature (if there is one).
3) Using the bully pulpit, which is not trivial, but still it's just talk and persuasion.
In passing, I call attention to the point that those responsible for making a budget can subvert the whole process by just failing to execute their duty. Both the President and Congress have been guilty of that.
One could argue that a President can take unilateral action, like engaging the military in action, which necessarily leads to hemmorhage in the budget, so yes, that has to be mitigated. However, the legislature can still use the war powers act to limit the effect by limiting the time scale - IF, and it is a big IF, they are willing to stick their neck out.
Absolutely right. And I have the right to call you on it, you racist mysogynist dictator lover.
Not liking someone isn't a good enough reason to put them in jail.
Usually. For now.
yes, but only because it was a spoken and language with no written documentation. now a days not so much. but I like where you are headed.
I would tell you to use American Sign Language, but then They would just turn on the camera.
I haven't had a microphone connected to my computer since about 2001.
No laptop? The mid 1990s called. They want to know how you missed the last 20 years.
There's also the fact that Fluorinert is potentially toxic, but it's also a greenhouse hazard. One would hope that 3M learned their lessons in the development of Novec and it's not an environmental hazard.
All right, I'll bite. Aside from "OMG, it is, gasp, a CHEMICAL", if it is inert, how can it be toxic? From the MSDS for Fluorinert FC-40:
"Not classified as hazardous according to OSHA Hazard Communication Standard, 29 CFR 1910.1200."
"No occupational exposure limit values exist for any of the components listed in Section 3 of this SDS."
"Skin protection is not required."
"Inhalation: Vapors from heated material may cause irritation of the respiratory system. Signs/symptoms may include cough, sneezing, nasal discharge, headache, hoarseness, and nose and throat pain."
"Skin Contact: Contact with the skin during product use is not expected to result in significant irritation."
"Eye Contact: Vapors from heated material may cause eye irritation. Signs/symptoms may include redness, swelling, pain, tearing, and blurred or hazy vision."
Note, when they are talking about "heated", they are talking about heating to well above any proper operating temperature - greater than 200 C. The stuff CAN break down chemically under such conditions, and noxious/toxic products result. More or less the same as any fluorocarbon, including the refrigerant in your refrigerator.
It is non flammable, period. There is no flash point.
As for the GHG designation, absolutely true. However, essentially no evaporation of Fluorinert into the open should occur in a properly designed and maintained system.
Bubbles will appear on each wire, the negative side is hydrogen and the positive side is oxygen
Using NaCl as you describe to make the water conductive also results in the evolution of Cl - chlorine gas - more than oxygen. If your wires are bare copper, the metal also migrates from the positive wire to the negative wire, turning the solution nasty blue-green in the process.
Some caution is advised. Chlorine gas is toxic. It was used in shells to poison troops in WW1. Of course the amount is quite slight in the experiment.
Been a long time since I've bought Seagate as I've had great reliability from WD but out of curiosity, what's the cost?
We won't know shit until Newegg begins to stock them, maybe in about 5 years. Cost data from manufacturers, even when you can get it, is always useless because in the real world nobody pays anywhere near list price.
Suppose it has a security vuln?
Suppose it depends on a certain version of a legacy DLL we need to service for other callers?
Suppose it was never localized beyond English?
Suppose admins want to enable/disable it via group policy?
(etc)
For better or for worse, it is incredibly expensive to put something in the Windows Box.
We give away VS for free, in a variety of different versions/avenues. By not putting it in the windows box, we avoid a huge # of headaches.
Your conclusion is entirely wrong.
Because Microsoft doesn't do the things YOU think Microsoft should do, you can ascertain the motivations and goals of Microsoft?
How interesting. Suppose we hire you to lead our CS education strategy. Can you promise results? Are you willing to bet your career on your prophecies coming true?
Let me tell you what IS true.
Microsoft lets me -- and many other MS employees -- volunteer to teach CS in public K-12 schools, 1 hour a day, before heading into the office for our "real jobs".
MS spends money to make this happen (volunteer matching hours), and gets less of my productive time (without docking my pay). There are full-time employees dedicated to this project. They have no other MS business function.
The program I am referring to is called TEALS (www.tealsk12.org)
It is just one of the ways that MS puts time, money, and people, into trying to build a better pipeline of students who can do CS.
I don't think stuffing GWBASIC back into windows is going to take us from where we are to where we need to be.
I've noticed several design suggestions in your code.
