Skip to content
Commits on Mar 25, 2016
  1. minor install/test suite change

    committed Mar 25, 2016
    perl no longer likes it when you increment a string (where you only care about
    the number at the start).  It does it anyway, but it produces a warning, and
    gitolite's install script does not like that.
Commits on Mar 21, 2016
  1. oops; minor bug in tproxy

    committed Mar 21, 2016
    thanks to Robin Johnson for catching this.
    
    Note it only happens in one very very specific case: when no command is sent
    by the user at all (i.e., "ssh git@host", so even if you don't have this
    patch, the workaround is "ssh git@host info");
Commits on Feb 22, 2016
  1. oops! perl version need not be that high; remove 'use' line

    committed Feb 23, 2016
    (thanks for Johnson Earls for catching this!)
Commits on Feb 20, 2016
  1. v3.6.5

    committed Feb 20, 2016
Commits on Feb 18, 2016
  1. @EugeneKay

    Add support for Github's new TEMPLATE features

    EugeneKay committed with Feb 18, 2016
    Github recently added support for TEMPLATEs for certain Github-specific
    activities, including creating Issues and Pull Requests. This patch
    creates these files as symlinks to the CONTRIBUTING document, which
    explains the process that should be used.
    
    Signed-off-by: Eugene E. Kashpureff Jr <eugene@kashpureff.org>
    
    Committer's note: I still refuse to use pull requests that *require me to go
    to the website and do stuff there*.  But it seems it's easy enough if the
    requestor gives you a number.  In this case, it was
    
        git fetch github refs/pull/78/head
        git merge FETCH_HEAD
Commits on Feb 14, 2016
  1. @pfalcon

    ban repo name ending in ".git"

    pfalcon committed with Feb 13, 2016
    'user.html' says:
    
        The ".git" at the end is optional for git commands (i.e., you can use
        "testing.git" instead of "testing" for clone, fetch, push, etc., if you
        like) but gitolite commands in general will not like the additional ".git"
        at the end.
    
    Until now, we've been catching this trailing ".git" in various commands and
    such, but there are so many programs, it's hard to make sure they all do this
    properly.
    
    This patch catches it deep inside gitolite core.
    
    (based on patch sent by Paul Sokolovsky)
Commits on Feb 6, 2016
  1. allow creator check to be bypassed during mirroring...

    committed Feb 6, 2016
    The original, intended, purpose of wild repos is that they belong to the user,
    and if the user is gone, so should his wild repos.
    
    However, it seems people are using the wild repos thing as a convenience to
    avoid creating actual repo stanzas in the conf file.  For them, the actual
    creator of a repo is more like the gitolite "admin" - his *authority* is being
    to used to create something, but the thing that is created is not tied to his
    *identity*.
    
    Oh well... so be it!
    
    To use, just add
    
        option bypass-creator-check = 1
    
    to the rules for the repo.
Commits on Jan 21, 2016
  1. @fanf2
  2. @skoslowski
