There are some remaining non-security bugs with this that I'll follow up on in T13682. I believe the security side of this is now resolved.

The details of this attack will be disclosed at a later date, once installs have had some sort of plausible chance to upgrade.

I believe D21811 covers this completely.

Just for visibility, this is I believe the change that broke Diffusion (which was fixed in rP52df4ff515b7), where the error message is something like

I believe these were all hunted down.

I deployed this everywhere in the Phacility cluster yesterday and things have been quiet, so I'm assuming it worked until evidence arises to the contrary.

D21756 effectively makes all Git pathways call setSudoAsDaemon(true).

Just for visibility, the error messages you'll see if you're affected by this issue look something like this:

...maybe this is an actual bug in Phabricator where some pathways are just missing the "sudo" wrapper?

I'm satisfied that we aren't violating our commitment to our customers by continuing to use Mailgun as a service provider...

Yes. I closed down registration on this install (secure.phabricator.com) several years ago because the overwhelming majority of users who registered accounts here didn't read or follow the rules. Access to secure.phabricator.com is now invite-only.

In T13589#254320, @epriestley wrote:

Please use Discourse to report bugs.

Please use Discourse to report bugs. See https://discourse.phabricator-community.org/t/repository-view-git-command-failed-error/4510/.

It works with Git 2.1.4 (shipped with Debian Wheezy), but not with Git 2.20.1 (shipped with Debian Buster), or Git 2.30.0 (latest version).

My apologies if this is not the right place to post about this, but seems like due to ea9cb0b625fb6922c45aecbfdebacc60788ed92d we now get following error message when visiting diffusion repository page, i.e. URL /diffusion/$REPOID/:

This could be made slightly cleaner with a setSummary() to set a shorter summary:

hmmmmmm

Some guidance about "configure captchas if you're a public-facing, password-login install" would be good here too

After T13222, this is more relevant:

From T13222, MFA on related flows should generally be updated.

Thanks! I get the same behavior locally, I filed this upstream: https://bugs.php.net/bug.php?id=77496

I can't get MYSQLI_OPT_LOCAL_INFILE to work on secure, either. I tried on secure001 and secure004 (where the database is not local). As far as I can tell, this option doesn't do anything, anywhere, ever?

We're probably done here, but ideally the next steps are:

Maybe another point in favor of this claim is that the option does not work is the behavior of this:

I think that maybe mysql_nonapi.c just overrides the conn->options() call? Near line 269 of PHP 7.2.3:

I can't get MYSQLI_OPT_LOCAL_INFILE to work on secure, either. I tried on secure001 and secure004 (where the database is not local). As far as I can tell, this option doesn't do anything, anywhere, ever? I'm going to look at the source and see if I can figure out what's going on, but I'll back it out of D19998 if I can't find some evidence that it's useful.

I'm unable to get the MySQLi option MYSQLI_OPT_LOCAL_INFILE to actually work. Here's the script I'm using:

It looks like we don't need to do anything about mysql on the CLI since this option is, thankfully, not enabled by default:

Performing this "attack" requires administrator privileges and probably some weird social engineering around making the "Reply All" happen.

When Phabricator receives the mail, it doesn't know which "To" or "Cc" actually caused delivery

In moving forward here, we're generally moving from manually-configured HMAC keys to automatic ones. This is generally good: it's simpler (less configuration); and I believe almost no one configured the old ones, so installs now actually get unique HMAC keys; and the new keys have more entropy, too.

See a note in T12509 about HMAC key regeneration.

After the stack of changes under D19897 land:

This appears to be stable and working properly. D19897 removes a straggling guardrail.

I think we're going to fix this with T7667 instead. Binding to a particular domain creates headaches if you actually move the LDAP server, and unlocked authentication creates a lot of other problems that we can't address in a similar way.