Page MenuHomePhabricator

2014-04 April
Updated 2,569 Days AgoPublic


This period saw a large number of very boring fixes and improvements, few of which have much impact for most users. They are mostly too dull to transcribe here. Here are some of the more noticeable changes:

  • Bot/script accounts (previously called "System Agents") are now easier to administrate.
  • Inbound email error handling has generally been improved.
  • The repository import daemons should handle large numbers of repositories more gracefully now.
  • Removed "Clowncopterize" button.
  • Slowvotes can now be closed.
  • Audit has been updated to use more modern UI and infrastructure.
  • Phabricator now supports two-factor auth.
  • Phabricator now supports a "sudo" mode called "high security", to protect credential operations.
  • Improved support for assistive technologies.

Upgrading and Compatibility

  • There are no changes with significant compatibility impact in this period.
  • There are 12 database migrations, but none should take very long even on large installs.


  • Links are now written with rel="noreferrer" by default.
  • Pages now emit a "never" meta referrer tag by default.
  • The --trace flag now censors credentials in some service calls.
  • Improved seeding for some types of tokens.
  • Account activity logs can now be reviewed in Settings.
  • We received 39 vulnerability reports via HackerOne in this period. This month, none of them qualified for awards under the program guidelines:
    • (5 Reports) XSS or information exposure in unreachable code. Most of these cases are security researchers scanning the codebase for potentially vulnerable functions, but not verifying that they are actually used in a dangerous way. None of these reports identified exploitable code.
    • (3 Reports) Password reset tokens are currently valid for 48 hours and do not expire upon use. This led several researchers to report various concerns. We are satisfied that this is sufficiently robust for now, particularly because relatively few installs in the wild actually use passwords. We will probably move these to one-time tokens in the future once other pieces of infrastructure motivate easier construction of one-time tokens.
    • (3 Reports) You can sign up for accounts (or add emails to an account you do not own) using variations of some other user's Gmail address (e.g., This could mildly annoy and slightly inconvenience the victim. Neither we nor the researchers could identify a real threat here, nor suggest a fix which doesn't trade off legitimate use cases.
    • (2 Reports) Uploading very large GIFs (e.g., with tens of thousands of frames) doesn't do anything bad, but doesn't give you a very nice error message.
    • (2 Reports) Some interfaces show user content in error messages in a highly contextualized way. We think the benefit of giving users error messages in contextualized interfaces outweighs the very small risk risk that an unusually unaware user will be deceived by one of these pages. There are generally better ways to deceive users who would find these pages deceptive.
    • (2 Reports) In some cases, Phabricator can leak referrers. This is reported somewhat regularly, and no researchers have been able to identify ways that credentials or other important information could leak. In this period we implemented rel="noreferrer" and "never" meta-referrer tags, which should mitigate this in most browsers.
    • (2 Reports) Two researchers reported that stripping CSRF tokens out of forms still allowed them to take CRSF-validated actions. The CSRF token was still being transmitted via a header.
    • (2 Reports) Some interfaces can disclose full paths to source files. At the present time, we think the benefits of this (making it easier to debug issues and support installs that encounter problems) outweigh the risks (this information is not valuable to attackers on its own).
    • (2 Reports) Researchers made reports which we believe mischaracterize the computational complexity of attacks, e.g. suggesting that an online attack against a 96-bit secret is feasible by using the bitcoin network.
    • (1 Report) We do not emit a Strict-Transport-Security header. See T4340 for discussion.
    • (1 Report) We serve a .swf file which was built in debug mode, so it includes comments which reveal full paths from the original author's machine when decompiled. Although this is interesting, we do not consider it to be a security vulnerability.
    • (1 Report) A researcher reported an issue with CSRF tokens not cycling when they expected them to. We bind CSRF tokens to accounts, not sessions, and cycle them independent of session or credential cycling. This is technically simpler and reduces coupling between different parts of the system. We are satisfied with this approach at this time.
    • (1 Report) A researcher reported an issue with session tokens not cycling when they expected them to. We allow users to manage sessions explicitly from the "Sessions" panel, but do not cycle them automatically when credentials change. As with CSRF tokens, this is technically simpler and reduces coupling between different parts of the system. We are satisfied with this approach at this time.
    • (1 Report) We don't currently have SPF configured. See T4439 for discussion.
    • (1 Report) We don't emit Content-Type-Options headers on, but this domain has no user controlled content.
    • (1 Report) You can create some types of objects with empty or unclickable names. This might annoy other users, but is not a security vulnerability.
    • (1 Report) We do not emit noindex headers or have robots.txt rules for some pages which should not be indexed. Since crawlers can only learn about these pages by following links on other pages and attackers can search for the URIs as page content to find them on the original pages, it's unclear that this would provide any security benefit. These measures are also purely advisory.
    • (1 Report) By default, we do not require passwords to be hugely complex. We are satisfied with our default password policies at this time. Administrators can configure a stricter policy if they prefer.
    • (1 Report) We run an SMTP server to receive mail to Phabricator. It is not an open relay.
    • (1 Report) A researcher reported an apparent policy violation with Calendar event creators. This is working as intended, the visibility of this information just isn't made very clear by the application (Calendar is still in beta).
    • (1 Report) By using a Chrome extension which allows you to pay other people to solve CAPTCHAs for you, an attacker can bypass CAPTCHAs very slowly and at enormous personal expense.
    • (1 Report) Usernames are enumerable. This is by design, as many features would be difficult to use without enumerable usernames.
    • (1 Report) By entering a bogus time-of-day format, you can confuse yourself. This is not a security vulnerability.
    • (1 Report) By entering a huge amount of data into some fields, you can sometimes crash your browser. This is not an issue with Phabricator.
    • (1 Report) We wrote the text "/bin/" in some documentation, and a researcher reported that we were disclosing paths.


  • Improved behavior of some commands when run on revisions which you are not the author of.

Bug Fixes

  • Fixed some issues with arc tasks and customizable priorities and statuses.
  • arc land now correctly detects when a local target is ahead of the remote.
  • Fixed an issue with editing comments that are part of a transaction group.


  • HTTPSFuture now supports file attachments.
  • PhutilGitURI and PhutilURI are now stricter about leading whitespace.
  • Iterating a Phobject which is not explicitly iterable now throws an exception.
Last Author
Last Edited
May 1 2014, 6:40 PM

Event Timeline