http-smart-backend: can clone, cannot push

Hello,

	I've set up a directory to serve git repos under /var/www/git using:

	- apache2
	- git 1.7.1
	
	The apache config file is literally pasted from the http-smart-backend documentation, modified for my installation. I clone successfully over https using the smart backend. I know this because when you use the smart backend you get this type of message:

	git clone https://git.pelagicore.net/var/www/git/administrivia.git
	Initialized empty Git repository in /home/jeremiah/administrivia/.git/
	remote: Counting objects: 69, done.
	remote: Compressing objects: 100% (47/47), done.
	remote: Total 69 (delta 15), reused 0 (delta 0)
	Unpacking objects: 100% (69/69), done.

	As opposed to a more terse message when using a 'dumb' http transport.

	I cannot push however. This is what git says:
	
	$ ~/administrivia >  git push origin master
	error: Cannot access URL https://git.pelagicore.net/var/www/git/administrivia.git/, return code 22
	fatal: git-http-push failed

	And this is what the logs say:

	[Tue Jun 01 14:25:54 2010] [error] [client 109.74.195.212] Request not supported: '/var/www/git/administrivia.git/'

	How is that I can clone with the smart transport, and not push?

Thanks,

Jeremiah

On Tue, Jun 1, 2010 at 8:28 PM, Jeremiah Foster <jeremiah.foster@pelagicore.com> wrote:

Can you paste the output for

  $ GIT_CURL_VERBOSE=1 git push origin master

On Jun 1, 2010, at 15:15, Tay Ray Chuan wrote:

This is the output :

   GIT_CURL_VERBOSE=1 git push origin master
