Presuming this is resolved since we've seen at least some confirmation that it fixed issues and aren't aware of any remaining outstanding problems.

Worth noting that the desirability of self-notifs is highly contextual. We use gmail, I was shocked to find there is no way to get gmail to let me see my own posts. But then I'm one of the few people using a local mail client, and it is actually kind of annoying when I have to slog thru the copies of the self-notifs on my phone to try and get to the one comment in the midst of potentially dozens of self-notifs.

See PHI185. This was fixed by D18753 but didn't get linked up.

Maybe this works now?

I'm going to roll this up into T13047 since this stuff needs a rebuild in general.

Per above, I think the pathway forward here is probably "tighter integration", not "merge/replace", i.e. tools for Diviner to automatically update Symbols, too. I'm just going to conceptually roll this up into T13047.

I think this probably isn't worth fixing in the upstream: different versions of PHP are mostly the same; there's usually a good argument for deploying the same version of PHP everywhere; and Phabricator supports both very old and very modern versions of PHP so it should usually be easy to run Phabricator on whatever version of PHP you're developing against.

I believe this is supported now (and for some time) in the general case in terms of Phabricator infrastructure. Actually getting it to work requires a very smart highlighter, and the upstream XHPAST highlighter is the only one in existence. But other tasks, like T3130, are better homes for parser/AST improvements to particular languages.

To reproduce:

Add a temporary token revoker.
Add a session revoker.
Add an SSH key revoker.
Add a password revoker.
Add a VCS password revoker.

This is at least fixed in theory. To verify it, I waved my cursor over a revision's table of contents and didn't see any periods.

The other thought I had was that using a cooperating subprocess and emitting signals to tell it to click a nanosecond-precision stopwatch might also make the attack more practical (or use pipes or domain sockets -- however you can get out of PHP with the lowest cost). They're probably all somewhat slow but likely better than microsecond-precision. Then you "just" need to get a cooperating binary onto the target host.

Wow, I didn't mean for my two cents' worth of snark to cause such a stir! I do buy the argument that Phabricator isn't impacted by Meltdown/Spectre ("At least today, Herald rules are insufficiently expressive to allow an attacker to encode a speculative execution cache timing side channel attack.").

As some general commentary on this:

@20after4, heads up that we're going to start exposing pull logs, which contain remote addresses in the upstream. The visibility policy will likely be similar to push logs.

I believe this has been supported since D11543, in 2015. Specifically, log.ssh.format supports %k, and it appears to work as expected.

I thought there was one in Diffusion too

This will break existing anchors (depending on how much we change the algorithm), although that's probably not a huuuuge deal.

I think these already broke once from D18465 and presumably it hasn't caused issues for anyone

This can be fixed by adjusting the regexp in PhabricatorObjectRemarkupRule->getObjectReferencePattern() to accept ., but then we'll match #xxx. as an anchor. In most cases, a terminal period is probably a punctuation character, not an anchor, like: For details, see D123#abc.

Yeah, file a new task? I spent 5 minutes looking at this but it isn't entirely trivial. Immediate issues are:

A minor thing I noticed recently with this is that remarkup linking sometimes won't work if the generated anchor for the file contains . (and possibly other characters). See
https://secure.phabricator.com/D18465#change-cv4o_.vkNhKk
D18465#change-cv4o_.vkNhKk