(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).

Just dropping this here since it's the first hit for "SAML" and makes it easier for me to contextualize things when I quote $50K for it, which I'm starting to think is too low:

The HackerOne issue for this is here:

The security part of this is fixed by D17625, but I'm planning to write a support script like bin/files integrity or similar to do things like "compute hashes for existing files" and "check that a file or set of files match their integrity hashes".

This appears to be resolved for me, now. Handling Range: bytes=123- and Range: bytes=0- (plus the fixes for the broader issues in T8266 and T12079) seemed to be the key issues.

F60036 now plays correctly for me in Safari.

The video in T12078 now plays correctly for me so I think this is, in fact, resolved.

T4721 (which I also linked on the HackerOne report) discusses usability improvements to Passphrase, including better documentation and hinting about this use case and possibly the separation of the "Can Use Credential" and "Can View Secret" policies. These are reasonable usability concerns.

You can review the HackerOne report, including my response, here:

After D17614, arc download uses file.search to retrieve a URI it can GET, then does a normal HTTP GET to that URI, retrieving the file content in the HTTP response body.