When someone adds a repo-specific hook to their repo, then create a
'fork' via the fork ADC, this repo-specific hook also get carried
across, but should not.
- 'dupkeys' -- catch duplicate keys in keydir
- 'email-check' -- "you can only push your own commits"
plus, 'merge-check' -- how we could have done the no-merges policy
- compile: VREF/ is special, like NAME/
- update hook: use a new "check_vrefs" sub to
- spawn helpers for each vref in @allowed_refs
- for each vref returned by the helper, call check_ref
This compensates for an selinux bug reported on #gitolite by John Hawley
(warthog9). sh/bash uses a tempfile to do this, which in turn causes
some problems in selinux; I really don't [need to] know more than that.
*Technically* this is a bug in selinux/policy, and would qualify for an
entry in "nagp"... but:
(1) the changes are small and localised
(2) the problem makes gitolite -- currently -- unusable with selinux,
and what use is a security program which can't run under selinux
(regardless of whose fault it is)?
and finally
(3) if I can't break my own rules for one of my most high-profile users
then what's the point of owning the code?
:-)
----
Implementation notes: I've only done this for code that is likely/meant
to be used in production
I also slip-streamed in a URL fix (from when I changed all the online
document rendering)
since gl-shell-setup runs as root, the comment in the generated key was
'root@...' instead of whatever userid it was being created for.
This does not affect gitolite or ssh but it seems some people don't
treat "comment" and "comment" and actually *do* stuff with it.
(only code is from author; commit message is from committer)
(can_* == can_read, can_write, and can_create)
See top of contrib/adc/adc.common-functions for more on this.
Note: the old style (calling get_rights_and_owner with $repo, then
checking $perm_read, $perm_write, etc.), will still work fine.
gl-shell-setup has a "run as hosting user" piece that basically
automates the adding of the user's (new) key to the admin repo.
This is now gone. (It's not that hard to automate yourself if you want
to do it anyway, using gl-admin-push).
I did this because I needed to allow someone in through a gateway, and
realised that that has the exact same needs. So the whole scheme has
been changed to treat the proxy and the gitolite host as being two
different servers.
At that point it became cumbersome to do the second bit, and I left it
out.
Other changes:
- you can define exceptions for the default shell in gl-shell
- the doc has been simplified.
I got tired of being told "TL;DR". Now the online versions of most
documents fit on a page or two, or at least most of them do. The rest
has been split out (and you can see the links to the split out sections
right where the text is in the raw Markdown).
This is much more pleasant to read, and I've improved the linking so
it's much less effort for me to keep the links correct.
Normally, I use the word "user" in gitolite to mean *my* users, who are
actually admins on their setups. All my documentation has been geared
to that class of person.
Last night my most famous "user" (not "admin", a real gitolite user)
mentioned that he found it very hard to find info on what a *user* could
do, and he was right. So here goes...
- support for ADCs with unchecked arguments
- rsync, htpasswd, and svnserve gone from core; turned into ADCs
Backward compat breakage and fix: Please see documentation for details,
but if you're using gitolite to control rsync you will now need to setup
ADCs (admin defined commands), and install at least the new "rsync" ADC.
----
Thanks to Joey Hess (see commit prior to this) for forcing me to stop
being lazy and get this out of my long term todo list.
- strictly speaking, this should be phrased: "deny" rules for the
first level access check
- requires a gitolite option to be set, like so:
config gitolite-options.deny-repo = 1
also
- new "WEB_INTERFACE" variable (defaults to 'gitweb')
- setup_web_access (write a plain list of repos out)
- add_del_web_access (add/delete a single repo from projects.list)
...for the code, not for the admin ;-)
OK that sounds nasty but really it's not that bad. We're replacing some
code with a one-time step for the admin which is also likely to be more
future-proof.
idea credit: Teemu
otherwise repo names containing "@" in them were causing the @foo part
to be interpolated (as empty of course) instead of being taken literally
reported by silvio dot fricke at googlemail
(and in one other place it needs to be defined earlier)
I never caught this because in my testing those error conditions --
caused by lack of afc3a06 -- never came up.
I'd originally written some minimal documentation for this ADC, but I
liked Jeff's version so much that I borrowed it, added the final section
("important notes for the admin"), made a few other minor fixups, and
then happily ditched my version.
(the ones that require GL_BYPASS_UPDATE_HOOK to be set are done slightly
differently because I just didn't want all the hassle of saving and
restoring that variable on the perl side)
The need for this comes about as follows:
- a project may allow its developers "RWC" (or "RW+C") so that they
can create feature branches when needed. Note that these are
*feature* branches, so they can't use the "personal branches"
mechanism that gitolite already has.
- the developers are *not* given RWCD (or RW+CD) to prevent accidental
deletion of an important branch. Branch *deletion* is something
that only a few trusted admins can do.
- as a result, there are sometimes situations where a developer
creates a misnamed branch and then has to ask the admins to help get
rid of it.
What the KDE folks wanted was a way to allow the creator of a branch to
be able to delete it. In addition, they needed this allowed only for a
fixed duration after the creation of a branch, not forever (for the same
reason they don't get RWCD, to prevent accidents).
These are my reasons why this feature is implemented as an ADC instead
of being "in core":
- we'd need additional syntax to differentiate this special case
(which is sort of in between RWC and RWCD, if you think about it).
I'm reluctant to complicate the syntax further for something that is
only occasionally needed.
- we'd need either (a) code to parse the log files, or, (b) code to
maintain "who created this ref" on every push that creates a ref.
- parsing the log files is too kludgy and inelegant to be in core,
not to mention potentially very slow for really large projects
- code to maintain the a history of "who created this ref" is too
cumbersome, especially because of the need to expire old entries
after a time.
