| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
|
| |
|
|
| |
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
|
| |
|
|
| |
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
|
| |
|
|
| |
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
|
| |
|
|
| |
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
|
| |
|
|
| |
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
|
| |
|
|
| |
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
|
| |
|
|
| |
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
|
| |\
| |
| |
| |
| |
| | |
v3.6.13
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
also see https://groups.google.com/g/gitolite/c/1c10gD1j7Tc/m/6RlShCgbAAAJ for some discussion
|
| |\| |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Historically, this hook put the certs in a ref named refs/push-certs.
However, git does *NOT* replicate single-level refs, and this meant that
gitolite mirroring did not replicate the push-certs!
Trying to push them explicitly causes this error:
```
remote: error: refusing to create funny ref 'refs/push-certs' remotely
```
Upstream Git has good reasons as to why not to replicate single-level
refs: https://lore.kernel.org/git/robbat2-20211115T063838-612792475Z@orbis-terrarum.net/
As a good-enough solution, use the namespace of meta/ for the refs.
This is already used in other systems:
- kernel.org refs/meta/cgit
- gerrit refs/meta/config
- GitBlit reflog: refs/meta/gitblit https://www.gitblit.com/administration.html#H12
- cc-utils refs/meta/ci
- JGit refs/meta/push-certs https://www.ibm.com/docs/en/radfws/9.6.1?topic=SSRTLW_9.6.1/org.eclipse.egit.doc/help/JGit/New_and_Noteworthy/4.1/4.1.htm
To migrate from old to new, for each repo, you must explicitly run:
git update-ref refs/meta/push-certs refs/push-certs
Then the hook will populate both refs.
You can remove the old ref after that:
git update-ref -d refs/push-certs
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Historically, this hook put the certs in a ref named refs/push-certs.
However, git does *NOT* replicate single-level refs, and this meant that
gitolite mirroring did not replicate the push-certs!
Trying to push them explicitly causes this error:
```
remote: error: refusing to create funny ref 'refs/push-certs' remotely
```
Upstream Git has good reasons as to why not to replicate single-level
refs: https://lore.kernel.org/git/robbat2-20211115T063838-612792475Z@orbis-terrarum.net/
As a good-enough solution, use the namespace of meta/ for the refs.
This is already used in other systems:
- kernel.org refs/meta/cgit
- gerrit refs/meta/config
- GitBlit reflog: refs/meta/gitblit https://www.gitblit.com/administration.html#H12
- cc-utils refs/meta/ci
- JGit refs/meta/push-certs https://www.ibm.com/docs/en/radfws/9.6.1?topic=SSRTLW_9.6.1/org.eclipse.egit.doc/help/JGit/New_and_Noteworthy/4.1/4.1.htm
To migrate from old to new, for each repo, you must explicitly run:
git update-ref refs/meta/push-certs refs/push-certs
Then the hook will populate both refs.
You can remove the old ref after that:
git update-ref -d refs/push-certs
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
|
| |\| |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
with perl 5.32.0 trying to use ukm gives:
```
$ ssh gitolite@localhost ukm
Enter passphrase for key '/home/kousu/.ssh/id_rsa':
FATAL: Can't use global $_ in "my" at /usr/lib/gitolite/commands/ukm line 296, near "($_"
Execution of /usr/lib/gitolite/commands/ukm aborted due to compilation errors.
```
This fixes it
```
$ ssh gitolite@localhost ukm list
Enter passphrase for key '/home/kousu/.ssh/id_rsa':
Hello alice, you manage the following keys:
fingerprint userid keyid
SHA256:VxHhqhOq5GxpPPUrYMeFMly4Mdc3YlP40qkLX4gr5fI alice alice
```
|
| |\|
| |
| |
| | |
v3.6.12
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This affects the mirroring code and documentation:
"slave"/"slaves" are now "copy"/"copies".
Backward compatibility should be maintained; you do not need to
change either your gitolite.conf, or any scripts you have
written on top, until you are ready to do so. (This in turn
means the word "slave" will still be present in the code, though
only just as much as needed.)
Should you wish to make this change, you need to migrate to the
latest version (which is also tagged as 3.6.12, so if you want
to wait till the distros pick it up wait for that), and then:
- In the gitolite.conf file, change `option mirror.slaves` to
`option mirror.copies`.
- If you have any scripts that use the `gitolite mirror list
slaves` command, change to `gitolite mirror list copies`.
sitaram
|
| |\| |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This command:
ssh git@host config my/wild/repo --add gitweb.owner "Sitaram Chamarty"
doesn't work. Sshd converts it to
config my/wild/repo --add gitweb.owner Sitaram Chamarty
so by the time src/commands/config sees this, that looks like two
"values" ("Sitaram" and "Chamarty") instead of one.
We can't do much about this in the general case; that's how sshd rolls.
I suppose we could, in parse_soc() in src/gitolite-shell, use something
like Text::ParseWords instead of a simple "split" (and then send in
arguments with backslash-escaped spaces etc) but that's too big a change
impacting too many things. Not going to happen for this simple need.
The simplest way out is for src/commands/config to learn that multiple
trailing arguments are actually one space-separated argument.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Technically, the previous behaviour could even be called a "feature", in
that it allowed you to use regexes for users -- contradicting the
documentation! -- in the following way:
@foo = u[123] u9
repo bar
RW+ = @foo
which would enable users u1, u2, and u3 to access bar.
I thought for a bit about this, and decided to fix the code rather than
the documentation.
Leaving it as a quirk was another alternative, but it would only be a
quirk [1], and an incomplete one at that because it only works for
patterns inside *groups*, not patterns that are actually *on* the rule
line (e.g. RW+ = u[123]). No good...
Thanks to Steven Peckins for catching this.
[1]:
$ dict quirk
From The Collaborative Fictional Dictionary of English v.0.48 [gcide]:
Quirk \Quirk\ (kw[~e]rk), n. [Written also {querk}.]
1. a bug that doesn't do enough harm to be shot down with extreme
prejudice, and in fact might even be said to do something
vaguely OK. If you squint. And if it's a Sunday.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There are two points to consider here:
- is the user trying to delete all hooks for a repo?
- is it a reserved hook (one we should not be touching)
The second one is more important; the first one is a spurious warning
that is at worst an aesthetic problem.
Unfortunately, when refactoring to fix a bug in 7898f9b, I gave higher
priority to the wrong issue, and the more important one was not checked
when the less important one was "true".
As a result, control moved to the second stage, where hooks were
symlinked to the multi-hook driver. Including the all important
'post-update' hook in 'gitolite-admin'.
Ouch!
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If a reference is deleted in a repository where this virtual ref is
active, the script is not capable of handling it correctly:
remote: fatal: bad object 0000000000000000000000000000000000000000
remote: error: unable to find 0000000000000000000000000000000000000000
remote: fatal: Not a valid object name
0000000000000000000000000000000000000000
This patch fixes the issue.
[commit message and patch modified slightly by Sitaram]
|
| | |
| |
| |
| |
| | |
git 2.18 (and above) does not leave an empty section header lying around
when the key and value are deleted using 'git config --unset'
|
| |\|
| |
| |
| | |
v3.6.11
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Nick Cleaton (nick@cleaton.net) found and reported a security issue
caused by trusting the remote rsync too much. It appears that rsync
cannot -- without special precautions -- be used in any "restricted"
environment.
Gitolite ships with a "bundle helper" called "rsync" (disabled
by default; more details below). This fix tightens up this
helper to close this hole.
TLDR for administrators and packagers:
1. Am I affected?
Look in ~/.gitolite.rc for "rsync"; if it is there, you are
affected.
This is NOT an essential program, and it is not enabled by
default. You (or a previous administrator of your site)
would have to have explicitly enabled it for you to be
affected.
2. What's the quick fix?
Comment out the "rsync" line in ~/.gitolite.rc IMMEDIATELY.
DO NOT LEAVE IT ENABLED IF YOU ARE UNABLE TO UPGRADE IMMEDIATELY!
Uncomment it only after you have upgraded or patched.
3. That bad, huh?
Sadly, yes :(
DETAILS:
This program is not a core program. Despite the name, it will not
function as a generic "rsync".
This is *only* meant to help out people who are on flaky connections,
trying to clone a large repo.
Because git clone is not resumable, one common technique is to have
someone create a "bundle", then download the bundle to seed the local
repo, then "git fetch" to finish off. Since the bundle is a single
file, you can use resumable mechanisms (like rsync) to download it.
What this command does is allow that kind of bundling to happen
automatically, if an administrator enables it.
The user simply rsyncs a bundle file using his gitolite
credentials. As a result, the rsync helper command that ships
with gitolite is executed. This program manages the creation
and expiry of bundle files, then passes control to the *real*
rsync program to perform the actual data transfer.
It is this last step that requires special care when used in a
restricted environment, resulting in the need for this patch.
|
| | | |
|
| | | |
|
| | | |
|
| |\|
| |
| |
| | |
v3.6.10
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
dc13dfc introduced a block on accessing repos which are in the process
of being moved into gitolite's control.
This block was (a) in gitolite-shell, which would catch all git-client
activity and (b) in list_phy_repos(), which would prevent those repos
from being seen by the 'info' command.
Unfortunately that was stupid; it also blocked 'gitolite setup' itself,
because setup uses list_phy_repos!
The correct place to put this was always going to be access(), but I had
initially shied away from that because it would cause a slight glitch in
the working of any POST_COMPILE trigger scripts that used the access()
function on any of the newly migrated repos.
But nothing else really works. As a result, the step where you run
`gitolite setup` when importing now becomes:
gitolite compile
gitolite setup --hooks-only
gitolite trigger POST_COMPILE
|
| |\|
| |
| |
| | |
v3.6.9
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
David Bremner found that 'gitolite trigger foo', where foo is some
arbitrary string, silently no-ops.
The "gitolite trigger X" command only makes sense when X is POST_COMPILE
or POST_CREATE, or, if it's a custom trigger type [1], when there is a
section with that name in the rc file with a list of scripts to run.
Anything else is an error, and should not silently no-op.
[1]: for example, http://gitolite.com/gitolite/odds-and-ends/#using-pubkeys-obtained-from-elsewhere
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Björn Kautler pointed out that, when a repo is being migrated into
gitolite as per the documentation [1], there is a gap between the actual
move of the repo and the rest of the process where a user can gain read
or write access to the repo, which he would *not* have had after the
completion of the process.
My first thought was to document this, and advise people to use the
'writable' command to disable writes, but there is nothing as simple and
painless to prevent reads. (On the plus side, this kind of racy read
access can only happen if the conf is using the "deny-rules" option to
restrict reads; without that, it makes no difference -- i.e., he gets no
access that he would not have got later anyway).
But eventually I realised that documentation was frustrating, for
various reasons, and that at least in this case there is a way to fix it
in the code -- just block all access to a repo that is in
~/repositories, but which does not yet have the update hook setup
correctly. Plus, the code does not impact anything else, and is
basically just an extra check.
[1]: http://gitolite.com/gitolite/basic-admin/index.html#appendix-1-bringing-existing-repos-into-gitolite
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Björn Kautler pointed out that for VREFs suffering fallthru, the
interpretation of the result of access would be wrong.
Initially, I was reluctant to make that adjustment here. The 'access'
command is meant to be just a shell entry point for the access()
function, nothing more, so bringing in adjustments that occur elsewhere
in gitolite would not be right.
But it makes automated testing for VREF rules more difficult (and VREFs
are already hard enough for most people to understand), so I caved.
Hopefully this won't turn into a slippery slope...
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
C was being handled incorrectly, while M was not even considered (and
would behave as if MERGE_CHECK was set)
thanks to Björn Kautler
|
Robin H. Johnson
Sitaram Chamarty
Nick
Thomas Gerbet
GitWeb