fidget

Yeah, we really should rewrite the kernel.

That's GRSecurity for you

Man, I've got some horrible news about your CPU.

There are other bad things about ssh. Tofu sucks balls and ssh users are far too comfortable with it.

Doesn't particularly make a difference, given that this issue is about users not upgrading (for whatever reason) their windows XP installations. Would the exploit having being disclosed by the NSA or by someone else have changed the fact that these users would not have upgraded and gotten a patch?

His arms and influence is also changed the way I view conflict between states.

It's not strongly coupled beyond requiring that the wrapper implement a `Cause() error` method. I don't really think that could ever be considered strong coupling

So short it

Please let me know where you work, so I can avoid any product potentially produced by you.

Are you suggesting that you had a concurrency bug that was solvable without changing your entire storage layer? Heresy..

No one does, you estimate each task to have a different number of points, which modify the task's contribution to the burndown graph.

I guess the idea is that points should correlate to time (questionable), and if you're estimating perfectly, that should give you a linear burndown graph. Which is stupid. What might be less stupid is that if you want to get some idea of how well your team is estimating tasks, compared to i.e. this time last year, you could look at the volatility (across several sprints) this year compared to last year, and a lower burndown rate volatility might suggest that the team has improved at estimating the duration of tasks.

However, when you just focus on the volatility as a metric, then people start optimizing for it, which is not the point at all.

Isn't anycast ip usually used for that instead?

Right, which is why I said those blackbox methods were pretty rubbish. You step through it with a debugger.

Unannounced side channels seems like by far the easiest thing to deal with there; send a 2mb file, observe network patterns, raise an eyebrow if 2mb gets sent over a channel that you didn't expect.

As for using the correct key, dismantle the signal message envelope until you get your blob of encrypted message. Then see if the same blob appears on the target device. Multiple keys? I imagine either correlating message size and network traffic (encrypting stuff twice could well show up), or going at it with a debugger.

Which is really the answer to all of these questions instead of any network shenanigans. You root your phone and attach a debugger, then step through what signal is doing.

Not a security researcher, never reverse engineered anything for security reasons in my life.

Phew lad. You're a bit far gone aren't you.