Some parts of KDE use git notes fairly extensively for certain specific workflows.
How difficult would it be to have Phabricator permit pushing Notes, even if Phabricator itself didn't do much with them (doesn't need to display them)?

Okay, thanks!

Oh, I think the issue is this:

I also can't reproduce this:

It's fine to consider it not a bug. Mainly I wanted to provide the info that it doesn't work for documentation purposes, in case anyone else runs into the same situation in the future. (We ran into this by trying to transition from a very old Phabricator installation to a new one with hosted repos, but with a legacy deployment setup that needs a non-bare repo copy, and didn't realize that Phabricator didn't fully support hosted non-bare repos.)

Why do you consider this to be a bug, then?

No.

Do we tell you to do this in the documentation anywhere?

Giving full access to all users for the host repo folder solved the issue. As this is a vulnerability, I shouldn't left it as 'chmod a+w'.

I have the same problem.

Any test we execute must be distributed with phabricator/ and run on the first page load after an upgrade. That generally means it needs to be small, very fast, and completely conclusive. Compare to the test for Shellshock here, which runs in a few milliseconds, requires 10 lines of code, and is totally conclusive:

In T10832#171473, @epriestley wrote:

Broadly, I lean toward this policy going forward:

• When we can perform an accurate test for the vulnerability in a reasonable amount of time/effort and tell you that you are definitely vulnerable (as with Shellshock), we will continue to do so with an active setup warning.
• When we can not perform such a test (as here), we will publish guidance and note the issue in the changelog, but will not attempt to guess if the installed version may be vulnerable because this test will frequently be confusing/misleading/wrong.
• We can re-evaluate this after T5055, which may give us a wider range of tools for providing more accurate vulnerability notifications.

Broadly, I lean toward this policy going forward:

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.

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.

I got this:

Thanks for the report! Let us know if you run into anything else.

@epriestley Thank you very much for this fix and the explanation!
It seems that this issue is now finally solved and can be closed.
Great start of a new year! ;)

This is another reason for me to dislike PHP but I really appreciate the time you've taken to explain the issue in addition to a promising fix for this task. Couldn't have asked for a better new year's gift :)

I think the fread() thing from PHP.net is just the user being clueless. He's opening a connection to an HTTP server, writing this "HTTP request":

When you have a chance, can anyone else who was hitting this update libphutil/ to rPHU5afd76 and see if it still reproduces?

I'm fairly confident that D14920 will fix this. I was able to reproduce it with the "run in a loop" method, and narrow it down from there.

