diff options
author | 2014-08-19 18:05:47 +0530 | |
---|---|---|
committer | 2014-08-19 19:27:12 +0530 | |
commit | 0bcd962df3e69f5d1050c51753473d3d7cc4dcff (patch) | |
tree | fd0ef5fda473ca94c4f6aa3a4a5d9107a96990fc /t | |
parent | enforce the full path requirement in 'install' (diff) | |
download | gitolite-gentoo-0bcd962df3e69f5d1050c51753473d3d7cc4dcff.tar.gz gitolite-gentoo-0bcd962df3e69f5d1050c51753473d3d7cc4dcff.tar.bz2 gitolite-gentoo-0bcd962df3e69f5d1050c51753473d3d7cc4dcff.zip |
ssh-authkeys: update authkeys when keydir is present but empty
When ~/.gitolite/keydir is present but empty, and someone runs 'gitolite
trigger POST_COMPILE', gitolite does not clear out the corresponding lines in
~/.ssh/authorized_keys.
----
NOTE that this can only happen when you're managing gitolite directly on the
server, per http://gitolite.com/gitolite/odds-and-ends.html#server-side-admin.
When you're managing gitolite remotely, and you 'git rm -rf keydir' in your
admin clone, then commit and push, this behaviour (of not updating the
authkeys file in ~/.ssh) will remain.
However, it's not by design -- it's more of a lucky accident! What's
happening here is, when ~/.gitolite is updated via a "git checkout -f", the
(now empty) 'keydir' directory is *completely deleted*. This makes
ssh-authkeys bail much earlier, because now it looks like a system that is not
even *using* ssh keys (for example, an http-mode installation).
The end result is the same -- the authkeys file is left untouched. However, I
will not be "fixing" that, for obvious reasons.
Diffstat (limited to 't')
-rwxr-xr-x | t/ssh-authkeys.t | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/t/ssh-authkeys.t b/t/ssh-authkeys.t index a9b1457..46b9413 100755 --- a/t/ssh-authkeys.t +++ b/t/ssh-authkeys.t @@ -28,7 +28,7 @@ try " cd $kd; ok $pgm; ok; /authorized_keys missing/ /creating/ - wc < $ak; ok; /0 *0 *0/ + wc < $ak; ok; /2 *6 *32/ # some gl keys ssh-keygen -N '' -q -f alice -C alice ssh-keygen -N '' -q -f bob -C bob |