2014-08 August
Updated 842 Days AgoPublic


  • Files now have better support for policies, and behave more naturally. In general, files uploaded to an object (like a task) are now visible only to the user who uploaded them and other users who can see the object.
  • Most files now perform stricter access checks when downloaded.
  • Workboards no longer sort tasks by priority by default. Instead, tasks work more like sticky notes on a whiteboard, and stay where you put them (unless you explicitly change the board ordering).
  • Automatic closing of tasks when commits with Fixes T123 are pushed now works better, in more cases, and is easier to debug and understand. The configuration for these options now supports regular expressions.
  • Repository update behavior for imported repositories is now better explained, easier to understand, and can be explicitly triggered from the web UI.
  • Added new "never send me any email" setting. Other email settings are now more granular, and you can completely ignore events you don't care about (like workboard column moves or CC changes).
  • Added a (very basic) HTML email setting.
  • There is a new Herald rule type ("Differential Diffs") for preventing users from uploading changes that include sensitive information. For example, you can blacklist configuration files or files with key material which should never be tracked by version control, and this will prevent arc diff (and other mechanisms which create diffs) from writing these accidental changesets to any permanent storage.

Upgrading / Compatibility

  • We fixed an issue with OSX Yosemite Beta 6 and SSL certificate handling. If you're seeing issues, updating should resolve them.
  • We've fixed an issue where arc diff could hang in lint.
  • Fixed an issue with the most recent version of flake8.
  • We've added setup warnings for ft_min_word_len and ft_stopword_file, two MySQL configuration options which cause the most common issues installs report with search. You may see setup warnings for these options after upgrading. They will guide you through tweaking these options to make search work better.
  • We've added a setup warning that checks if the daemons are running with different configuration from the webserver. This is primarily intended to catch cases where you change configuration from the web UI but forget to restart the daemons. This issue may raise a false positive if you intentionally run the daemons with a different configuration. If so, you can use the "Ignore" feature to suppress it.


  • Users can now manage temporary tokens (for example, password reset tokens) in SettingsTemporary Tokens.
  • We now invalidate password reset links and outstanding sessions more aggressively when account authentication sources are changed.
  • CSRF tokens are now tied to the current session.
  • We fixed a persistent XSS hole in Remarkup. This issue was reported to us via HackerOne and we awarded a $1,000 bounty for it. An attacker needed access to create objects or post comments in order to exploit the issue.
  • We fixed an issue where a user who attempted to add an email address to their account but mistyped it and did not realize their mistake could potentially have their account compromised by the real address owner. This issue was reported to us via HackerOne and we awarded a $300 bounty for it. A victim needed to accidentally type an adversary's email address instead of their own to be vulnerable.
  • We fixed an issue where we would incorrectly assess /\evil.com to be a domain-relative URI and issue a redirect to it. In practice, some browsers "correct" backslashes into forward slashes, and interpret this like the protocol-relative URI //evil.com, which points at a different domain. This issue was reported to us via HackerOne and we awarded a $400 bounty for it.
  • We received 35 additional reports in this period, which we did not award:
    • (8 Reports) Configuration or software issues on secure.phabricator.com or phabricator.org which are not covered by the program. This is explained very clearly in the program description.
    • (5 Reports) Various tokens/sessions/keys don't expire when users take somewhat-related (or sometimes totally unrelated) actions. When there is no direct security impact to expiring a token, we generally do not expire it: this reduces implementation complexity and user confusion. For example, if a user requests two password reset links, we do not expire the first one immediately when the second one is requested. Expiring it would not prevent any attack, and would sometimes frustrate users if mail is arriving slowly. Another example is that we do not invalidate all outstanding sessions when a user adds an email address. Doing so would not prevent any attack, and would sometimes frustrate users. Users can manage temporary tokens and sessions explicitly, and we expire tokens when there are meaningful security changes which legitimately invalidate them (for example, when a reset link is used or an email address is removed).
    • (2 Report) We don't re-prompt users for passwords when taking various actions. In general, we don't do this because most user accounts do not have passwords (they use OAuth instead). Users can configure multi-factor authentication to improve account security and defuse all attacks in this class far more effectively.
    • (1 Report) An attacker who tricks a victim into logging in to an OAuth account the attacker controls may be able to escalate this into tricking the user into logging into a Phabricator account the attacker controls. At this time, we do not think this attack is very realistic, and mitigating it would inconvenience users. Users can substantially defuse this attack with multi-factor authentication. Generally, we aren't sure that tricking a victim into logging into an account you control is a very interesting attack. It seems hard to convince them to enter sensitive information, and hard to maintain the ruse for very long given the increasing level of customization many interfaces provide.
    • (1 Report) An attacker can trick a victim into logging into an account the attacker controls if he can convince them to click a button in a very explicit roadblock dialog which clearly explains which account they are logging in as. We currently believe the roadblock dialog is sufficient to prevent this attack: it is as clear as we can make it without beginning to unduly burden legitimate users.
    • (1 Report) Phabricator does not have a way for users to block other users (for example, users who are harassing them). We haven't seen issues with this in the wild yet, and the majority of installs are either private or have a small enough userbase that messaging an administrator is a reasonable way to resolve the issue. We'll consider building these features if and when we see problems they might help resolve. (The reporting researcher had not encountered a harassing user in practice, and was just reporting the issue in theory.)
    • (1 Report) Researcher hit a bug around file permissions; we fixed the bug but there was no security impact (the bug made permissions too restrictive in some cases).
    • (1 Report) Users can attempt to enumerate usernames or email addresses in an online attack by trying to register accounts, provided they fill out a CAPTCHA for each attempt. We believe this reasonably balances usability and security.
    • (1 Report) During setup, there is a brief window when Phabricator will trust Host headers, which can allow an adversary to attack the install by proxying it. We think this design reasonably balances usability and security, since trusting Host headers makes setup much easier for users and this attack is not possible once an install is configured. Even if an attacker succeeds in performing this attack, there is not much they can do (there is no obvious mechanism by which they can establish sessions or extend access).
    • (1 Report) Highly-contextualized content spoofing of an error message. We do not believe any user would reasonably be confused by this attack, and showing the text of the error message is significantly valuable.
    • (1 Report) We don't send an email notification on password changes. We're satisfied with this behavior for now.
    • (1 Report) Users are allowed to reset their password to their previous password. There is no security benefit to preventing this and doing so would sometimes frustrate users.
    • (1 Report) An attacker can perform an online attack against a compromised account's password, by repeatedly trying to change it. We don't currently think this attack is viable or interesting.
    • (1 Report) Full path disclosure. We continue to believe the security impact of this is negligible and it has positive utility.
    • (1 Report) We do not randomly rename uploaded files. The researcher could not describe any attack where this would be relevant.
    • (1 Report) Phabricator intentionally does not generally allow users to completely destroy data.
    • (1 Report) A particularly clever user can choose a password which satisfies the minimum length requirement and does not appear on the common password blacklist, but is still extremely weak, like their username, email address, company name, the domain Phabricator is installed on, etc. We believe we make a reasonable effort to encourage users to choose good passwords, and can not reasonably prevent determined users from selecting poor passwords.
    • (1 Report) Attackers can register multiple accounts that point to the same mailbox, for example with email+anything@gmail.com. This is expected, desirable, and impossible to prevent.
    • (1 Report) CSRF protections are not effective if an attacker has read access to the network. This is expected and not preventable.
    • (1 Report) Logged out users can see content when Phabricator is configured to allow logged out users to see content.
    • (2 Reports) Users can edit content when Phabricator is configured to allow users to edit content.
    • (1 Report) User needed help using Phabricator.


  • arc browse now works on more objects, like arc browse D123.
  • arc diff and arc todo now support --browse flags.
  • Added a simple php syntax check linter.


  • You can now order Maniphest search results by custom field values.
  • bin/remove destroy can now destroy polls, credentials, dashboards, panels, files, questions, and answers.
  • Destroying an object now destroys its Herald transcripts.
  • You can now view the raw source text of comments.
  • You can now view the original email source for email comments.
  • Workboard backlog columns can now be reordered.
  • Fixed an issue with non-UTF8 branch names.
  • Projects can now be filtered by icon and color.
  • Feed renders more usefully, and includes projects.
  • Added a new X-Phabricator-Projects header to outbound mail.
  • Differential now shows some image metadata for image diffs. The properties table is also more nicely designed.
  • You can now provide a custom quit signoff message for the IRC bot.
  • Workboard columns now show a task count, and a maximum limit can be configured.
  • Fixed an issue with bin/files migrate which could cause some copies of duplicate files to lose their association to their data.
  • Added bin/files compact, which can usually fix the issue above for affected files.
  • Improved the responsiveness of Harbormaster builds to interrupts.
  • Improved behavior when a password hasher which previously existed goes missing.
  • Fixed an issue where account.editable would prevent password changes.
  • Username and project mentions in custom remarkup fields now work correctly.
  • Fixed an issue where feed HTTP hook tasks would not permanently fail if the target URI was removed from the configuration.


  • Daemons now support graceful shutdown, and phd attempts to shut them down gracefully. You can use the new --graceful flag to adjust this behavior.
  • bin/phd now attempts to detect stray daemons when stopping or restarting daemons.
  • The daemon logs have moved from the web UI to bin/phd log. This is mostly intended to limit the accessibility of system information to users.


  • List items may now have several paragraphs.

    This second paragraph serves as proof that we really built this feature and are not just making it up.
  • The new remarkup.ignored-object-names setting allows you to blacklist certain object names or patterns, like Q1, V1, etc., which may be false positives that occur in normal discussion.
  • Added a new navigation sequence element for communicating things like HomeSettingsEmail Preferences or JudgeJuryExecutioner

Miscellaneous / Developer

  • Fixed an issue where temporary files were not removed after an abrupt shutdown.
  • Replaced phutil_utf8_shorten() with PhutilUTF8StringTruncator.
  • Fixed a bug with parsing Git diffs that remove a file containing spaces in the filename.
Last Author