Today I`ve had some more time and investigated this issue a bit further.
I tried to debug this issue by using gdb and figured out that after a while the method DiffusionGitSSHWorkflow->waitForGitClient() in DiffusionGitUploadPackSSHWorkflow.php:35 loops forever:

[0x7f595b9d4208] stream_select(array(1)[0x3efe808], array(0)[0x3efe718], array(1)[0x40fb4c8], 1, 0) /home/build/phabricator/libphutil/src/channel/PhutilChannel.php:197
[0x7f595b9d3848] PhutilChannel::waitForActivity(array(1)[0x40fb588], array(1)[0x40fb588], array(0)[0x40fb5e8]) /home/build/phabricator/libphutil/src/channel/PhutilChannel.php:100
[0x7f595b9d3748] PhutilChannel::waitForAny(array(1)[0x40fb588]) /home/build/phabricator/phabricator/src/applications/diffusion/ssh/DiffusionGitSSHWorkflow.php:25
[0x7f595b9d34a0] DiffusionGitSSHWorkflow->waitForGitClient() /home/build/phabricator/phabricator/src/applications/diffusion/ssh/DiffusionGitUploadPackSSHWorkflow.php:35
[0x7f595b9d2ec8] DiffusionGitUploadPackSSHWorkflow->executeRepositoryOperations() /home/build/phabricator/phabricator/src/applications/diffusion/ssh/DiffusionSSHWorkflow.php:142
[0x7f595b9d28a0] DiffusionSSHWorkflow->execute(object[0x373c5c8]) /home/build/phabricator/phabricator/scripts/ssh/ssh-exec.php:267

Same here... Sadly D14801 doesn't fix this issue.

Updating to HEAD and running the clone in a loop, it still hangs eventually :(

There is a small possibility that D14801 fixed this. That's highly speculative, but it is the kind of low-level bug which could theoretically cause intermittent, difficult-to-reproduce hangs of this nature.

As a temporary workaround our company currently uses direct checkout through the standard ssh server until we have a stable phabricator-ssh daemon available.
I hope this will be fixed soon...
Thanks anyway!

I can reproduce this on my dev install (Ubuntu 14.04.3 LTS, git 2.6, OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.3, OpenSSL 1.0.1f 6 Jan 2014, PHP 5.5.9-1ubuntu4.14):

$ git clone --depth 5  ssh://git@localhost:7422/diffusion/MNG
Cloning into 'MNG'...
remote: Counting objects: 3560, done.
remote: Compressing objects: 100% (2960/2960), done.
Receiving objects:  99% (3525/3560), 153.83 MiB | 102.55 MiB/s
<hang>

Again I attached strace to narrow down the problem further.

I am getting the exact same issue.
I am prompted for a user id and password so I use the appropriate ones:
user: user_name_in_phab
password: users_password_in_phab

The same here...

In T9724#146283, @epriestley wrote:

I can't reproduce this. Here's what I did:

• I opened three terminal windows.
• I ran git clone ssh://dweller@secure.phabricator.com/diffusion/P/phabricator.git phabricator-X in each at the same time, where X is one of 1, 2 or 3.

All clones completed successfully, and I got three clones in the working directory after they finished.

I can't reproduce this. Here's what I did:

Any news on this?

Same as @cole... I've reported this issue with an already up to date OS and GIT:

build@ei-srv-l-141:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.3 LTS
Release:        14.04
Codename:       trusty

Thanks for checking, @cole.

I have upgraded git to the latest version.

$ git --version
git version 2.6.3

In T9724#144778, @johnny-bit wrote:

Not that it might help, but:

In T9724#144776, @cole wrote:

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 12.04.4 LTS
Release:	12.04
Codename:	precise

That's ancient 14.04 is also LTS...

Not that it might help, but:

From both of your installs, can we have the versions of:

• OS
• php
• git
• openssh
• phabricator

?

We have been experiencing the same issue, though we can reliably reproduce on larger repositories with no submodules.

Are the submodules all hosted in the same phabricator instance?

After playing around a while I found out that it seems the hang occurs only if another user concurrently does a git clone:

Yes, the path to 'repo.git' looks like this: plink.exe git@<our_server> "git-upload-pack '/diffusion/TPTB/3RDPARTY/tbb.git'".
I've tried running sshd in debug mode, but the sshd is terminating on every new connection attempt, because it isn't running as a daemon.
The only logging output I got when my clone attempt gets stuck is the following on the server side:

Nov 16 11:03:02 ei-srv-l-141 sshd[64152]: Set /proc/self/oom_score_adj to 0
Nov 16 11:03:02 ei-srv-l-141 sshd[64152]: Connection from 192.168.192.179 port 28269 on 192.168.192.141 port 22
Nov 16 11:03:03 ei-srv-l-141 sshd[64152]: Postponed publickey for git from 192.168.192.179 port 28269 ssh2 [preauth]
Nov 16 11:03:04 ei-srv-l-141 sshd[64152]: Accepted publickey for git from 192.168.192.179 port 28269 ssh2: RSA c1:1d:81:e5:81:e7:0e:b3:cd:92:3b:fa:b9:22:73:ae
Nov 16 11:03:04 ei-srv-l-141 sshd[64152]: User child is on pid 64160
Nov 16 11:03:04 ei-srv-l-141 sshd[64160]: Starting session: forced-command (key-option) ''/home/build/phabricator/phabricator/bin/ssh-exec' '--phabricator-ssh-user' 'm.herzog' '--phabricator-ssh-key' '32'' for git from 192.168.192.179 port 28269
Nov 16 11:03:04 ei-srv-l-141 sudo:      git : TTY=unknown ; PWD=/home/git ; USER=build ; COMMAND=/usr/bin/git-upload-pack -- /var/repo/TPL/
Nov 16 11:03:04 ei-srv-l-141 sudo: pam_unix(sudo:session): session opened for user build by (uid=0)
Nov 16 11:03:07 ei-srv-l-141 sudo: pam_unix(sudo:session): session closed for user build

Are you using VCS password for cloning?

I just tried pushing a new branch "test" and it worked, there is no master yet, but that push he attempts to do should work

This is hosted by phabricator itself, but repository is actually pretty clean, nobody ever pushed any commit to it in past.

Who is hosting the repository, Phabricator or an external source? Rough Googling suggests the repository might be corrupt or the disk might be full.

ssh git@<our_server> "git-upload-pack 'repo.git'"

• git-upload-pack is the server-side part of the git fetch/git pull transfer protocol.
• 'repo.git' should look like diffusion/CALLSIGN/name.git; Is that right?

let say this is my git tree
origin/master -> c1 -> c2 -> c3
at this point, arc diff results into creation of revision of c1, c2, c3. That's exactly what expected.
Now my reviews are pending and I started working on more stuff, so git tree will look like
origin/master -> c1 -> c2 -> c3 -> c4 -> c5 -> c6
this time arc diff will result into creation of revision of (c1, c2,.. c6) due to default ruleset. I want that arc diff should include only (c4, c5, c6) only.
I can achieve the same by using arc diff c4. But this situations is too frequent and doing arc diff <commit> is cumbersome because one have to do git log before that etc. So is there any ruleset in arcanist to handle that directly?

Can you explain more about what you're trying to accomplish in your details?

D14137 (with the new prompt) is now in master. It will promote to stable in about a week. You can grab it with arc upgrade.

No.

Is this related to T8936? I.e. similar cause?

We do not currently support git notes, and I had never heard of it before this task.

Still - wouldn't You have to also configure git for repo to use phabricator-mail? Plus - routing to conpherence is IMO more dangerous than simply forwarding to mailbox (where once can set up nice filters and spamhandlers).

I'm closing this as a dup of Q104; As a question, it has the same answers.