| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We had `gitlab-shell-authorized-keys-check` and
`gitlab-shell-authorized-principals-check` as symlinks to
`gitlab-shell` before.
We determine the `Command` and `CommandArgs` that we build based
on the `Name` of the `Executable`. We also use that to know which
fallback ruby executable should we fallback to. We use
`os.Executable()` to do that.
`os.Executable()` behaves differently depending on OS. It may
return the symlink or the target's name. That can result to a
buggy behavior.
The fix is to create binaries for each instead of using a symlink.
That way we don't need to rely on `os.Executable()` to get the name.
We pass the `Name` of the executable instead.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rename the ruby scripts to have `-ruby` suffix and add a symlink
for both to `./gitlab-shell`. The executable name will be used to
determine how args will be parsed.
For now, we only parse the arguments for gitlab-shell commands. If
the executable is `gitlab-shell-authorized-keys-check` or
`gitlab-shell-authorized-principals-check`, it'll always fallback
to the ruby version.
Ruby specs test the ruby script, the fallback from go to ruby and
go implementation of both (still pending).
|
| |
|
|
|
| |
This reverts commit 3aaf4751e09262c53544a1987f59b1308af9b6c1, reversing
changes made to c6577e0d75f51b017f2f332838b97c3ca5b497c0.
|
| | |
|
| | |
|
|
|
This along with the code submitted to gitlab-ce in the
gitlab-org/gitlab-ce! MR implements SSH certificate
authentication. See the docs added to gitlab-ce for why and how to
enable this. This, along with that MR, closes
gitlab-org/gitlab-ce#3457
Implementation notes:
- Because it's easy to do, and because an earlier nascent version of
this would pass user-ID to gitlab-shell, that's now supported, even
though the SSH certificate authentication uses username-USERNAME.
- The astute reader will notice that not all the API calls in
gitlab-ce's lib/api/internal.rb support a "username" argument, some
only support "user_id".
There's a few reasons for this:
a) For this to be efficient, I am bending over backwards to avoid
extra API calls when using SSH certificates.
Therefore the /allowed API call will now return a "user id" to
us if we're allowed to proceed further. This is then fed to
existing APIs that would only be called after a successful
call to /allowed.
b) Not all of the git-shell codepaths go through
/internal/allowed, or ever deal with a repository, e.g. the
argument-less "Welcome to GitLab", and
/internal/2fa_recovery_codes. These need to use
/internal/discover to figure out details about the user, so
support looking that up by username.
c) Once we have the "user id", the GL_ID gets passed down to
e.g. user-authored hooks. I don't want to have those all break
by having to handle a third GL_ID mode of "username" in
addition to the current "key id" and "user id".
|
