Hacker News Reader

Comment by viraptor | Hacker News Reader

I have no answer to the first one. Since urandom is periodically reseeded, I believe tptacek and others - at least they provide arguments that justify their position. The other side seems to be just silent.

As for "Also, why are the Ruby devs so dead set on the manual page?" - because it makes sense. If I didn't know much about random number generation, I'd rely on manuals and most widely adopted software. That means: urandom says it's not good for that usage, while openssl is used by almost every system. If you used a dependency that documents it does X and someone tells you that actually it does Y, but you have no ability to prove it either way, would you listen to the docs or random-internet-person.

View on HN

    would you listen to the docs or random-internet-person.

I mean given that scenario as you describe it yes, obviously you go with the docs. But these aren't random-internet people. These are the acknowledged experts in the field. If you are writing crypto related code and aren't familiar with these people then there is far more wrong here than just this bug.

> these people

Which people? Could you please name some of them? Honest question - the only name I can think of right now is tptacek's, but I'm sure there are more.

djb, Adam Langley, Dave Wagner, Thomas Pornin, among others.

I think the problem is that this person is not writing crypto-related code. (or they don't think they do) They write an interface to N underlying interfaces providing RNGs and don't necessarily understand how they work internally or the theory behind them. And that's kind of ok - they made it work correctly, but it could be better.

We don't expect person writing a Ruby binding for sqlite to know the theory behind database indexes and who are the acknowledged experts in that field. Yet we seem to expect that from a person writing binding for RNGs.

> We don't expect person writing a Ruby binding for sqlite to know the theory behind database indexes and who are the acknowledged experts in that field.

We don't? More to the point, do we expect them to close a bug related to those things without educating themselves on the subject enough to make a rational decision on it?

I don't think it's reasonable to expect they already know that. Whether they should educate themselves... that's up for discussion I guess. The maintainer here effectively says: I read the docs and don't see a reason for a change; if the docs are wrong, prove it by changing them, if there's a bug in dependency handle the issue there.

It's not the best solution, but if I ignored everything I know about this issue, I think it's a reasonable maintainer's approach.

The probability distribution function of average coder understandable-documentation decays exponentially with subject matter expertise, in most cases. Furthermore, it is often semi-rational, usually unconscious non-/for-profit "job-securitization" to lay landmines and obscure functionality to reinforce in-group, elite, "arcane knowledge" hoarding and seem "expert."

A startup founder often wants to work themselves out of a job to do more useful things, most will do all they can to insulate themselves into indispensability (a lot of technical people are super insecure, I'm proly one of them, and a lot of corporate gigs are cut-throat fiefdoms).

I think it would be entirely reasonable for the person maintaining a Ruby binding for sqlite to follow the sqlite documentation and close any bugs telling them to go against that documentation, yes.

It goes against the Linux kernel documentation, yes. As has been pointed out to them, it doesn't go against the documentation on OS X or any of the BSDs. But they engage in the same behavior on those systems.

Well, perfectly reasonable to take the intersection of capabilities rather than special-case each platform. AIUI the behaviour of /dev/urandom and /dev/random is the same on OSX and *BSD, so there's no problem with their behaviour there.

Except they totally are writing crypto related code. It's called SecureRandom for a reason. If I as a user of Ruby see that code I have certain expectations regarding that. If the Ruby coder maintaining that code is not capable of doing the work required to satisfy those expectations then as I said there is much more wrong than just this bug.

It's reasonable to make this mistake initially sure. But when it's pointed out to you that the documentation is flat out wrong for reasons outside your and others control and you are pointed at articles and research by the experts in this field and you elect to ignore them then the security flaws that will result are very much on you just as much as they are on the linux man page maintainer.

Reply on news.ycombinator.com