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

From https://bugzilla.mindrot.org/show_bug.cgi?id=2496, this is apparently fixed in the OpenSSH upstream (https://github.com/openssh/openssh-portable/commit/ddd3d34e5c7979ca6f4a3a98a7d219a4ed3d98c2). Since this is a bug in OpenSSH, an upstream fix is available, and the impact is fairly narrow, I don't plan to work around it in Phabricator.

See D17458 for the previous, narrower case of token revocation in response to Heartbleed (T12313).

This is either T4675 or T6004. I don't know which will happen first, but I'm just going to close it in favor of those.