v3.6.4

19 views
Skip to first unread message

Sitaram Chamarty

unread,
Nov 1, 2015, 10:51:55 PM11/1/15
to Gitolite Google Groups, gitolite...@googlegroups.com
V3.6.4 has been pushed. It isn't a very remarkable set of patches, but
there is one interesting bug that was caught (thanks to "hseg" on irc)
and fixed.

Briefly, if

- you have a wild repo
- which allows repo-creation by a certain (group of) user(s)
- but does not allow this (group of) user(s) to *create* new refs
in (some of) the repos created

then this bug would bypass the create-block and allow the creation
of new refs.

I thought long about whether to classify this as a security issue but in
the end I decided not to. My reasons are:

- there is no data leak (someone viewing what they should not be able
to)
- there is no data loss (someone changing or deleting what they should
not be able to)
- at best it can be used as a DOS mechanism on the "packed-refs" file.
- only authorised users can do this, and they can be easily detected
by looking in the log files

More details are in the commit message for be5c2f5. For people who have
a conf with the conditions described above and who cannot afford to
upgrade, there is also a workaround; again, see the commit message
there.

regards
sitaram

PS: note that gitolite's "update hook based" mechanism already allows a
far more powerful DOS -- a DOS on the disk space, which therefore
affects the entire system, not just one repo. A user who has *some*
write access can fill up disk by sending in arbitrarily large commits,
because *git* does not invoke the update hook until after the objects
have been written to disk. Again, I don't consider this a real issue
since only authorised users can do this. (This *has* been highlighted
once as a reason to remove the "testing" repo, and I had rejected the
proposal for essentially the same reasons as above.)
Reply all
Reply to author
Forward
0 new messages