Forgot your password?
typodupeerror

Comment: Re:Militia, then vs now (Score 1) 1370

by NateTech (#46781825) Attached to: Retired SCOTUS Justice Wants To 'Fix' the Second Amendment

Which even if true, means it's inept to send 200 armed soldiers to collect. That's not how we handle debts in the U.S.

If it were, we'd have surrounded Al Sharpton's house with 200 armed agents many years ago for the $3.5M in back-taxes he owes. And we probably wouldn't want the top law-enforcement person in the country speaking at his events.

Comment: Re:de Raadt (Score 1) 284

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

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

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?

(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.

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 (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.

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

Hrmm.

http://www.urbandictionary.com...

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.

Money is the root of all wealth.

Working...