Add "pusher is committer" to Herald as a pre-commit rule

Summary:
Fixes T4594. Also, allow "exists" / "does not exist" to be run against author/committer. This allows construction of rules like:

  - Committer identities must be authentic.
  - Committer identities must be resolvable.
  - Author identities must be resolvable.

Test Plan: Created some rules using these new rules and ran them.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: aran, epriestley

Maniphest Tasks: T4594

Differential Revision: https://secure.phabricator.com/D8507
Fix two transactional issues around revision status

Summary:
Two issues:

  - Herald is currently overwriting accepts and rejects with "blocking reviewer". Just stop it from doing that.
  - When you update an accepted revision, we put it back in "needs review", then return it to "accepted", generating an extra transaction. Instead, don't.

Test Plan:
  - Updated a revision with an accepting, herald-based blocking project reviewer. Reviewer was still accepting.
  - Updated an accepted revision, didn't get an extra transaction.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: aran, epriestley

Differential Revision: https://secure.phabricator.com/D8506
Add missing needReviewerAuthority() for differential.createcomment

Summary: For some actions (like accept) we need to load reviewer authority so we can figure out if the actor can act on behalf of project reviewers, etc.

Test Plan: Will make @dctrwatson do it.

Reviewers: dctrwatson, btrahan

Reviewed By: btrahan

Subscribers: chad, aran, dctrwatson, epriestley

Differential Revision: https://secure.phabricator.com/D8505
Fix a small typo when creating a Herald rule

Summary: "Users who an edit" to "Users who can edit"

Test Plan: Verified that typo is gone after the change

Reviewers: epriestley, #blessed_reviewers

Reviewed By: epriestley, #blessed_reviewers

Subscribers: aran, epriestley, Korvin

Differential Revision: https://secure.phabricator.com/D8511
Silence a warning about unknown fields in 'getcommitmessage'

Summary: Similar to D8491, some of my new exceptions are a bit too aggressive. See IRC. This one's hitting an edit workflow with 'revisionID' onboard somehow.

Test Plan: Not entirely sure how to hit this, but it won't throw anymore.

Reviewers: btrahan, dctrwatson, zeeg

Reviewed By: zeeg

Subscribers: zeeg, aran, epriestley

Differential Revision: https://secure.phabricator.com/D8514
Fix parsing of "Reviewed By" field

Summary: In the Message parser, we read this field and expect to get an array of PHIDs out of it. Currently, we get a string. Instead, get an array of PHIDs.

Test Plan: Wrote a message like "Fixes Tnnn" with "Reviewed by: duck", and saw no more parse error during message parsing.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: aran, epriestley

Differential Revision: https://secure.phabricator.com/D8510
Disable Herald more aggressively when it's turned off for a repository

Summary:
Currently, disabling Herald only disables feed, notifications and email. Historically, audits didn't really create external effects so it made sense for Herald to only partially disable itself.

With the advent of Harbormaster/Build Plans, it makes more sense for Herald to just stop doing anything. When this option is disabled, stop all audit/build/publish/feed/email actions for the repository.

Test Plan: Ran `scripts/repository/reparse.php --herald`, etc.

Reviewers: dctrwatson, btrahan

Reviewed By: btrahan

Subscribers: aran, epriestley

Differential Revision: https://secure.phabricator.com/D8509
Add a "Generate Keypair" option on the SSH Keys panel

Summary: Ref T4587. Add an option to automatically generate a keypair, associate the public key, and save the private key.

Test Plan: Generated some keypairs. Hit error conditions, etc.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: aran, epriestley

Maniphest Tasks: T4587

Differential Revision: https://secure.phabricator.com/D8513
Allow Passphrase to generate SSH keypairs and extact public keys from private keys

Summary:
Ref T4587.

  - Add an option to generate a keypair.
  - Add an option to view the public keys for existing keypairs.

Test Plan:
  - Generated keypairs.
  - Viewed public keys.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: aran, epriestley

Maniphest Tasks: T4587

