(minor) move a small chunk of code out of a loop
call GROUPLIST_PGM before determining user_roles()...

thanks to Stephane Chazelas [1]

[1]: https://groups.google.com/d/topic/gitolite/gy_ZkrxGSjg
(security) fix bug in pattern to detect path traversal

while we're about it, add the same check to some of the internal
routines, so that commands can also be protected.

finally, just to make sure we don't lose it again in some other fashion,
add a few tests for path traversal...
v3.1
Fix spurious error in triggers/upstream

The initial fetch of a new repo which has 'upstream' read-only mirroring
configured will cause a spurious error concerning FETCH_HEAD not yet
existing. This silences the error.
(minor) clarify that D only works on wild repos
(minor) bash -> sh changes in some non-core code

/bin/bash is muscle memory for me, although it appears that not too much
of the actual code is bash-specific, so it's reasonably easy to fix.
(test suite) stop using 'ls' to test for presence/absence of files/directories

another of those "duh!  what was I thinking" moments, this specific one
being "why test that files/directories are created with the right user
and group IDs?  Shouldn't that be out of your control, as well as
totally unnecessary on a sane system?"
fix for keysubdirs-as-groups sugar script to support "old style multi-keys" for users
(minor fixups to some non-code parts)
make sure gl-perms exists, even if it is empty...

I expect this to help if we optimise the rule generation by caching.
move %GL_REPO and %GL_CREATOR substitution into core

see usage example at the end of src/triggers/upstream
some minor rearrangements of code...

why?  now that would be telling!
(minor) add quick and dirty timer code to Common.pm
help run some trigger programs in the background
gl-conf must be created even if the repo para has only config lines

(i.e., no access rules but only config lines)
refex-expr: die when admin forgets to add the required line to the rc
allow multi-line pubkeys; see code for doc
Uggh; horrible inner loop screwing up all performance :-(

This might actually make the redis version unnecessary for most people!
And if it does, well shame on me for not instrumenting things at a more
granular level before going all "oh we need a cache!"

[In my defense, I blame redis for being such a sweet little tool that I
felt compelled to use it somehow!]

----

t/sequence failed because the test itself was in error; fixed.
v3.2