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.

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.

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.

See a note in T12509 about HMAC key regeneration.

See PHI500 and T13179. Recent versions of SSH support passing the key fingerprint to the AuthorizedKeysCommand by specifying it like this:

D19935 prepares for multiple MFA provider types.

Maybe worth a mention -- GHC is another somewhat-similar project and moving to GitLab (e.g., https://mail.haskell.org/pipermail/ghc-devs/2018-October/016425.html). It sounds like GitLab is currently better able to spend resources to support free users with relatively non-mainstream use cases than we are.

I think a lot of this behavior may be fairly unique to the LLVM project, since we've never really received this general class of feedback from other installs (except, perhaps, FreeBSD, which I think is somewhat culturally similar).

This is the most upsetting bug in the software.