aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorSitaram Chamarty <sitaram@atc.tcs.com>2014-08-19 18:05:47 +0530
committerSitaram Chamarty <sitaram@atc.tcs.com>2014-08-19 19:27:12 +0530
commit0bcd962df3e69f5d1050c51753473d3d7cc4dcff (patch)
treefd0ef5fda473ca94c4f6aa3a4a5d9107a96990fc /contrib
parentenforce the full path requirement in 'install' (diff)
downloadgitolite-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 'contrib')
0 files changed, 0 insertions, 0 deletions