* About to connect() to git.pelagicore.net port 443 (#0)
*   Trying 109.74.195.212... * connected
* Connected to git.pelagicore.net (109.74.195.212) port 443 (#0)
* found 142 certificates in /etc/ssl/certs/ca-certificates.crt
*        server certificate verification SKIPPED
*        common name: www.pelagicore.net (does not match 'git.pelagicore.net')
*        server certificate expiration date OK
*        server certificate activation date OK
*        certificate public key: RSA
*        certificate version: #1
*        subject: CN=www.pelagicore.net
*        start date: Mon, 08 Feb 2010 13:49:15 GMT
*        expire date: Thu, 06 Feb 2020 13:49:15 GMT
*        issuer: CN=www.pelagicore.net
*        compression: NULL
*        cipher: AES-128-CBC
*        MAC: SHA1

User-Agent: git/1.7.1
Host: git.pelagicore.net
Accept: */*
Pragma: no-cache

* The requested URL returned error: 403
* Closing connection #0
* About to connect() to git.pelagicore.net port 443 (#0)
*   Trying 109.74.195.212... * connected
* Connected to git.pelagicore.net (109.74.195.212) port 443 (#0)
* found 142 certificates in /etc/ssl/certs/ca-certificates.crt
* SSL re-using session ID
*        server certificate verification SKIPPED
*        common name: www.pelagicore.net (does not match 'git.pelagicore.net')
*        server certificate expiration date OK
*        server certificate activation date OK
*        certificate public key: RSA
*        certificate version: #1
*        subject: CN=www.pelagicore.net
*        start date: Mon, 08 Feb 2010 13:49:15 GMT
*        expire date: Thu, 06 Feb 2020 13:49:15 GMT
*        issuer: CN=www.pelagicore.net
*        compression: NULL
*        cipher: AES-128-CBC
*        MAC: SHA1

User-Agent: git/1.7.1
Host: git.pelagicore.net
Accept: */*
Pragma: no-cache

< HTTP/1.1 200 OK
< Date: Tue, 01 Jun 2010 13:41:02 GMT
< Server: Apache/2.2.15 (Debian)
< Expires: Fri, 01 Jan 1980 00:00:00 GMT
< Pragma: no-cache
< Cache-Control: no-cache, max-age=0, must-revalidate
< Content-Length: 59
< Vary: Accept-Encoding
< Content-Type: text/plain
< 
* Connection #0 to host git.pelagicore.net left intact
* Re-using existing connection! (#0) with host git.pelagicore.net
* Connected to git.pelagicore.net (109.74.195.212) port 443 (#0)

User-Agent: git/1.7.1
Host: git.pelagicore.net
Accept: */*
Pragma: no-cache

< HTTP/1.1 200 OK
< Date: Tue, 01 Jun 2010 13:41:03 GMT
< Server: Apache/2.2.15 (Debian)
< Expires: Fri, 01 Jan 1980 00:00:00 GMT
< Pragma: no-cache
< Cache-Control: no-cache, max-age=0, must-revalidate
< Content-Length: 23
< Last-Modified: Tue, 01 Jun 2010 08:29:13 GMT
< Vary: Accept-Encoding
< Content-Type: text/plain
< 
* Connection #0 to host git.pelagicore.net left intact
* About to connect() to git.pelagicore.net port 443 (#0)
*   Trying 109.74.195.212... * connected
* Connected to git.pelagicore.net (109.74.195.212) port 443 (#0)
* found 142 certificates in /etc/ssl/certs/ca-certificates.crt
*        server certificate verification SKIPPED
*        common name: www.pelagicore.net (does not match 'git.pelagicore.net')
*        server certificate expiration date OK
*        server certificate activation date OK
*        certificate public key: RSA
*        certificate version: #1
*        subject: CN=www.pelagicore.net
*        start date: Mon, 08 Feb 2010 13:49:15 GMT
*        expire date: Thu, 06 Feb 2020 13:49:15 GMT
*        issuer: CN=www.pelagicore.net
*        compression: NULL
*        cipher: AES-128-CBC
*        MAC: SHA1

User-Agent: git/1.7.1
Host: git.pelagicore.net
Accept: */*
Depth: 0
Content-Type: text/xml
Content-Length: 187
Expect: 100-continue

< HTTP/1.1 100 Continue
* The requested URL returned error: 404
* Closing connection #0
error: Cannot access URL https://git.pelagicore.net/var/www/git/administrivia.git/, return code 22
fatal: git-http-push failed

Hi,

On Tue, Jun 1, 2010 at 11:24 PM, Jeremiah Foster <jeremiah.foster@pelagicore.com> wrote:

You're getting a 403 Forbidden here. What authentication method were you expecting?

FYI, after this, the requests show that git is falling back to the "dumb"/WebDAV protocol, which the server doesn't seem to support.

On Jun 1, 2010, at 17:40, Tay Ray Chuan wrote:

I thought that by exporting "GIT_SSL_NO_VERIFY=true" that it would not matter.

Yeah, I can see in the logs that it is calling PROPFIND, which is clearly a webDav command. The weird thing is that I know this repo is checked out of a smart http transport dir, at least when I clone it. I don't understand how I could have set it up correctly for cloning and then not be able to push properly back. 

Maybe I _have_ to be authenticated since the documentation states:  "If the client is authenticated, thereceive-pack service is enabled, which serves git send-pack clients, which is invoked from git push." 

Jeremiah

Jeremiah Foster <jeremiah.foster@pelagicore.com> wrote:

Yes.

A flaw of the smart HTTP transport is the servers are nearly impossible to configure for anonymous clone and authenticated push via the same URL. The servers just can't seem to be configured to require authentication for the $GIT_DIR/info/refs?service=git-receive-pack request.

Hi all,

Yeah, the problem seems to be that query string. Apache's <Location> doesn't help with that. However, you could add a custom authentication handler which checks the query part of the URL, right?

<shameless plug> In fact, I submitted a patch which adds smart HTTP integration to Redmine's Perl auth module at [1] and does just this. I've tested on a server I set up at my uni, and pretty much nowhere else :-/. Lines 250-254 should do just that: check the unparsed URI (possibly including the query string) for git- receive-pack at the end. That includes .../git-receive-pack and .../refs?service=git-receive-pack.

Perhaps you could take just the parts you need from the patched Redmine.pm file. </shameless plug>

Another option could be using RewriteCond to set an environment variable depending on REQUEST_URI and QUERY_STRING [2] and use "Allow from env=..." [3]. I think it should be simpler than writing and installing an authentication handler, but I'm not sure, either. I'm mostly limited to Apache here: perhaps it can be easier with other web servers.

[1]: http://www.redmine.org/attachments/3300/0001-Redmine.pm-add-Git-smart- HTTP-support-v4.patch [2]: http://www.phwinfo.com/forum/alt-apache-configuration/329880-regular- expressions-locationmatch.html#post1483835 [3]: http://httpd.apache.org/docs/2.2/mod/mod_authz_host.html#allow

Regards, Antonio

On Jun 1, 2010, at 17:58, Shawn O. Pearce wrote:

Thanks Shawn, and everyone else who commented on this thread - I appreciate the help.

I created a system to authenticate and then I could push and pull with the same URL. Thanks again for the help and I'm going to try to write up a short blog post about using this because I think it is a really great way to share git repos.

Jeremiah

On Tue, Jun 1, 2010 at 5:53 PM, Jeremiah Foster <jeremiah.foster@pelagicore.com> wrote:

This is about not verifying the SSL certificate, not the user.