Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
LFS uploads are handled in concert by workhorse and rails. In normal
use, workhorse:
* Authorizes the request with rails (upload_authorize)
* Handles the upload of the file to a tempfile - disk or object storage
* Validates the file size and contents
* Hands off to rails to complete the upload (upload_finalize)
In `upload_finalize`, the LFS object is linked to the project. As LFS
objects are deduplicated across all projects, it may already exist. If
not, the temporary file is copied to the correct place, and will be
used by all future LFS objects with the same OID.
Workhorse uses the Content-Type of the request to decide to follow this
routine, as the URLs are ambiguous. If the Content-Type is anything but
"application/octet-stream", the request is proxied directly to rails,
on the assumption that this is a normal file edit request. If it's an
actual LFS request with a different content-type, however, it is routed
to the Rails `upload_finalize` action, which treats it as an LFS upload
just as it would a workhorse-modified request.
The outcome is that users can upload LFS objects that don't match the
declared size or OID. They can also create links to LFS objects they
don't really own, allowing them to read the contents of files if they
know just the size or OID.
We can close this hole by requiring requests to `upload_finalize` to be
sourced from Workhorse. The mechanism to do this already exists.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
https://gitlab.com/gitlab-org/gitlab-workhorse/blob/master/CHANGELOG
|
|
This version now supports redis[s]:// URL schemes.
|
|
|
|
|
|
|
|
There were several issues:
1. With Google Cloud Storage, we can't override the Content-Type with
Response-Content-Type once it is set. Setting the value to
`application/octet-stream` doesn't buy us anything. GCS defaults to
`application/octet-stream`, and AWS uses `binary/octet-stream`. Just remove
this `Content-Type` when we upload new files.
2. CarrierWave and fog-google need to support query parameters:
https://github.com/fog/fog-google/pull/409/files, https://github.com/carrierwaveuploader/carrierwave/pull/2332/files.
CarrierWave has been monkey-patched until an official release.
3. Workhorse also needs to remove the Content-Type header in the request
(https://gitlab.com/gitlab-org/gitlab-workhorse/blob/ef80978ff89e628c8eeb66556720e30587d3deb6/internal/objectstore/object.go#L66),
or we'll get a 403 error when uploading due to signed URLs not matching the headers.
Upgrading to Workhorse 6.1.0 for https://gitlab.com/gitlab-org/gitlab-workhorse/merge_requests/297
will make Workhorse use the headers that are used by Rails.
Closes #49957
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fixes silent failure of `git clone` when Gitaly is not running.
|
|
|
|
Bug fixes, Gitaly gRPC support, experimental Redis integration.
|
|
|
|
|
|
|
|
Confines API rate limiting feature to builds/register.json CI requests
only.
|
|
|
|
v1.0.0 was mistakenly tagged with a lightweight, rather than annotated, tag,
which caused compiled versions of workhorse to wrongly report their version.
|
|
|