That's OK.

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.

Just tested, works great. Thanks for the quick fix!

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.

No prob! If it helps:

Thanks, that definitely looks like a bug.

Not sure if this is a known bug / missing feature, but FYI just in case...

@avivey I was hanging my head in RTFM shame, TBH.

No. You should list the (actual, real, day-to-day, not theoretical) things you want to be able to do that you currently can not, or which you do at significant time or complexity cost through cumbersome workarounds. Optionally, you might also say "in other cases, we currently use Wikimedia templates to solve these". Suggesting a solution is the least important part of a feature request.

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

I gave a trivial example as that is better than a complicated one. In a huge wiki, like Wikipedia templates are used for all kinds of things besides making links simpler.

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

T12511 is about a very different problem and use case. This request is about adding a feature that "will allow users to quickly create a wiki page with some specific base content.". T12511 is about adding a feature that lets users create a bit or markup that acts as a macro/function/template that generates a few lines of markup within a page.

I do not think this is a duplicate. T3963 is about creating template Wiki pages that start off ready populated with some basic data. This request is about creating a Macro like tag (which is part of the Templates feature in WikiMedia markup) not about creating pre-canned pages.

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 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

am disappoint

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.

Thank you for explaining - I didn't mean to imply I thought it was a security concern, as it is very clear what giving someone Edit access means.

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.

It sounds like the user is confused that having View access doesn't let them have access to decrypt/see the secret - only that they can use the secret within Phabricator. So in order to allow others to decrypt/see the secret he gives them Edit access which does give them the ability to change the secret.

Thanks for the response Evan.

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

mm, yeah, I didn't actually read it 😊 @kfsone said in the chat that it can be resolved, but this does actually sound like trust email address should win over require-email-verification.

@avivey Trust Email Address is meant to handle that though, is it not? The reported "bug" here is that the email addresses are not being verified when coming from LDAP, not that email verification is required.

auth.email-domains implies auth.require-email-verification.

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.