since there's a bunch of errata collected here

One issue here is that existing MFA factors now require a concrete Factor object to associate with. To preserve existing behavior, we'd need to create a new one automatically on all installs. This inevitably turns into a little bit of a mess where we have some builtinKey factors and some organic factors. Nothing terrible, but not especially clean.

(I'm not 100% sure that D19972 fixes this completely, but it appeared to locally. In the future, "Mail Stamps" should include this information in a more reliable format, although they do not currently include transaction information. See T13069.)

PhabricatorObjectRemarkupRule->renderObjectEmbedForAnyMedia() currently calls renderObjectTagForMail() unconditionally when we're in HTML mail mode. This always renders a (F123: Xyz) element.

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

This isn't trivial to resolve. The inverse transaction goes through standard "old value / new value" logic, so if we just move the entire "apply inverse transactions" block to later on, the transactions automatically no-op themselves: they do nothing by the time we apply them.

I made this edit:

Unsurprisingly, I think this is a race condition.

The replacement should also setTimeout(...), per T5969.

See also https://discourse.phabricator-community.org/t/suggestions-show-failed-email-in-ui-send-test-error-console-output/1844.

Currently, the SES adapter extends from the Sendmail (PHPMailerLite) adapter. I'd like to fix this.

So I don’t see why that logic would be necessary. ... Pushing to the referenced branch never changes the ref to the branch itself. Only branch deletion does/can.

If the answer to (2) is "yes", we should detect that a commit deletes the HEAD ref and remove HEAD before accepting the commit. This may be quite difficult if hooks don't get to run before the HEAD check runs.

There is a Migrate from Google+ Sign-In howto for web apps.

Currently, the SES adapter extends from the Sendmail (PHPMailerLite) adapter. I'd like to fix this.

The other component of that report is that there are 32,768 low-entropy "2048-bit" RSA keys which Debian systems generated until ~2008:

See https://hackerone.com/reports/474897, which suggests that ssh-keygen -l ... ("Show fingerprint of specified public key file.") is probably a pretty good starting point for ssh --is-this-a-valid-public-key:

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

I'm more about not living that Homebrew life.

This doesn't help if you're committed to that Apache life, but FWIW I'm using nginx 1.15.8 via Homebrew on Mojave without any issues.

Since T13227 has an actual realtime deadline, that's probably a good time to take care of this, too.

This can be implemented as a third-party extension. We're unlikely to ever pursue it upstream without customer interest.

I'm going to merge this into T12738. Although that task primarily discusses Nuance as a Phacility support tool and we ended up building a standalone Support tool instead, I generally believe Nuance is the most likely pathway for interactions falling under the general "helpdesk" umbrella.

I'm going to merge this into T12738. Although that task primarily discusses Nuance as a Phacility support tool and we ended up building a standalone Support tool instead, I generally believe Nuance is the most likely pathway for interactions falling under the general "helpdesk" umbrella.

I'm going to merge this into T12738. Although that task primarily discusses Nuance as a Phacility support tool and we ended up building a standalone Support tool instead, I generally believe Nuance is the most likely pathway for interactions falling under the general "helpdesk" umbrella. That is, the future for these use cases mostly looks like "lightweight/external users interact with Nuance, then staff triage issues into other objects like Tasks that only real users interact with", not "lightweight/external users interact with every application and every application gains support for email/external/grey interactions".

I ran a query against a subset of instances to see if any instances had configured metamta.insecure-auth-with-reply-to, to get a sense of how safe it is to remove this option.

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.