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.

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.

PHP allows and evaluates these constructions:

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.

T10604 and T4369 do not impact LFS (broadly, they apply only to POST requests, and LFS uses PUT to upload data).

Adjacently, some other parts of the UI currently use the word "enormous" (see https://discourse.phabricator-community.org/t/herald-enormous-check/822). They should be rewritten to use different language (like "Very Large"). We should use the term "Enormous" to mean only "too large to process completely", while the other UI uses it to mean "large enough to partially collapse for viewer convenience".

Also, while it's on my mind, all repositories should probably have this rule today:

See T7789 and D18827. Block Git LFS in some repositories:

See PHI242. SR Latch:

D18831 should upgrade this from "horrible fatal" to "reasonable-but-not-ideal normal page". This could still be improved (providing the user more information and taking them into the submodule redirect workflow) but it's normally difficult to end up here without trying.

We have an outstanding support issue (PHI204) about timeouts with large files.