41–50 of 138 posts
Is there a good random library that's not the giant ball of death that's OpenSSL?
I've used Mersenne Twister[0] in the past. [0] http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html If you're talking about an RNG library for cryptographic purposes, then it depends on your use case.
https://github.com/technion/use_urandom
Note I said "start", so I'm aware it needs work. Feedback is appreciated however.
Earlier quoted context omitted.
Yes, it's just you. The core ruby team is mostly Japanese-speaking, and Japanese developers are less likely to speak English well even than people in a lot of other countries where English is not a common first language. I think that does serve as a barrier to communication and transparency (with/towards English-speakers!). I think that's all there is, nothing "about Asian culture", or "decisions are made as a group…
Thanks for the enlightenment, I didn't know this aspect of the Ruby core team.
Here's a useful (to those curious to learn more about ruby committers) interview from 2013 with 15 ruby committers, note the questions and answers have been translated between English and Japanese. http://www.sitepoint.com/meet-fifteen-ruby-core-committers/
My impression is that a lot of discussion on MRI happens in Japanese on Japanese listservs. Of course, it doesn't take a language barrier to make things seem not so transparent -- for comparison a few years ago, Rails core team started taking the majority of their discussion to private core-team-only listservs. (I gather because they were finding dealing with the peanut gallery made it too hard to get things done/decided). At least there's still lots of open (and English-language) communication on the github issues or open listserv, but there are often times when I'm not really sure who or how or on what basis architectural decisions are made for Rails too, a lot is done in private, is my impression.
But I suspect to curious Japanese-speakers, MRI development may even be _more_ transparent than Rails is to English-speakers! I think (but not entirely sure) all of the listservs MRI devs use to collaborate are actually open -- you just have to read/write Japanese to understand what's there or engage effectively. :)
Why haven't the urandom man pages been fixed yet? Is there, like, no process for fixing man pages at all, they just wind up set in stone forever?
So bug report understates the issue, nobody has gotten around to writing a good quality patch, everyone is just loudly complaining elsewhere.
So once again, the man page for urandom creates more problems than solutions. ( https://bugzilla.kernel.org/show_bug.cgi?id=71211 )
Well, to be honest, this isn't the man page creating problems; this is the Ruby core team stubbornly refusing to fix a known problem. Using the man page as justification for their refusal is both stupid and weird. Who uses the Linux man page to determine their security?
Earlier quoted context omitted.
Why is there such a discrepancy between the prevailing sentiment on HN and the actions of whoever controls the manual? What is preventing one side from convincing the other, apart from stubbornness? Also, why are the Ruby devs so dead set on the manual page?
It's not the prevailing sentiment "on HN". It's the prevailing sentiment among virtually all experts everywhere . I can make a list of those experts, but I'll leave it to someone else, so as not to bogart an lay-up high-quality upvote magnet comment. The reason this is a problem is simply that the Linux maintainer is obstinately wrong. Theodore Ts'o was on HN a year or so ago, and in defending the current design (and…
Is there a good random library that's not the giant ball of death that's OpenSSL?
As others have said it depends on your needs[6] and whether or not it has to be a CSPRNG (cryptographically secure). Since you mentioned OpenSSL I'll assume that in this context we are talking about a CSPRNG. The short answer is to just use the OS provided one if available. Linux has /dev/urandom[1] and the getrandom[2] syscall and Windows has RtlGenRandom[3][4] (there's also CryptGenRandom on Windows which is the "o…
Earlier quoted context omitted.
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.
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 dat…
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?
Why haven't the urandom man pages been fixed yet? Is there, like, no process for fixing man pages at all, they just wind up set in stone forever?
If you look at the bug filed against the man page, it doesn't exactly make a strong case. It just suggests some weasel words, about qualifying "large amount of data" etc. ( https://bugzilla.kernel.org/show_bug.cgi?id=71211 ) So bug report understates the issue, nobody has gotten around to writing a good quality patch, everyone is just loudly complaining elsewhere.
But you may make a good point that perhaps nobody has submitted a good patch yet -- you're right that issue isn't a good patch, just an invitation to enter into a discussion toward one (an invitation that doesn't seem to have been taken up, at least on the issue tracker).
One would hope that the actual maintainers of the kernel subsystems would feel responsibility to improve a clearly insufficient man page. Which makes me suspect there are some underlying politics or personality conflicts going on. (Or just burn-out?)
But if all it needs is someone to write some good text -- is it really the case that none of the cryptographers who have been writing extensive blog posts about this for years care to submit a doc patch? If so, I wonder why?
Perhaps, just guessing, another potential issue is that nobody really wants to _take responsibility_ for such text, in case they make a mistake. So the existing clearly insufficient text remains. Tragedy of the open source commons?
Earlier quoted context omitted.
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 dat…
> 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?
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.