Forgot your password?

Comment: Re:de Raadt (Score 1) 287

by bmajik (#46761037) Attached to: OpenBSD Team Cleaning Up OpenSSL

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?)

Comment: Re:de Raadt (Score 1) 287

by bmajik (#46760367) Attached to: OpenBSD Team Cleaning Up OpenSSL

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?

Comment: Re:de Raadt (Score 5, Insightful) 287

by bmajik (#46759527) Attached to: OpenBSD Team Cleaning Up OpenSSL

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 ... you should already be squarely in the land of "doing every possible software engineering best practice possible". This is software that needs to be written differently than "normal" software; held to a higher standard, and correct for correctness sake.

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.

Comment: Re:Microsoft does not want kids coding... (Score 1) 226

by bmajik (#46686665) Attached to: Should Microsoft Give Kids Programmable Versions of Office?

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?


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.

Comment: Re:Microsoft does not want kids coding... (Score 1) 226

by bmajik (#46684479) Attached to: Should Microsoft Give Kids Programmable Versions of Office?

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 (

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.

Comment: Spacedocking? (Score 1) 392

by bmajik (#46664213) Attached to: How Many People Does It Take To Colonize Another Star System?

Luckily, tens of thousands of pioneers wouldn't have to be housed all in one starship. Spreading people out among multiple ships also spreads out the risk. Modular ships could dock together for trade and social gatherings


I don't think this will contribute to genetic diversity....

Comment: Re:60 minutes is not longer of value (Score 1) 544

by bmajik (#46651345) Attached to: 60 Minutes Dubbed Engines Noise Over Tesla Model S

60 minutes has had credibility problems for a long time.

They _destroyed_ Audi in the 1980s. They fabricated the "tests" and the results. They modified the cars and rigged them to fail in the way 60 minutes wanted them to.

Nothing 60 minutes says about cars should be considered accurate.

If there was any justice in the world, the show and the people behind it would have been in prison 30 years ago.

Comment: Re:Don't do it. period. (Score 0) 119

Funny you mention that.

Early in my Microsoft career, I built a system that provisioned thousands of windows machines on an as needed basis, differing by SKU level, language type, windows version, etc.

I'm was proficient in scripting the installs of windows machines -- even back when windows didn't natively support that sort of thing very well(e.g. NT4)

To be honest, Windows looks pretty good compared to any Linux distro I've worked with when it comes to automated provisioning and post configuration. That's a subjective comparison, of course, so I'll just say: I don't think windows was your problem.

It sounds like your management wasn't especially visionary nor technical, and that you failed to make an adequate business case to them regarding how much productivity the team would gain in the long run if you worked to automate these repetitive tasks.

That's a shame. I'm glad you moved on to greener pastures.

Comment: Re:Very amusing but... (Score 2) 314

Most German cars (which is who Tesla competes with) have undercarriage engineering for reasons of sound and high-speed aero concerns. They are expected to sustain 200kmh, and the relevance of drag rises exponentially with speed, but also, controlling airflow is important so that the car doesn't have too much high speed lift. What you do NOT want is a vehicle that loses significant grip as speed rises, yet most cars are shaped like (poor) airfoils so this is a concern.

You may recall that the first gen Audi TT did not have a rear deck spoiler, but real world driving showed that there were many high speed loss-of-control accidents with the vehicle, so a rear spoiler was fitted later.

Comment: Re:Not easy? (Score 1) 323

by bmajik (#46553557) Attached to: More On the Disposable Tech Worker

Of course.

I would say it is more of an exceptional case, but I've worked with folks who have non-technical degrees (Philosophy) and those who have no degree at all.

I think most of our listings say they require a 4 year degree in CS or a related field. So, that's a pretty harsh filter.

If you're the kind of person that doesn't match resume filters, your best bet is to know somebody already in the company, and get referred by them.

It's probably easier than ever to get noticed in the software industry though. There is a whole world o open source projects out there for you to contribute to, and all of that work is, by definition, public knowledge.

When I see someone has listed work they've done on OSS projects on their resume, that tells me way more than whatever they write about education or school projects.

Comment: Re:Not easy? (Score 1) 323

by bmajik (#46551167) Attached to: More On the Disposable Tech Worker

Your conclusion -- that good candidates never make it to my inbox because of recruiter filtering -- is certainly possible.

I think you've misunderstood what I wrote, however, on criteria.

Not only do we not have a policy of only hiring the top 20%, we don't even know how to measure that.

I am basing those comments on the observation that we talk to many more people than we're actually able to feel good about extending an offer to. I surmised it might be the top 20% based on the # of people I personally have had to "no hire" before I could recommend a hire. I apologize for not making that clearer.

I suspect that, as a college hire, you'd have been an ideal candidate for us. Clearly you had passion in the software space, given what you'd accomplished before finishing college. It's always possible that you'd bomb an interview question about doing something perverse in C with linked lists, but, that's really a matter of your technical competence and if you have any hangups about technical interviews (some people do).

fwiw, I went to a boring state university, and had a pile of UNIX/linux experience before and during college.

We have no restrictions or criteria at all as far as what universities people come from (we do have a finite amount of university recruiting money, so, we don't send campus recruiters to every college in the US.)

Regarding recruiting -- the recruiters we have are not programmers, but technical recruiting is the entirety of their job. And, they are not the only way people get into the pipeline. For instance, when I do campus recruiting trips, there is little to no pre-filtering of the resumes I get.

The conclusion I really want you to take away is that just because somebody has a degree in CS doesn't mean we can hire them.

Lend money to a bad debtor and he will hate you.