sethvargo
Joined 14 years ago
Karma
1,634
Submissions
269
Member since
May 29
Recent submissions
Comment · 4 years ago
This is awesome - congratulations to the team on this raise. Very well-deserved :)
Comment · 4 years ago
The context was introduced by the commenter. The original post does not use contexts. In general, there's a pretty common set of patterns in which multiple goroutines are writing data to different channels, and you need to ensure the data from those channels are processed with some level of priority.
Comment · 4 years ago
Also, this isn't semantically correct. In order to ensure that `conditionaA` is _always_ preferred over `conditionB`, you must also check if `conditionA` has received a value inside of `conditionB`:
select {
case a := <-conditionA:
return a
default:
}
select {
case b := <-conditionB:
case a := <-conditionA:
return a
default:
return b
default:
}Comment · 4 years ago
Right, which is noted in the post. That verbosity is, well, verbose. I generally need this in 20% of things I write.
Comment · 4 years ago
It really doesn't though. It handles the case where the context might have expired or be cancelled, but there's still a race when entering the select between the ctx.Done() and reading from thingCh. You may end up processing one additional unit of work. In situations where the exit condition is channel-based, this won't work.
Additionally, this would only work if you had one predominant condition and that condition was context-based. If you have multiple ordered conditions upon which you want to exit, I can't think of how you'd express that as a range.
Comment · 4 years ago
How would you fix that code?
Comment · 5 years ago
Thanks, I'll take this feedback back to the team.
Disclaimer: I work for Google Cloud.
Comment · 5 years ago
Yup - I can confirm that's the source.
Disclaimer: I work for Google Cloud.
Comment · 6 years ago
The author of this paper alerted Google on June 11, 7:35 AM EST, less than 6 hours ago. While we recognize this is a rapidly-evolving space, a few hours is not in line with responsible disclosure[1] timelines.
While we're still preparing a proper response to the submitter, the paper makes an invalid assumption that RPI rotation and BLE address rotation are out-of-step and overlap. The BLE and RPI changes are synced; the MAC address is always rotated with the RPI/packet is rotated. We're still investigating our implementation to verify, but we do not believe this to be a vulnerability. I will reply to this thread should our investigation find anything.
[ my public key: https://keybase.io/sethvargo; my proof: https://keybase.io/sethvargo/sigs/2iRkeYwEvHo7WUYxCxlrFEDaGCKY-1RJMIF6IUM2z60 ]