Differential Revision: https://secure.phabricator.com/D8515
Fix some collateral damage from SSH Keypair generation

Summary: There's no `addHiddenInput()` on the layout view. Instead, build it
from the form. See: <https://github.com/facebook/phabricator/issues/538>.

Auditors: btrahan
Use "\z" instead of "$" to anchor validating regular expressions

Summary:
Via HackerOne. In regular expressions, "$" matches "end of input, or before terminating newline". This means that the expression `/^A$/` matches two strings: `"A"`, and `"A\n"`.

When we care about this, use `\z` instead, which matches "end of input" only.

This allowed registration of `"username\n"` and similar.

Test Plan:
  - Grepped codebase for all calls to `preg_match()` / `preg_match_all()`.
  - Fixed the ones where this seemed like it could have an impact.
  - Added and executed unit tests.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: aran, epriestley

Differential Revision: https://secure.phabricator.com/D8516
Fix an anchor redirect issue with OAuth server, plus modernize the application a bit

Summary:
Ref T4593. Via HackerOne. An attacker can use the anchor reattachment, combined with the Facebook token workflow, combined with redirection on OAuth errors to capture access tokens. The attack works roughly like this:

  - Create an OAuth application on Phabricator.
  - Set the domain to `evil.com`.
  - Grab the OAuth URI for it (something like `https://phabricator.com/oauthserver/auth/?redirect_uri=http://evil.com&...`).
  - Add an invalid `scope` parameter (`scope=xyz`).
  - Use //that// URI to build a Facebook OAuth URI (something like `https://facebook.com/oauth/?redirect_uri=http://phabricator.com/...&response_type=token`).
  - After the user authorizes the application on Facebook (or instantly if they've already authorized it), they're redirected to the OAuth server, which processes the request. Since this is the 'token' workflow, it has auth information in the URL anchor/fragment.
  - The OAuth server notices the `scope` error and 302's to the attacker's domain, preserving the anchor in most browsers through anchor reattachment.
  - The attacker reads the anchor in JS and can do client workflow stuff.

To fix this, I've made several general changes/modernizations:

  - Add a new application and make it beta. This is mostly cleanup, but also turns the server off for typical installs (it's not generally useful quite yet).
  - Add a "Console" page to make it easier to navigate.
  - Modernize some of the UI, since I was touching most of it anyways.

Then I've made specific security-focused changes:

  - In the web-based OAuth workflow, send back a human-readable page when errors occur. I //think// this is universally correct. Previously, humans would get a blob of JSON if they entered an invalid URI, etc. This type of response is correct for the companion endpoint ("ServerTokenController") since it's called by programs, but I believe not correct for this endpoint ("AuthController") since it's used by humans. Most of this is general cleanup (give humans human-readable errors instead of JSON blobs).
  - Never 302 off this endpoint automatically. Previously, a small set of errors (notably, bad `scope`) would cause a 302 with 'error'. This exposes us to anchor reattachment, and isn't generally helpful to anyone, since the requesting application did something wrong and even if it's prepared to handle the error, it can't really do anything better than we can.
  - The only time we'll 'error' back now from this workflow is if a user explicitly cancels the workflow. This isn't a 302, but a normal link (the cancel button), so the anchor is lost.
  - Even if the application is already approved, don't blindly 302. Instead, show the user a confirmation dialog with a 'continue' link. This is perhaps slightly less user-friendly than the straight redirect, but I think it's pretty reasonable in general, and it gives us a lot of protection against these classes of attack. This redirect is then through a link, not a 302, so the anchor is again detached.
  -

Test Plan: I attempted to hit everything I touched. See screenshots.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: aran, epriestley

Maniphest Tasks: T4593

Differential Revision: https://secure.phabricator.com/D8517
Modernize Facebook OAuth instructions

Summary: Ref T4593. We have somewhat outdated instructions, and safer setup instructions are now available.

Test Plan: Read instructions.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: aran, epriestley

Maniphest Tasks: T4593

Differential Revision: https://secure.phabricator.com/D8518
Tweak application and maniphest editors to handle policy corner cases better

Summary:
Fixes T4362. If you have a default edit + view policy of "no one" things get weird when you try to create a task - basically its impossible.

Ergo, re-jigger how we do policy checks just a bit.

 - if its a new object, don't bother with the "can the $actor edit this thing by virtue of having can see / can edit priveleges?" That makes no sense on create.
 - add a hook so when doing the "will $actor still be able to edit this thing after all the edits" checks the object can be updated to its ultimate state. This matters for Maniphest as being the owner lets you do all sorts of stuff.

Test Plan:
- made a task with no one policy and assigned to no one - exception
- made a task with no one policy and assigned to me - success
 - made a comment on the task - success
 - reassigned the task to another user - exception
 - reassigned the task to another user and updated policies to "users" - success

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: aran, epriestley, Korvin

Maniphest Tasks: T4362

Differential Revision: https://secure.phabricator.com/D8508
Added 'method' field to the HTTP request build step.

Summary:
This revision adds a 'method' field to the HTTP request harbormaster build step.  This allows the user to specify GET, POST, DELETE, and PUT (limited by the underlying wrapper phabricator uses for HTTP requests).  I'm not sure how much sense PUT makes, but oh well.

Existing plans shouldn't break, as if this field is an empty string, we default to POST, which is the old behavior.

Fixes T4604

Test Plan: 1) Verified that the empty string does, in fact, issue a POST request.  Changed the method to be GET and observed that the problem described in T4604 is resolved.

Reviewers: #blessed_reviewers, epriestley

Reviewed By: #blessed_reviewers, epriestley

Subscribers: aran, epriestley

Maniphest Tasks: T4604

Differential Revision: https://secure.phabricator.com/D8520
Fix issue with ref/fixes in commit messages

Summary: Fixes T4600. If there's also a revision, the variable "$message" gets overwritten. groan~

Test Plan: Pushed a commit with "Fixes T123" and a revision, saw it parse on the first try.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: chrisbolt, aran, epriestley

Maniphest Tasks: T4600

Differential Revision: https://secure.phabricator.com/D8519
Include objectPHID in feed.query text view

Summary: This way the type of story can be inferred.

Test Plan: requested feed.query with `view=>'text'`

Reviewers: epriestley, #blessed_reviewers

Reviewed By: epriestley, #blessed_reviewers

Subscribers: aran, epriestley, Korvin

Differential Revision: https://secure.phabricator.com/D8521
Make PhabricatorBotFeedNotificationHandler work with new PhabricatorApplicationTransactionFeedStory

Summary: Depends on D8521

Test Plan: ran with handler enabled and phabot posted stories

Reviewers: #blessed_reviewers, epriestley

Reviewed By: #blessed_reviewers, epriestley

Subscribers: aran, epriestley, Korvin

Differential Revision: https://secure.phabricator.com/D8524
Fix two registration errors for unusual provider emails

Summary:
See <https://github.com/facebook/phabricator/issues/541>.

  - If a provider returns the email `""` or `"0"`, we currently don't let the user edit it and thus don't let them register.
  - If a provider returns an invalid email like `"!!!"` (permitted by GitHub, e.g.), we show them a nonsense error message.

Instead:

  - Pretend we didn't get an address if we get an invalid address.
  - Test the address strictly against `null`.

Test Plan: Registered on Phabricator with my GitHub email set to `""` (empty string) and `"!!!"` (bang bang bang).

Reviewers: btrahan, chad

Reviewed By: chad

Subscribers: aran, epriestley

Differential Revision: https://secure.phabricator.com/D8528
Fix a couple of minor OAuthServer things

Summary:
I was a bit hasty with this.

  - This should be uninstallable.
  - Provide a real description.
  - Choose a better title glyph (trident of neptune).

Test Plan: Poked around.

Reviewers: btrahan, chad

Reviewed By: chad

Subscribers: aran, epriestley

Differential Revision: https://secure.phabricator.com/D8534