Forgot your password?
typodupeerror

Comment: Not faked GPUs... (Score 4, Informative) 74

by OmniGeek (#47773585) Attached to: Fake NVIDIA Graphics Cards Show Up In Germany

I've read the Heise articles in the original German, and the GPUs were not faked; the cards were an older generation graphics card (~10% of the graphics throughput of the claimed item) with the video BIOS hacked to zero out the card manufacturer ID and the GPU type twiddled to fool the driver into thinking it was the newer card. According to the articles, NVidia is tracing the GPUs through the supply chain by their internal serial numbers.

I would speculate that someone bought up a truckload of obsolete cards, reflashed the BIOS images, and relabeled them with plausible product ID labels. Could have been the Chinese manufacturer, could have been someone elsewhere in the pipeline.

Comment: The chilling thing about Ted Unangst's analysis (Score 5, Interesting) 301

by OmniGeek (#46715395) Attached to: Theo De Raadt's Small Rant On OpenSSL

As I read his analysis, OpenSSL relies on releasing a buffer, reallocating it, and getting the PREVIOUS contents of that buffer back -- or else it will abort the connection. (Search for the string "On line 1059, we find a call to ssl3_release_read_buffer after we have read the header, which will free the current buffer." in his article referenced by the parent post).

Now, IMO, this goes way beyond sloppy. Releasing a buffer before you're done with it, and relying on a wacky LIFO reallocation scheme giving you back that very same buffer so you can process it, is either 1) an utterly incompetent coding blunder that just happened to work when combined with an utterly terrible, insecure custom allocation scheme, or 2) specifically designed to ensure that this insecure combination is widely deployed to provide a custom-made back door, as it works only with the leaky custom allocator.

If 1), then I must agree with Theo that the OpenSSL team were indeed irresponsible, since at least one of these two cooperating blunders ought to have shown up in a decent security audit of the code, and any decent set of security-oriented coding standards would forbid them both.

If 2), then it was deliberate, and the tinfoil-hat crowd is right for once.

Comment: All roads may run ill... (Score 5, Informative) 227

by OmniGeek (#45214327) Attached to: Ask Slashdot: How Do You Choose Frameworks That Will Survive?

Been there, done that, wondered "What were we thinking?"

In selecting an instrumentation framework for a test system, we went through a careful process of defining what was important, listing the pros and cons of each competing option, ran some tests to see if both would run the instruments we needed, ... Aaaand chose the worse option of the two, as events ultimately showed. The choice was evidence-based, reasonable on the basis of what we knew at the time, and suboptimal. The system worked, but we had to do some ugly stuff to make it work.

Sometimes you just can't outwit Murphy.

Censorship

Joining Lavabit Et Al, Groklaw Shuts Down Because of NSA Dragnet 986

Posted by Unknown Lamer
from the freedom-of-the-press dept.
An anonymous reader was the first to write with news that Groklaw is shutting down: "There is now no shield from forced exposure. Nothing in that parenthetical thought list is terrorism-related, but no one can feel protected enough from forced exposure any more to say anything the least bit like that to anyone in an email, particularly from the U.S. out or to the U.S. in, but really anywhere. You don't expect a stranger to read your private communications to a friend. And once you know they can, what is there to say? Constricted and distracted. That's it exactly. That's how I feel. So. There we are. The foundation of Groklaw is over. I can't do Groklaw without your input. I was never exaggerating about that when we won awards. It really was a collaborative effort, and there is now no private way, evidently, to collaborate." Why it's a big deal.

Can't open /usr/fortunes. Lid stuck on cookie jar.

Working...