From https://bugzilla.mindrot.org/show_bug.cgi?id=2496, this is apparently fixed in the OpenSSH upstream (https://github.com/openssh/openssh-portable/commit/ddd3d34e5c7979ca6f4a3a98a7d219a4ed3d98c2). Since this is a bug in OpenSSH, an upstream fix is available, and the impact is fairly narrow, I don't plan to work around it in Phabricator.

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.