See D17458 for the previous, narrower case of token revocation in response to Heartbleed (T12313).

This is either T4675 or T6004. I don't know which will happen first, but I'm just going to close it in favor of those.

I've marked D18879 as fixing this. It does not extend bulk editor support to all custom field types, but makes such support generally trivial. We'll fill in and test more field types as use cases arise.

I've marked D18863 as fixing this. This doesn't expose bulk editors in all applications, but generalizes all existing bulk edit operations and makes the process of adding more bulk editors straightforward.

I've marked D18867 as fixing this. It isn't a perfect fix, but it's closer to the realm of reasonable (you have a sensible amount of area to work with and a readable font):

After D18868, which rewrote the relevant code in the bulk editor, I can no longer reproduce this. My expectation is that the modern pathway these edits take can correctly collate multiple edits to the same field.

In theory, yes. But I suspect the actual required sample size may be on the scale of "heat death of the universe", potentially making this attack less practical than just brute forcing whatever secret you're trying to extract.

Tangential, but T8768 is a case where we generated an unfaithful synthetic diff (a diff --git that the git binary could not generate since 2006) and took the blame for it.

I'm not totally sure all variants of this are fixed, but I don't know how to reproduce any remaining issues.

I filed a summary of this in the Mercurial upstream to waste someone else's time so I feel better:

This is an explicit behavior in Mercurial and dates from 2007:

The rule Git uses appears to literally be "does the filename include a space":

I'm going to close this since it was mostly answered and the remaining questions (about custom extension development) are outside the scope of modern support. See T13039 for a followup about numeric fields in Herald.

Ah, thanks! This is probably effectively covered by T9948 anyway -- one of the major changes for the Git flavor of that (T9657) was "put things back the way they were when anything goes wrong, even if we discard merge/rebase work", and that seems like a better behavior. I'll make a note there just in case.

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.