Honey has botulism in it. Sometimes.
Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
mod parent up, damn. The things people say around here.
Well, finally today they do. LLVM is good for catching unsafe casts and such, which can hide buffer overflows.
Yes, exactly. (My day job is static analysis)
"Many Eyes" are great for identifying and fixing the broken build... but have no good track record for monitoring security design and implementation flaws.
For security infrastructure critical code, the available tools should be coming up spot clean. This is absolutely not the case with Openssl.
And I am not even a crypto expert! Well, this is a very long-winded way of saying that the GP "DigitAl56K" was probably right; that we do need a clearing-house of good software cryptographic random number generators.
repeatedly hashing a counter that is set with a random seed
But I think that's exactly why you don't roll your own. That would be a predictable sequence. I could make a rainbow table of sha1('1'), sha1('2') etc. up to 4 trillion, and then by sampling a few numbers from your stream I could very quickly identify the current counter value and the next sequences for ever. Total fail, and if the seed is the system time this is only a level of abstraction more difficult. (Chess & West, p. 398)
That was for fast secure hashes, and not for psuedorandom numbers. They aren't really the exact same thing, are they?
That's utterly crap advice. Since a lot of softwares in popular, active use have critical vulnerabilities.
The example quoted just above (http://ask.slashdot.org/comments.pl?sid=4862577&cid=46414687) in which nobody got the sarcasm... says:
You know there won't be any bugs in those, or if there are they'll be very quickly fixed and not sit there unnoticed for years.
The last time I tried to run OpenBSD, it was so I could test our static analyzer Fortify SCA on the kernel.
One thing that really held me back in my research is that processes were limited to about 1 Gigabyte of RAM each. What exactly is the reasoning behind this hard limit?
Note: I never finished my work, but it would be totally cool to compete this someday.
It's a design error, plain and simple. I don't know what the real solution is however.
If you dump enough ice that it actually cools the oil, then it's fine.
Obviously, risky behavior if you don't know the equipment you're working with.
All of this already exists. Type rated Captains, First Officers, ATPLs, CPLs
Instructing is not an apprenticeship. First Officer is an apprenticeship, a program which of course already exists.
Traffic monitoring and alerting?