the dupkeys function was already in ssh-authkeys...
...so there's no need for the VREF. Ironically, while I was arguing with Eli that I wouldn't do it and why, the code was *already* there, and had been for over a month! (It must have been there for much longer for me to have forgotten!) TODO: convert from using fingerprint compute to actual key strings when the complaints about speed start appearing. My own personal speed up loop [1] I guess :) [1]: http://thedailywtf.com/Articles/Classic-WTF-The-Speedup-Loop.aspx
This commit is contained in:
parent
699bafa096
commit
fa2893be7c
|
@ -16,12 +16,6 @@ Here's an example to start you off.
|
||||||
Now dev2 and dev3 cannot push changes that affect more than 9 files at a time,
|
Now dev2 and dev3 cannot push changes that affect more than 9 files at a time,
|
||||||
nor those that have more than 3 new files.
|
nor those that have more than 3 new files.
|
||||||
|
|
||||||
Another example is detecting duplicate pubkeys in a push to the admin repo:
|
|
||||||
|
|
||||||
repo gitolite-admin
|
|
||||||
# ... normal rules ...
|
|
||||||
- VREF/DUPKEYS = @all
|
|
||||||
|
|
||||||
----
|
----
|
||||||
|
|
||||||
## rule matching recap
|
## rule matching recap
|
||||||
|
@ -63,7 +57,7 @@ the VREF only in "deny" rules.
|
||||||
|
|
||||||
This in turn means any existing update hook can be used as a VREF *as-is*, as
|
This in turn means any existing update hook can be used as a VREF *as-is*, as
|
||||||
long as it (a) prints nothing on success and (b) dies on failure. See the
|
long as it (a) prints nothing on success and (b) dies on failure. See the
|
||||||
email-check and dupkeys examples later.
|
email-check example later.
|
||||||
|
|
||||||
## how it works -- overview
|
## how it works -- overview
|
||||||
|
|
||||||
|
|
|
@ -1,45 +0,0 @@
|
||||||
#!/bin/bash
|
|
||||||
|
|
||||||
# gitolite VREF to detect duplicate public keys
|
|
||||||
|
|
||||||
# see gitolite doc/vref.mkd for what the arguments are
|
|
||||||
sha=$3
|
|
||||||
|
|
||||||
# git sets this; and we don't want it at this point...
|
|
||||||
unset GIT_DIR
|
|
||||||
|
|
||||||
# paranoia
|
|
||||||
set -e
|
|
||||||
|
|
||||||
# setup the temp area
|
|
||||||
export TMPDIR=$GL_REPO_BASE_ABS
|
|
||||||
export tmp=$(mktemp -d -t gl-internal-temp-repo.XXXXXXXXXX);
|
|
||||||
trap "rm -rf $tmp" EXIT;
|
|
||||||
|
|
||||||
git archive $sha keydir | tar -C $tmp -xf -
|
|
||||||
# DO NOT try, say, 'GIT_WORK_TREE=$tmp git checkout $sha'. It'll screw up
|
|
||||||
# both the 'index' and 'HEAD' of the repo.git. Screwing up the index is
|
|
||||||
# BAD because now it goes out of sync with $GL_ADMINDIR. Think of a push
|
|
||||||
# that had a deleted pubkey but failed a hooklet for some reason. A
|
|
||||||
# subsequent push that fixes the error will now result in a $GL_ADMINDIR
|
|
||||||
# that still *has* that deleted pubkey!!
|
|
||||||
|
|
||||||
# And this is equally applicable to cases where you're using a
|
|
||||||
# post-receive or similar hook to live update a web site or something,
|
|
||||||
# which is a pretty common usage, I am given to understand.
|
|
||||||
|
|
||||||
cd $tmp
|
|
||||||
|
|
||||||
for f in `find keydir -name "*.pub"`
|
|
||||||
do
|
|
||||||
ssh-keygen -l -f "$f"
|
|
||||||
done | perl -ane '
|
|
||||||
die "FATAL: $F[2] is a duplicate of $seen{$F[1]}\n" if $seen{$F[1]};
|
|
||||||
$seen{$F[1]} = $F[2];
|
|
||||||
'
|
|
||||||
|
|
||||||
# as you can see, a vref can also 'die' if it wishes to, and it'll take the
|
|
||||||
# whole update with it if it does. No messing around with sending back a
|
|
||||||
# vref, having it run through the matches, and printing the DENIED message,
|
|
||||||
# etc. However, if your push is running from a script, and that script is
|
|
||||||
# looking for the word "DENIED" or something, then this won't work...
|
|
Loading…
Reference in a new issue