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.

He was referring to https://www.gitorious.org/gnut... and https://www.imperialviolet.org..., not to mention http://bsd.slashdot.org/story/... which also sat 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.

Aerial photography?
Traffic monitoring and alerting?

He means the Russians can buy the current working directory.

OWASP has guidance; for instance, here: https://www.owasp.org/index.php/IOS_Developer_Cheat_Sheet#Insecure_Data_Storage_.28M1.29

From https://www.owasp.org/images/5/5e/Mobile_Security_-_Android_and_iOS_-_OWASP_NY_-_Final.pdf
2. Insecure data storage
Solution
  Avoid local storage inside the device for sensitive information
  If local storage is “required” encrypt data securely and then store Use the Crypto APIs provided by Apple and Google
  Avoid writing custom crypto code – prone to vulnerability

Chinese need an exit visa to leave China.

304 Permanent Redirect: https://www.youtube.com/watch?v=i37uttMA6Mc