| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The 'integration' with Gitolite is honestly pretty bad and should not be
taken very seriously: it runs the 'gitolite access' command to check if
some user (e.g., daemon/nobody) should be able to read from the
repository. Based on this, it grants access to objects stored in S3, by
generating Presigned GetObject URLs using the S3 API.
Of course, this integration with Gitolite (especially when using the
daemon user to check if the user should be able to read) is not very
'high-value':
1. If we already make use of the daemon pseudo-user to control access to
public repositories, we may as well check for the existence of
git-daemon-export-ok files. In case they exist, we simply assume that
the repository is meant to be shown on the public internet and that
therefore the LFS archive should also be considered 'open to the
public'.
2. The way that Gitolite commands are currently run, this program breaks
when not running under the git user without extra configuration;
Gitolite decides where repositories are based on the HOME environment
variable. This program currently does not set this. This could be set
by the CGI server (or fcgiwrap) and would unbreak the system.
There's no support for any more advanced kind of authn/authz. Uploading
is also not supported yet. That's still to come.
|
Rutger Broekhoff