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.

Use diffusion.repository.search or phid.lookup to map repository identifiers to PHIDs.

I think it does, but only if you ever don't have a profile picture:

This is extremely old and doesn't have any use case information, which we require for modern feature requests (see Contributing Feature Requests).

(Just closing this since we haven't seen an update in ~4 months and it isn't actionable.)

This isn't a bug; the cURL request is not a websocket request.

Per the latest update in D17502, this remains involved.

The segfaults appear to have subsided for me so I'm just going to close this as "upgrade to PHP 7.1.2".

While we haven't been showered in free money, I also haven't seen more reports of this so I'm going to presume it's resolved.

I may still do a bit of a UI touchup pass here but this can follow up in T10967, since there's still some other work to be done there (like purging the old double writes).

This appears to now be resolved for me, presumably by the fixes for T12079 and T12219.

I think this got fixed by D17483.

I'm just going to merge this into T8033 since I our intent there is to prevent this situation entirely.

T12335#214054 discusses some future/followup work, but that can be filed separately as it becomes relevant.

From elsewhere, it sounds like this is working.

See "git push = save changes" discussion in T5000.

We don't know how to reproduce this, so we can't move forward.

We don't have any way to move forward here.

We don't know how to reproduce this and can't move forward.

We don't know how to reproduce this.

That's expected, and not a bug. "Blocking" is currently a top-level status. When a reviewer becomes "Rejecting", they are no longer "Blocking". This doesn't matter in terms of the workflow, because both "Rejecting" and "Blocking" prevent a revision from transitioning to "Accepted".

See T12515 for followup guidance.

I'm going to merge this into T11314, but I don't want to hard-code rules around specific names used by GitHub/GitLab. We can provide more tools to manage these refs, but I don't think the right tool is a bunch of hard-coded rules. These refs are real refs which exist in the repository, and Diffusion should be able to represent them. A driving use case for the original change was a desire to expose Gerrit refs.

I think things should work now, let me know if you're still seeing issues. Thanks for the report!

Argh! I broke it while doing last-minute fixes to improve rendering, fix in a moment.

Thanks, that definitely looks like a bug.

I gave a trivial example as that is better than a complicated one.

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

See T12511#218328.

There is basically zero chance we're going to implement parameterized templates which can call one another (easily dozens of hours of work) if the only real use case is making RFC5555 autolink (works today with InlineRule, takes a few minutes to make work).

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

I'm having trouble reproducing this, but maybe I'm not fully understanding what you're running into?

Some guidance about "configure captchas if you're a public-facing, password-login install" would be good here too, but maybe we should just raise it as a setup issue if you have password auth enabled, and let users ignore it if they're VPN'd.

T12511 discusses some possible use cases, but they are all in the form of {{name|123}} expanding to [[ something.com/123 | 123 ]] (external bug trackers, RFCs, etc).

In the future, please report security issues via HackerOne: https://hackerone.com/phabricator -- notably, this allows us to award you a security bounty if you discover an issue.

yeah, sorry, in retrospect this is a real underwhelming test

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

I deployed that and created this masterpiece:

Almost certainly fallout from the increased strictness in D17616, thanks.

I'm going to call this resolved; T9979 is the survivor for Files and the Maniphest case is probably more involved (T6721).