PHP allows and evaluates these constructions:

Some followup SHOW INDEXES from the case in PHI47 provided output which didn't have any evidence of key cardinality issues, so it seems less likely that this is a cardinality problem.

bin/storage adjust and bin/storage upgrade now run ANALYZE, unless users opt-out with flags.

I think there will be a trickle of these for a while, but we seem to have found the most common cases.

Practically, msortv() and PhutilSortVector are now the solution here. They provide high-performance (no usort*()), multi-dimensional, stable, explicitly typed sort.

We appear to have survived this. D18398 removed the double writes. There's a bit more cleanup (we could remove the edge type and actually destroy the older data) but that can happen whenever we get around to it.

This doesn't affect us, but more fuel on the fire -- XSS in example code which ships with PHPMailer (we don't distribute this code):

That sounds right to me.

This looks pretty easy. No mentions of DifferentialDraft in the codebase other than the class itself and a single migration. Steps here (I think) are:

Totally my fault, I just didn't read half that sentence. 🐈

Thanks for looking into this so quickly.

And thanks for the report! Let us know if you run into anything else.

D17687 should dirty the cache properly on username changes. It should promote to stable within the next ~12 hours, and deploy to Phacility production about 24 hours from now.

I was able to resolve the issue by deleting my user's ssh key, and uploading the original ssh key material as a new Phabricator sshkey.

See also somewhat-related task T12397.

I've been doing production deployments with this for a while without hitting any meaningful issues. It's not general-purpose yet but followups can live in Phage from here on out.

(That said, the hash cost may become very relevant when we eventually ship "Phabricator Valuable Golden Coin Money", our blockchain-based virtual currency.)

I get these rough per-hash costs locally (Macbook Pro), with a 64-byte key:

Piece of info (you guys might already be aware of it) which might be of interest when implementing this; SHA512 is often faster then SHA256 on x64. See for example: https://crypto.stackexchange.com/questions/26336/sha512-faster-than-sha256

I'm maybe going to try to do this in the short term:

(This isn't really very closely related to the Files application anymore, just cleaning up that board a little.)

The workflow thing is somewhat nontrivial. Previously, we would explicitly downgrade "Accept" into "Accepted Older" when an author used "Request Review".

From D17564, there's a minor workflow issue with "request review" incorrectly putting accepted changes back into an "accepted" state from this.

Hmm. Ok. Deleted.

Specifically, this task is about how the javascript in typeaheads rank and match choices.

Not similar.

Downgrading accepts and rejects (changing "Accepted" into "Accepted Older") uses raw edge transactions.