We received our first credit card dispute on January 31st.

See some additional discussion in T13060 and T7339. Pretty much everything here remains unchanged, but those tasks discover an additional constrain: a parent process has LANG=POSIX (or similar, some non-UTF8 locale), it can not pass UTF8 to subprocesses in argument lists.

See T13060 and T7339 for followups and additional discussion.

D18988 addresses the issue from D18105 (git grep 🐑 fails) more directly by calling @setlocale(LC_ALL, 'en_US.UTF-8') unconditionally during startup. The motivating case in T13060 is:

(Future me, see also PHI343.)

I think I didn't kick Apache hard enough since I eventually rammed this through with setlocale().

setlocale(...) doesn't (?) appear to work from within Apache (?).

Thankfully, it seems that setlocale(LC_ALL, 'en_US.UTF-8'); from within PHP does work, so we don't need to figure out what PAM initialization cache file Ubuntu is actually reading LANG settings from.

sudo update-locale LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8 also does not work, although this is apparently just a Perl script that rewrites /etc/default/locale for you.

Setting LANG in /etc/environment had no effect on anything.

I now strongly believe this is some kind of terminal environment problem. This script has different behavior in production and on my laptop:

No luck, I don't even see any bugs in Differential locally with that change (the en-dash decodes and renders properly). So this might be in the realm of T7339.

Same result.

Same results for spaces.

To try to reproduce this, I did this:

Vaguely related, the subject line for this mail is currently something like:

🐱 🐟

contains complex HTML elements (like inline comments) which would also need to be stored in a structured way and then rendered just-in-time

While it's on my mind -- these messages link to /mail/whatever/123/ right now, but that page doesn't hyperlink links in the mail body, which is a fairly significant usability issue since the workflow is: click the link to go to the mail, read the mail body, copy paste the link in the mail body into your address bar.

This report doesn't include working reproduction instructions so we can't move forward.

I can't reproduce this; it may have been fixed by D18776 + D18778.

My call with Mailgun was generally reassuring. Based on an uncharitable reading of the January 5th disclosure, my major concern was that they might be starting from a cultural position which was blind to internal actors as threats and everyone just used root / hunter2 written on a sticky note to log in to everything or something like that.

I suppose another reasonable attacker is "laptop thieves", but deleting any locally stored mail which was accidentally transmitted in the open seems like a reasonable way to recover from any confusion that arises until we figure out how foolproof the behavior needs to be.

The intended trigger for "Must Encrypt" is Herald rules like this:

The "Must Encrypt" change will necessarily link into the existing /mail/ web UI so users can read the mail content, so it's probably worth considering possible improvements.

Although I'm suppressing the X-Phabricator-To and X-Phabricator-Cc headers for "Must Encrypt" mail (and the "To: ..." and "Cc: ..." footers in the body), the recipients will still be visible in the actual "To" and "Cc" lines if metamta.one-mail-per-recipient has been configured to false instead of the default (which is true).

On Thread-Topic, this very old thread suggests that Outlook can show the header in some cases: https://bugzilla.mozilla.org/show_bug.cgi?id=411601

From rereading D18600, maybe "ridiculously strong" is an understatement and it was actually so powerful it took effect even if you didn't enable it.

Locally, seems like "No Notifications" correctly has no effect on the "Upload" bubble being shown at HEAD of master.

Not unless something super weird/buggy is going on.

It's possible that adjusting Settings → Notifications to No Notifications disables this bubble, if that's a compounding factor here. D18600 pulled back some of the aggressiveness of that setting but I'd guess it might still be hitting the upload progress bubbles.

What browser are you using? I get a progress bubble in the lower left immediately. Here's a screenshot -- note the blue upload progress element in the lower left corner.

I think T11934 and an explicit !claim Txxx action (which would mean "reassign + ref"; maybe with a !claim-and-fix Txxx to mean "reassign + fixes" or some kind of !claim+fix X syntax which expands to !claim <args>; !fix <args>) is a possible way forward on this, but I don't want to make "ref" automatically mean "claim".

Because of the high degree of complexity there's basically zero chance we'll ever build this without active customer interest, and we have none today. Closing this until interest arises.

We don't have any use cases for this today so I don't plan to pursue it. It's conceptually reasonable, but complex, and there's no customer interest.

T11934 is a possible way forward on this (and other niche things) without adding a lot of Javascript and UI complexity, by supporting it through !fixes.

One possible approach for this is:

I'm going to roll this forward into T13057.

We shipped "Mentions" and "Duplicates" some time ago.

See T13056 for followup.

One attack is that you can override the content of email and then send invite or welcome mail that says whatever you want, whether the victim has a Phabricator account (welcome) or not (invite).

After T13049 this is relatively within reach, but we haven't seen other requests for it so I don't currently plan to pursue it.

This is relevant now that work related to T13049 has added CSV support.

More or less obsoleted by work in T13049.

That's as far as I plan to take this for now. I think the additional features described above (filter, reorder, reformat, and broader field and application support) are all reasonable if use cases arise, but am not currently aware of use cases. We can return to that stuff when use cases arise.

I just let that run for a while but it finished at some point:

I'm going to roll this forward into T12677 since SES managed to one-up this by a healthy margin in T12237.

(They got back to me and we're scheduling a call.)

Mailgun has yet to respond to me after about three weeks, so I send them a followup.

The compaction completed overnight. I'm optimizing the tables now.

Pool is full again, repo is upgrading, edges are compacting on the instance shard.

web004 is deploying now.

web004 died abruptly so I'm going to fix that and deploy these changes at the same time.