| 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.
|
| | |
|
| | |
|
|
|
bin/authorized_keys doesn't check that the requesting user matches the expected
user, so to enable database authorized keys lookups, we currently ask the admin
to create a custom script for that purpose.
Better is to have a complete script that can perform the whole task. This commit
introduces bin/gitlab-shell-authorized-keys-check which does so.
|
