rsc

9 ms·

61.
by rsc 2y ago
In general there is very little overlap. crypto/rand vs math/rand don't even overlap except for rand.Read, and that was a mistake. We also corrected the import fixer in 2016 to prefer crypto/rand, so no one should have
62.
by rsc 2y ago
It doesn't pick an arbitrary one. It prefers crypto/rand, and has since 2016 ( https://go-review.googlesource.com/24847 ).
63.
by rsc 2y ago
I'm not sure what happened in your case, but it probably wasn't what you describe. We changed goimports in 2016 to prefer crypto/rand over math/rand ( https://go-review.googlesource.com/24847 ), and that w
64.
by rsc 2y ago
That's correct - the state is 300 bytes (36 uint64 + 3 uint32). https://go.dev/src/internal/chacha8rand/chacha8.go
65.
by rsc 2y ago
If I had to guess which of Random and RandomNumberGenerator was the cryptographically secure one, I would have guessed wrong. It's not clear either way.
66.
Secure Randomness in Go 1.22(go.dev)
292 points by rsc 2y ago|94 comments
67.
by rsc 2y ago
(This was posted last week by spacey at https://news.ycombinator.com/item?id=40237491 as well, but that post seems to have been incorrectly buried as a duplicate of https://news.ycombinator.com/item?id=40224
68.
by rsc 2y ago
math/rand is not the speed bottleneck for just about anything, but it _is_ a security weak point in many systems, including systems where you wouldn't at first think there was a security aspect. It makes sense to improve the secur
69.
by rsc 2y ago
It's a different blog post about a different but related topic. Yesterday's post was about API design. This post is about random number generator design.
70.
by rsc 2y ago
> Allowing this to all user packages would be a major improvement over the status quo. We have plans to get there. https://github.com/golang/go/issues/32816
71.
by rsc 2y ago
I see it. Thanks very much! That could certainly be clearer...
72.
by rsc 2y ago
I have looked in the sshd code at https://github.com/openssh/openssh-portable and I cannot find it forking and re-execing _itself_. It forks and execs other commands, of course, and it forks to handle new connections b
73.
by rsc 3y ago
Updated. Thanks!
74.
by rsc 3y ago
The update was pulling from trusted upstream archives. I'm sure Debian verified that.
75.
by rsc 3y ago
I don't think there's necessarily an assumption that it was Russia or China this time (the Chinese-sounding name is almost a dead giveaway that it's someone other than China), but the security world does believe quite strongl
76.
by rsc 3y ago
Two problems with this: 1. Many important contributors, especially in security, prefer to be pseudonymous for good reasons. Insisting on identity drives them away. 2. If a spy agency was behind this, as many people have speculated, those ca
77.
by rsc 3y ago
I think the RedHat Valgrind report on 2024-03-04 made the Jia Tan team panic, since the one public rwmj stack trace pointed the finger directly at the backdoor. All it would take is someone looking closely at that failure to expose the whol
78.
by rsc 3y ago
Hi! Was there any discussion on any mailing lists ahead of time, or was your PR the first public mention of that idea? Thanks.
79.
by rsc 3y ago
Open source fundamentally does not work that way. There are many important open source contributors who work pseudonymously. Google's Know, Prevent, Fix blog post floated the idea of stronger identity for open source in https:/&#
80.
by rsc 3y ago
lcamtuf's two posts argue that this may simply not be an open-source maintainer's job to defend against. ("The maintainers of libcolorpicker.so can’t be the only thing that stands between your critical infrastructure and Russ
81.
by rsc 3y ago
Thanks for this comment. I've added that LKML patch set to the timeline.
82.
by rsc 3y ago
Yes, exactly. I did look at many of them, and they are innocuous. This is all aimed at setting up Jia as a trusted contributor.
83.
by rsc 3y ago
"unauthenticated remote code execution" is a fairly standard term for this kind of access. ( https://www.google.com/search?q=%22unauthenticated+remote+co... )
84.
by rsc 3y ago
It's not as exciting as it sounds. He wanted to play around with learning Paxos, which is a big state machine, and he used yacc to do it. I shared an office with him for a couple years in the early days of Go, and he was working on it
85.
by rsc 3y ago
Perhaps this comment was meant as a joke, but this is exactly what lex does for regexps and yacc does for LALR(1) grammars. For the right job, they are both great. I watched Ken Thompson write a Paxos implementation in yacc once.
86.
by rsc 3y ago
No tattoos although maybe I should look into that.
87.
Running the "Reflections on Trusting Trust" Compiler(research.swtch.com)
287 points by rsc 3y ago|67 comments
88.
by rsc 3y ago
I answered some of this above: https://news.ycombinator.com/item?id=37577312
89.
by rsc 3y ago
If you have tests and they break with GOEXPERIMENT=loopvar, then there is a new tool that will tell you exactly which loop is causing the breakage. That's a post for a few weeks from now.
90.
by rsc 3y ago
Speaking as the person Rob Pike handed the formal power to (8 years ago now), I don't think that change has much to do with it. We've known about the problem for a long time. I have notes from the run up to Go 1 (circa 2011) where

More ›