Commits on Jan 20, 2016
  1. sshkeys-lint: remove a couple of subs...

    committed Jan 20, 2016
    a couple of subs are now re-defined following 285c4b5 ("sshkeys-lint: use new
    ssh fingerprint functions") because that commit pulls in Common.pm.  One (dbg)
    was subtly different but was not being used anyway, while the other (usage)
    was genuinely redundant.  Got rid of both.
Commits on Jan 19, 2016
  1. @robbat2

    ukm: use new ssh fingerprint functions.

    robbat2 committed with Jan 12, 2016
    UKM was never updated for new-style fingerprints at all.
    
    Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
  2. @robbat2

    sskm: use new ssh fingerprint functions.

    robbat2 committed with Jan 12, 2016
    SSKM was never updated for new-style fingerprints at all.
    
    Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
  3. @robbat2

    sshkeys-lint: use new ssh fingerprint functions.

    robbat2 committed with Jan 12, 2016
    Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
  4. @robbat2

    ssh-authkeys: use new ssh fingerprint functions.

    robbat2 committed with Jan 12, 2016
    Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
  5. @robbat2

    Add helper functions for SSH fingerprints.

    robbat2 committed with Jan 12, 2016
    New Gitolite::Common functions:
    ssh_fingerprint_file
    ssh_fingerprint_line
    
    The existing code for new-style fingerprint did not correctly match on
    some inputs, as it was not strict enough about the MD5-format
    fingerprint. Additionally, some places in the codebase had not been
    updated for new-style fingerprints at all.
    
    Two fingerprints both starting with 'SHA256:34' were matched by the old
    regex as '56:34', instead of a full MD5 fingerprint, and gitolite
    mistakenly thought they were identical. This held for ANY new form
    fingerprint where both the hashname ended with AND the hash content
    started with [0-9a-f]{2}.
    
    Be stricter about the form of the fingerprints instead:
    - MD5 can have a 'MD5:' prefix (new OpenSSH versions only).
    - MD5 has a known length (16 octets of hex digits, with colons)
    - Other hashes are more than just SHA256, but all follow the form
      '$HASHNAME:$base64_str'
    
    This commit introduces the new functions only.
    
    Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
Commits on Jan 13, 2016
Commits on Jan 12, 2016
  1. @fanf2

    ssh-authkeys-split: avoid creating invalid keyfiles

    fanf2 committed with Jan 7, 2016
    Verify that each line from a multiline keyfile is plausible using
    `ssh-keygen -l` to generate a fingerprint. This is similar to the
    check performed by the main ssh-authkeys script, except we don't
    bother checking the fingerprint format in ssh-authkeys-split.
    
    This should reduce the damage due to problems such as stray blank
    lines or unexpected key formats (e.g. PuTTY keys).
Commits on Dec 15, 2015
  1. testing mirror push "one plus one" mode... (read below)

    committed Dec 15, 2015
    Currently, every time someone does a push to a master server, a slave push
    (one for each slave) is triggered.
    
    This is not only wasteful, it also causes too much load.  First of all, pushes
    should be serialised -- there is no point running TWO 'git push --mirror' from
    one server to another.  This means when one push is running, any more pushes
    of the same repo to the same slave must be queued.
    
    But more importantly, it does not make sense to queue more than one!
    
    Hence the "one(running) plus one(queued)" name of the helper script.
Commits on Dec 11, 2015
  1. testing mirror push "one plus one" mode... (read below)

    gitolite tester committed with Dec 11, 2015
    Currently, every time someone does a push to a master server, a slave push
    (one for each slave) is triggered.
    
    This is not only wasteful, it also causes too much load.  First of all, pushes
    should be serialised -- there is no point running TWO 'git push --mirror' from
    one server to another.  This means when one push is running, any more pushes
    of the same repo to the same slave must be queued.
    
    But more importantly, it does not make sense to queue more than one!
    
    Hence the "one(running) plus one(queued)" name of the helper script.
Commits on Nov 26, 2015
  1. @milki

    Enter trigger create-with-reference

    milki committed with Jul 25, 2014
    On repo creation, setup objects/info/alternates for a server side
    alternate object store. The value is configured via `option
    reference.repo`.
    
    Intended to use with forks and mirrors to save network bandwidth.
Commits on Nov 24, 2015
  1. new mirror function: 'status all all'

    committed Nov 25, 2015
    We used to say if you need the status of all slaves for all repos you have to
    roll it yourself, maybe like this:
    
        gitolite list-phy-repos | while read r
        do
            echo ---- $r
            gitolite mirror list slaves $r
        done
    
    This isn't great for automation.
    
    The new feature simply prints a list of repos that have *some* error, which is
    arguably more useful for further action/processing.
Commits on Nov 23, 2015
Commits on Nov 15, 2015
  1. skip self in slave list...

    committed Nov 15, 2015
    makes creating slave lists a lot more convenient for some cases; see
    https://groups.google.com/forum/#!topic/gitolite/_jL--PR0AXM
  2. repo specific hooks:

    committed Nov 15, 2015
    -   allow incrementally adding more repo-specific hooks
    
        see https://groups.google.com/forum/#!topic/gitolite/YcfuFDzhq4A
    
    -   allow gitolite-admin repo also to be "hooked" (but not post-update of
        course)
    
        see https://groups.google.com/forum/#!topic/gitolite/zAi4H1OKkgI
Commits on Nov 11, 2015
Commits on Nov 1, 2015
  1. v3.6.4

    committed Nov 1, 2015
  2. access -s: better error message for ^C on existing repo...

    committed Oct 18, 2015
    because "this should not happen"... happened!
    
    (thanks to hseg on irc for catching this)
  3. fix ref-create permission bug on wild repos

    gitolite tester committed with Oct 16, 2015
    TLDR: users are able to *create* new refs that they are not supposed to.
    Upgrading gitolite is not mandatory; there is a workaround within the conf
    syntax itself (see below).
    
    The bug shows up if the following four conditions are satisfied:
    
        repo foo/..*                    # 1 (see below)
            C       =   @all            # 2
            RW+CD   =   CREATOR         # 3
            RW      =   special_user    # 4
    
    1.  must be a wild repo
    2.  the create-repo line must allow "special_user(s)"
    3.  there is at least one rule containing RW.*C in the repo
    4.  the intent is that special user(s) can ff-push but cannot *create* refs
        since they have only RW; for a refresher on this, see
        http://gitolite.com/gitolite/conf.html#write-types
    
    In such cases, the restriction on creating a ref is ignored.  (Only creation
    is affected; the bug does not affect delete, rewind permissions).
    
    In general, this is a relatively minor bug.  No data is destroyed, and no data
    is leaked.  Some cleanup of useless refs may be required if someone has
    (ab)used this.  At worst this could be a potential DOS, but I have never
    considered DOS to be a valid concern when it requires *authorised* users.
    
    If you have such a conf, and cannot immediately upgrade, there is a
    workaround:
    
        repo foo/..*
            RW+CD   =   CREATOR
            RW      =   special_user
    
            -       =   special_user    # add a deny rule for the special user(s)
            C       =   @all            # move the repo-create perm to the end,
                                        # *after* the deny rule above
    
    (Thanks to hseg on #gitolite for catching this and being tenacious about it!
    At first, I was arrogant enough to reject the idea that such a bug could
    exist; it took me a bit to get the right conditions in place and see the
    problem!)
Commits on Oct 16, 2015
  1. minor fixups to 'perms' command:

    gitolite tester committed with Oct 16, 2015
    -   when list_roles is invoked as part of the error reporting for an invalid
        role (as opposed to being explicitly asked for by option '-lr'), the
        output should go to STDERR, just like the error message.
    
    -   the Ctrl-C stuff doesn't work when the user is sharing multiple ssh
        sessions over a single connection (see, ControlMaster, ControlPersist,
        etc., in 'man ssh_config').  Replaced it with a more explicit means to
        allow a user who inadvertently walked into this mode of operation to
        gracefully get out.
    
    Thanks to Stephane Chazelas on the mailing list[1] for reporting the issues,
    subsequent discussion, and patches which I was able to modify as needed.
    
    [1]: https://groups.google.com/forum/#!topic/gitolite/Fcw1Et9PGmw
Commits on Oct 9, 2015
Commits on Aug 14, 2015
  1. minor typo in pattern...

    committed Aug 14, 2015
    note that this does not affect anything, since the 6 extra characters that
    would be matched are not part of the base64 character set anyway, so they
    should not be *produced* by your ssh-keygen.
    
    thanks to 'ayekat' on irc pointing me to a comment on the commit on github.
    (Please don't put stuff on github and expect me to find it; I prefer plain old
    email because -- among other things -- I don't want to insist that you have a
    github account in order to discuss gitolite).
Commits on Jun 6, 2015
  1. contrib: redmine user alias

    gitolite tester committed with Jun 6, 2015
Something went wrong with that request. Please try again.