Another quality Security update from Phabricator! 🐕

Mostly from the HN thread, other possible providers we haven't tried yet include Mandrill, Postmark, and Sparkpost.

T12677 documents previous general issues with mail providers. Mailgun gets the worst of it there, but just because we've been with them for a while without anything too awful happening.

The install in PHI271 reported this as fixed after upgrading.

After D18857, I'm not aware of any remaining, reproducible issues with Mercurial. If you're still encountering protocol issues after upgrading through D18857, let me know how to reproduce the problem you're seeing.

T13036 is a more focused rebrand of this issue, since this has a lot of philosophy and not a lot of actionable reproduction steps. The three line fix in D18857 may have resolved these issues.

Mercurial's protocol negotiation presumably considers the size of the change being transmitted in selecting the protocol format

I think D18857 fixes the pipe issues. Here's the problem:

Here's some evidence [that filtering bundle2] doesn't work:
we attempt to filter the protocol and tell the client that we don't support bundle2

Actually, this is less crazy than I thought.

This appears to date back to the introduction of the feature in D5738, where I suggested we use ancestors() without a legitimate reason (or maybe very old Mercurial had weird behavior).

We can't reproduce this, and can't fix issues we can't reproduce.

This is possibly connected to T9548 but we don't know how to reproduce this and can't fix issues we can't reproduce.

Hi @tappers, I can't get your query flow to work on my machine, would it be possible for you to give me a simple example of a working query ?

Yes. I am also looking for shortcuts even as simple as closing the current task. Currently we need many mouse clicks: 1. Add Action.., 2. Click Change Status, 3. click submit button, totally 3 mouse moves.

I second this:

FWIW, I am using a custom file and mail engine that utilises the AWS SDK and supports instance profile credentials. See P2082 and P2083. You need to install and require the AWS SDK before using these extensions.

T13023 provides an example of a synthetic "git-like" diff generated by some tool (dpkg-source?) which appears (?) to pretend to generate Git diffs (diff --git in the text).

I'll merge this into T12664, but realistically it's exceptionally unlikely that we'll add the ability to parse these diffs given one example and no idea how to generate them in the general case, and apparently only one install encounters these diffs, and they aren't generated with a legitimate VCS tool.

The fix for T13031 may have made this worse by default, since we now extract all pushed changesets and hold them in memory by default, even if no Herald content-based rules which use them actually exist. This may create too much memory pressure if you push a very large number of commits.

The chatbot was removed completely in D17756.

unfortunately, this no longer exists, is there a new documentation for it somewhere?

PHP allows and evaluates these constructions:

D18836 probably isn't the right solution, however, it's the only straightforward fix I could come up with. I didn't dig into the details of why it 404s when I fix the code in PhabricatorProjectViewController to avoid the fatal. The patch is probably good enough for Wikimedia, however, I'm not sure if it's good enough for upstream.

With T13001, the commit page itself now gives you disambiguation options if the commits are in the same repository. This is a narrower case than ambiguous commits across multiple repositories, but related if we did pursue something like hovercards or a multi-repository disambiguation page.

T13028 is a followup but I think everything else here is resolved.

Another approach that might make sense would be to highlight the hash and then show a hovercard which lists the commits with that hash. Of course this wouldn't scale too far but it should handle the case where 2 or 3 commits have the same hash.

I tried to work around the immediate fatal by checking the return value of $engine->getDefaultItem() in PhabricatorProjectViewController, however, that resulted in hitting a 404 so it's a bit deeper of an issue. Perhaps the right solution is to prevent users from disabling both of the default items in the project "manage menu" UI?

The apparent lack of support for scheduling in UTC in much more mature calendar software (Google Calendar / Calendar.app) further suggests that this is not an important feature for most users.