D19968 got us closer here, but the link targets aren't actually rendering properly.

The fix for T12921: Link to referenced object in transaction emails (in D19968) is a bit buggy -- the links aren't generating as absolute links with a protocol and domain name. This is likely an easy fix, although I don't expect to get to it tonight.

No one seemed to hate this. I'm not sure it's seeing too much use, but we could grep some access logs eventually.

Nothing really actionable here.

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:

I ran a query against a subset of instances to see if any instances had configured metamta.*.subject-prefix options.

When the time comes, this should almost certainly also handle contact numbers for non-email media (T920 / D19988).

Hey guys,

D19955 has how I think this likely breaks down, I'm not planning to touch it in this iteration since the badness, while bad, is mostly in a box (hopefully) until the next PHPMailer CVE. All yours!

When I was messing around with SMS sending last week, I put a rough cut of this together that is capable of sending an SMS using SNS, which has almost the same API as SES: D19982. I can tackle this unless you're already in the middle of it.

SMS MFA

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: