At least for now, maybe I'll remove the setup issue to avoid confusion and just note this in the changelog instead. This is much more likely to be overlooked, but vendors other than Apple seem to have generally taken care of this and using git --version to test for the presence of the vulnerability isn't really meaningful.

safe to ignore if you've updated to the latest version even though it's a lower version number

In other cases (like with Shellshock) we can just test for the vulnerability to see if a binary is vulnerable. Ideally, we'd just perform this test to figure out if you need to upgrade, but I don't think a reasonable test case exists here because we need to create a 2GB pathname and probably can not do that in a reasonable amount of time.

I got hit by that warning today, and while it doesn't bother me because I knew about the vulnerabilities and versions, it could be confusing for others. I've got 2.1.4-2.1+deb8u2 on Debian, which is old but the fixes are backported. Many other distros have older versions with backported fixes as well (as per https://news.ycombinator.com/item?id=11517894). Unfortunately you cannot see that in git --version though.

what do you think about supporting a mode that always uses the client (browser) timezone by default without any manual action taken by the user?

I've tried to re-pull down to a new folder (and copy whole conf) content - the left padding bug still occurs on our browser (this is a super old installation of phabricator. we use phabricator internally since 1-2 years ago)

FWIW, from our perspective we really want the time zone to be correct (for our users) by default without any manual intervention. From the discussion above, it seems like this ticket is leaning towards a scheme were the user is expected to set their time zone in Phabricator, but displaying a recon dialog if it mismatches the browser.

Sorry - not really sure how to describe the reproduction steps since it's a long deployment/upgrade steps. (in which I can mistake/skip the steps somewhere)

Offhand, I don't see any means of reproducing this. My guess is something was done/installed/updated/pulled incorrectly on your local install. Maybe delete phabricator and re-pull down.

Bug reports require reproduction steps.

Ubuntu 16.04 ... is a major platform for Phabricator hosts

T4752 is the detail on that.

When using local disk storage, the file is owned by the web-server user, not the daemon user.

I think it might be worth noting that Ubuntu 16.04 which releases soon (and is a major platform for Phabricator hosts) will be shipping with PHP 7 only, with a hard path to install PHP 5.

Personally for Pirate (English) I usually git-grep for the string, so I know how it shows up in the code.

That file I shared is just for strings with plurality, for all other strings, you can manually add them or run the string extractor. At some point we'll have this all automated, but it's manual right now.

Advancing quite a lot, but not being able to translate the sentences which explain the different status changes of a task:

All good now. Thanks.

Try that?

I get a new error when i run ./bin/storage upgrade:

I think the sequence of action is:

I'm less sure about adding a warning to arc.

I've updated all Phacility cluster hosts which run any git operations (secure*, sbuild*, saux*, repo*) to 2.8.1.

Sorry everyone -- we don't actually read or write this table yet so I didn't add the schema, but the fact that bin/storage adjust would complain slipped my mind. D15744 will fix it and make sure bin/storage adjust is run as part of the test suite.

This is not a demo or test install. Please don't make a mess! You can launch a demo install on Phacility if you want to poke around and try things out.

Sorry for testing this here. Please remove :(

Revert to rPeef217216116 and wait for all this to blow over ;)

I get the same issue after upgrading:

@avivey Please help look at it. Thanks in advance

Versions:
phabricator fbfe7304521464151986aee99d71fa07b20e0768 (Sun, Apr 17)
arcanist a2ab38df78a9d111459fab8d0d63e74d811edf29 (Sat, Apr 16)
phutil 1ea69b48e36d8411c329559b593772ae51a2e6f9 (Fri, Apr 15)

Well we could use Maniphest for commenting on documents, except that Maniphest tasks don't have a hierarchy to them.. neither do all of those other applications.

T3353 isn't specifically all about "review" if you read through the task. That task is the currently point for all things "we want to discuss changes on a document". I think that could include:

We're not signing off on the textual or structural changes, we're just agreeing that the ideas expressed in the document are what we all understand them to be.

Discuss potential changes.
Make the changes.
Then record a comment from each person signing off on them.

That task seems to be about reviewing structure of the document whereas we want to discuss ideas and content (and we don't need or want a formal review process).

How do I know if files are being stored in the database? What specific database/table should I look at?

Are you storing files in the database or have you configured a different storage engine?

We're just using bin/storage dump and just zipping it. Zip file is around 500Mb in size.

T3353 is the "Review changes in Phriction" task.

That doesn't seem like an efficient way to reclaim space. What are the exact sizes of your databases? Are you storing files in it?

I think a way of addressing the issue is to set the "There are 10 previous comments (show all)." bar that appears in transactions to at least comments that were made after the last change to the document.