Get Gentoo!
gentoo.org sites
gentoo.org Wiki Bugs Forums Packages
Planet Archives Sources
Infra Status
summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* v3.6.5v3.6.5Sitaram Chamarty2016-02-201-0/+19
|
* Add support for Github's new TEMPLATE featuresEugene E. Kashpureff Jr2016-02-182-0/+2
| | | | | | | | | | | | | | | | 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
* ban repo name ending in ".git"Paul Sokolovsky2016-02-141-0/+1
| | | | | | | | | | | | | | | | | '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)
* allow creator check to be bypassed during mirroring...Sitaram Chamarty2016-02-062-2/+6
| | | | | | | | | | | | | | | | | | | 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.
* who-pushed: avoid undefined variable warnings before printing usageTony Finch2016-01-211-2/+3
|
* (minor) make sure <user> was passed in access commandSebastian Koslowski2016-01-211-1/+1
|
* sshkeys-lint: remove a couple of subs...Sitaram Chamarty2016-01-201-12/+2
| | | | | | | 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.
* ukm: use new ssh fingerprint functions.Robin H. Johnson2016-01-191-4/+4
| | | | | | UKM was never updated for new-style fingerprints at all. Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
* sskm: use new ssh fingerprint functions.Robin H. Johnson2016-01-191-3/+4
| | | | | | SSKM was never updated for new-style fingerprints at all. Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
* sshkeys-lint: use new ssh fingerprint functions.Robin H. Johnson2016-01-191-20/+12
| | | | Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
* ssh-authkeys: use new ssh fingerprint functions.Robin H. Johnson2016-01-191-10/+5
| | | | Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
* Add helper functions for SSH fingerprints.Robin H. Johnson2016-01-191-0/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* allow pre-auto-gc also when adding repo specific hooksSitaram Chamarty2016-01-131-2/+2
|
* ssh-authkeys-split: avoid creating invalid keyfilesTony Finch2016-01-121-5/+9
| | | | | | | | | | 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).
* testing mirror push "one plus one" mode... (read below)Sitaram Chamarty2015-12-151-4/+4
| | | | | | | | | | | | | | 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.
* testing mirror push "one plus one" mode... (read below)gitolite tester2015-12-112-2/+45
| | | | | | | | | | | | | | 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.
* Enter trigger create-with-referencemilki2015-11-263-0/+89
| | | | | | | | 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.
* new mirror function: 'status all all'Sitaram Chamarty2015-11-251-5/+22
| | | | | | | | | | | | | | | | 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.
* add repo name to mirror status outputSitaram Chamarty2015-11-241-2/+3
|
* add line about ^C to usage message of access commandSitaram Chamarty2015-11-241-0/+3
|
* skip self in slave list...Sitaram Chamarty2015-11-151-0/+1
| | | | | makes creating slave lists a lot more convenient for some cases; see https://groups.google.com/forum/#!topic/gitolite/_jL--PR0AXM
* repo specific hooks:Sitaram Chamarty2015-11-152-28/+58
| | | | | | | | | | | - 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
* add security warning to 'config' commandSitaram Chamarty2015-11-111-1/+8
|
* v3.6.4v3.6.4Sitaram Chamarty2015-11-011-0/+15
|
* access -s: better error message for ^C on existing repo...Sitaram Chamarty2015-11-011-2/+5
| | | | | | because "this should not happen"... happened! (thanks to hseg on irc for catching this)
* fix ref-create permission bug on wild reposgitolite tester2015-11-012-2/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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!)
* minor fixups to 'perms' command:gitolite tester2015-10-161-3/+5
| | | | | | | | | | | | | | | | | - 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
* Add script to pull and sanitize Active Directory user groupsJonathan Gray2015-10-091-0/+40
|
* Add documentation for using Active Directory authentication via ApacheJonathan Gray2015-10-091-0/+47
|
* minor typo in pattern...Sitaram Chamarty2015-08-141-1/+1
| | | | | | | | | | | 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).
* contrib: redmine user aliasgitolite tester2015-06-061-0/+55
|
* Alias.pm learns a few more tricks...Sitaram Chamarty2015-05-311-6/+53
| | | | | | | | | (thanks to Nicholas Clark for the first requirement) - allow replacement by "prefix" - allow customised warning message (to better warn users of the new repo name) - allow "inform and abort" -- forces users to switch to the new name
* create command: remove race condition...Sitaram Chamarty2015-05-271-3/+4
| | | | | | | | | | | | | | | | | | | | | | | Because of the pipe in the create command, 'gitolite git-config' and 'perms -c' would run simultaneously. The problem was, if git-config ran between these two statements in new_wild_repo() in Store.pm: new_repo($repo); # 'gitolite git-config' runs here _print( "$repo.git/gl-creator", $user ); *and* the repo pattern had CREATOR in it, it would not return the correct values for the default.roles options, since the repo pattern would not be deemed to match the actual repo (between creator() and generic_name()). Thanks to Ronald Wirth for catching this; see [1] for details. [1]: https://groups.google.com/forum/#!topic/gitolite/5Dv6ViDmfF4 ---- ...and while we're about it, I changed it to use /bin/sh and smoke tested it using "dash", which I believe is close enough.
* make single quotes around reponame optional...Sitaram Chamarty2015-05-271-1/+1
| | | | | | | apparently the git client, when using ext:: transports, does not send those quotes https://groups.google.com/forum/#!topic/gitolite/x8rUaxJU0iM
* 'who-pushed' learns super-efficient 'tip search'Sitaram Chamarty2015-05-191-3/+16
|
* Don't overwrite gl-log on each flush in who-pushedmilki2015-05-141-1/+7
| | | | | _print always overwrites the target file. Empty the file at the beginning of the migrate run but subsequently append new entries.
* make who-pushed more efficient...Sitaram Chamarty2015-05-123-25/+136
| | | | | | | | | | | | | - add (commented out) values to LOG_DEST in the default rc file to allow 'repo-log' as a destination - make gl_log() respect this and append update log records to a file called 'gl-log' within the bare repo dir. (This is only the update log records, not everything.) - let 'who-pushed' use gl-log if found, and the normal ones (much slower) only if not - add more help to who-pushed - help admin migrate log records (or rather, generate the new ones from the normal gitolite logs)
* change the usage() semantics slightly...Sitaram Chamarty2015-05-111-3/+3
| | | | to better accommodate additional custom help messages
* gitolite query-rc --dump (or -d)Sitaram Chamarty2015-05-111-2/+14
|
* (minor) fix typoTony Xue2015-05-031-1/+1
|
* v3.6.3v3.6.3Sitaram Chamarty2015-04-261-0/+23
|
* allow limited remote use of 'git config'gitolite tester2015-04-261-0/+88
|
* git-annex-shell: accept repo paths without '~/'Benoît Knecht2015-04-261-1/+2
| | | | | It seems that (some versions of) git-annex use repository paths that simply start with '/' instead of '/~/', so make the '~/' part optional.
* openssh 6.8 again... forgot sshkeys-lint the last time!Sitaram Chamarty2015-04-221-1/+2
|
* fix minor bugly in permsSitaram Chamarty2015-03-301-1/+1
| | | | reminder: bugly = bug that makes something look ugly :)
* openssh 6.8 compatSitaram Chamarty2015-03-191-1/+1
|
* allow repo symlinks while still being paranoid...Sitaram Chamarty2015-03-132-6/+7
| | | | | | | | | | | | | | | | | I don't like "find -L" in a security program. Period. If you MUST keep some of your repos somewhere else, you'll need to do it this way. Let's say all the repos under foo/bar and baz are actually on a different disk. That is, ~/repositories/foo/bar is a symlink to some other disk, as is ~/repositories/baz. Then add this to the rc file somewhere in the "rc variables used by various features" section: REPO_SYMLINKS => "foo/bar/ baz/", DON'T forget the trailing slash at the end of each name, and the comma outside.
* lineup the info display fieldsSitaram Chamarty2015-03-131-10/+14
|
* perms: list available roles, plus several other changes...Sitaram Chamarty2015-03-138-30/+85
| | | | | | | | | | | | | (much thanks to Tony Finch!) - show valid roles and their access rights, for the given repo ("-lr") - check a role not just against the rc, but against the roles that this specific repo actually uses, which may be a smaller subset. (This is the most important improvement in this patch; the rest is just fluff!) - fixup usage message WARNING: minor backward compat breakage: 'ssh ... perms -l repo' no longer works; the '-l' goes *after* the repo name now.
* prevent info leak when gitolite-shell is used as $SHELL...Sitaram Chamarty2015-03-041-1/+1
| | | | | The error message is explicitly the same as you get when you do send in an invalid git/gitolite command; this is by design.