Repositories which require authentication can be cloned with bogus login data

[gitblit]

Originally reported on Google Code with ID 28

What steps will reproduce the problem?
1. Set a repository to "authenticated clone, view & push"
2. Clone the repository locally (I use TortoiseGit) using the URL shown in the summary
page in gitblit
3. Enter bogus login information

What is the expected output? What do you see instead?
I expected an authentication error but the repository was cloned successfully.

What version of the product are you using? On what operating system?
gitblit in Jetty 8.0.3. (also tried in Jetty 6.1.1) in Windows Server 2008 R2 using
plain http access

Reported by rob2d2 on 2011-10-23 00:58:27

[gitblit]

Uh oh.  I will take a look at this very soon - maybe today.

Reported by James.Moger on 2011-10-23 13:46:55

• Status changed: Accepted
• Labels added: Priority-Critical, Milestone-0.7.0
• Labels removed: Priority-Medium

[gitblit]

Reported by James.Moger on 2011-10-23 13:47:11

[gitblit]

My test setup is a little different than your setup....

* I always test on Jetty 7 (GO build) and occasionally Tomcat 6 (and Tomcat 7 in master).
* Gitblit 0.6.0 is servlet-api 2.5, not servlet-api 3.0 (Jetty 8).  The next release
is servlet-api 3.0 ready (Tomcat 6/Tomcat7/Jetty 8).
* I don't have TortoiseGit, but I don't *think* that should be an issue since the reported
error is server-side.

My preliminary result is that I can not reproduce your finding with 0.6.0 or the current
master branch.  I have tried cloning a repository at each restriction level with a
unit test.  It did surprise me to see that an empty repository is created locally,
though even though the clone failed.

Things you could do to help me diagnose the issue further:

1. Don't test on Jetty 8 since that is servlet 3.0 and may change/break authentication
(like trying to run Gitblit 0.6.0 on Tomcat 7).

2. Set "web.debugMode=true" in web.xml - this will add some logging to the AccessRestrictionFilter
class.  Confirm the received credentials in the log.  The log will say something like
when you try to clone:

INFO  ARF: ticgit.git/info/refs?service=git-upload-pack (401)
INFO  AUTH: Challenge Basic realm="Gitblit"
INFO  AUTH: invalid credentials (bogus:bogus)
INFO  ARF: ticgit.git/info/refs?service=git-upload-pack (401)
INFO  AUTH: Challenge Basic realm="Gitblit"

3. If TortoiseGit still succeeds and the credentials are the bogus ones, confirm that
the cloned repository actually has commits in it and is not just empty.

If all those are true, then perhaps TortoiseGit is falling back to the "dumb" http
protocol in which case I will have to review that some more because I did not think
that I was serving the "dumb" style.

Reported by James.Moger on 2011-10-23 14:58:22

[gitblit]

I did not yet change back to an old Jetty version (but as I said, I used Jetty 6 at
first and had the same behaviour).
The repositories I cloned are not empty, the debug logs look like this:

INFO   | jvm 1    | 2011/10/23 18:06:59 | INFO  ARF: kake.git/info/refs?service=git-upload-pack
(401)
INFO   | jvm 1    | 2011/10/23 18:06:59 | INFO  AUTH: Challenge Basic realm="Gitblit"
INFO   | jvm 1    | 2011/10/23 18:07:05 | INFO  ARF: kake.git/info/refs?service=git-upload-pack
(401)
INFO   | jvm 1    | 2011/10/23 18:07:05 | INFO  AUTH: Challenge Basic realm="Gitblit"
INFO   | jvm 1    | 2011/10/23 18:07:05 | INFO  AUTH: invalid credentials (bla:blub)
INFO   | jvm 1    | 2011/10/23 18:07:05 | INFO  ARF: kake.git/info/refs?service=git-upload-pack
(401)
INFO   | jvm 1    | 2011/10/23 18:07:05 | INFO  AUTH: Challenge Basic realm="Gitblit"
INFO   | jvm 1    | 2011/10/23 18:07:05 | INFO  ARF: kake.git/info/refs (100) unauthenticated
INFO   | jvm 1    | 2011/10/23 18:07:06 | INFO  ARF: kake.git/HEAD (100) unauthenticated
INFO   | jvm 1    | 2011/10/23 18:07:06 | INFO  ARF: kake.git/objects/e5/8cb482d051fe0d269468d76e556f23cfb84fab
(100) unauthenticated
INFO   | jvm 1    | 2011/10/23 18:07:06 | INFO  ARF: kake.git/objects/da/12904f9adf481ffcf1fd695e76df748542770f
(100) unauthenticated
INFO   | jvm 1    | 2011/10/23 18:07:06 | INFO  ARF: kake.git/objects/67/f869a6b5fff28b25eb5368adff0a67ad67393c
(100) unauthenticated
INFO   | jvm 1    | 2011/10/23 18:07:06 | INFO  ARF: kake.git/objects/18/d70f02cb8eeded3bb20b75f0cd29bb66157990
(100) unauthenticated
INFO   | jvm 1    | 2011/10/23 18:07:06 | INFO  ARF: kake.git/objects/ff/58cd936270ea2d151448f5f1cfb5a887213682
(100) unauthenticated

But it's still cloned successfully.

Reported by rob2d2 on 2011-10-23 16:11:27

[gitblit]

Ok.  Please repeat with the GO version and post your findings to help me determine where
the problem lies.

Reported by James.Moger on 2011-10-23 16:26:59

[gitblit]

Same thing happens. I copied in one of my repositories, enabled http and started gibtlit
go locally. Then I cloned successfully from localhost using bogus login data. On Win7
with a 64bit Java7u1.
I can send you the whole thing including the repository if it helps.

Reported by rob2d2 on 2011-10-23 16:57:31

[gitblit]

That might be very diagnostic.  Try zipping and attaching to this issue - if its not
too large.  I'll install TortoiseGit to see if I can replicate here.

Reported by James.Moger on 2011-10-23 17:49:57

[gitblit]

Oh shit.  I just replicated this with TortoiseGit.  This is obviously a nasty security
hole in my restriction filter implementation.  EGit/JGit doesn't trigger this.  Last
I checked, CGit doesn't trigger this either... but maybe it does now.  I'll check that
too.  It looks like TortoiseGit just keeps chugging along trying to make every URL
request instead of (really) stopping after authentication failure.  Actually, what
happens is that it prompts for credentials on the first challenge, but then disregards
all subsequent challenges and makes url requests which Gitblit happily processes, even
though it should not.

Thanks for reporting this.  I'll have this fixed today or tomorrow on Master.  I was
planning on a new release (big changes) by end of the week... this will be an *important*
addition.

Reported by James.Moger on 2011-10-23 18:28:00

[gitblit]

Ah, okidoki, glad I could help, really like the software.

Reported by rob2d2 on 2011-10-23 21:20:38

[gitblit]

Fix deployed in v0.7.0.

Reported by James.Moger on 2011-11-11 23:16:24

• Status changed: Fixed