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.

Among other advanced capabilities, PHP instructions execute too slowly to allow a runtime program to distinguish between L1 cache access and main memory access.

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.

thank you

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 have been trying to see about another way to do this until this is added (if it is I should say). We are finally getting ready to move to Phabricator, and I was hoping there was at least a shortcode or something I can use. Currently what I was trying to do was paste the query URL for a particular project's Passphrase credentials. What we were going to try was getting the query for whichever project's passwords, copying it, and adding it to the Project as a custom link.

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.

I tried a few scenarios for this and wasn't able to reproduce

1. Single commit in diff that creates conflict
2. Multiple commits in diff that all create conflicts
3. Single commit in diff where first commit does not create conflict but second does