aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* Add 'lfs/objects' part to pathLibravatar Rutger Broekhoff2023-12-291-1/+1
|
* Write basic read-only public Git LFS serverLibravatar Rutger Broekhoff2023-12-293-0/+401
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Initial commitLibravatar Rutger Broekhoff2023-12-294-0/+57