- 19 Dec, 2019 4 commits
-
-
Nick Thomas authored
Release v8.18.0 See merge request gitlab-org/gitlab-workhorse!450
-
Nick Thomas authored
-
Nick Thomas authored
Update environment websocket route See merge request gitlab-org/gitlab-workhorse!449
-
Dmitriy Zaporozhets authored
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
- 10 Dec, 2019 2 commits
-
-
Nick Thomas authored
Allow inline PDF files See merge request gitlab-org/gitlab-workhorse!446
-
Felipe Artur authored
Allow inline content disposition for PDF files
-
- 09 Dec, 2019 5 commits
-
-
Nick Thomas authored
Fix typo in Gitaly RPC in CHANGELOG See merge request gitlab-org/gitlab-workhorse!448
-
Stan Hu authored
Renames CompleteMultiparytUpload -> CompleteMultipartUpload
-
Nick Thomas authored
Release v8.17.0 See merge request gitlab-org/gitlab-workhorse!447
-
Stan Hu authored
-
Jacob Vosmaer authored
Log duration_ms when Workhorse hits a bad gateway See merge request gitlab-org/gitlab-workhorse!445
-
- 06 Dec, 2019 1 commit
-
-
Stan Hu authored
Previously when the upstream application (e.g. Unicorn) timed out, Workhorse would report an error message of the form: ```json { "correlation_id": "k4mKg0snXG3", "error": "badgateway: failed after 61s: EOF", "level": "error", "method": "GET", "msg": "error", "time": "2019-12-02T22:05:09-08:00", "uri": "/admin" } ``` Since Sentry attempts to group similar events by some fingerprint that includes the message, the changes in timings would trick Sentry into creating a new event. To avoid that, the new log message now looks like: ```json { "correlation_id": "k4mKg0snXG3", "duration_ms": 60599, "error": "badgateway: failed to receive response: EOF", "level": "error", "method": "GET", "msg": "error", "time": "2019-12-02T22:05:09-08:00", "uri": "/admin" } ``` The inclusion of `duration_ms` and the standardized `error` message makes it easier for users to filter and parse this error.
-
- 03 Dec, 2019 1 commit
-
-
Jacob Vosmaer authored
Add labkit monitoring for build metrics See merge request gitlab-org/gitlab-workhorse!440
-
- 27 Nov, 2019 6 commits
-
-
Zeger-Jan van de Weg authored
Labkit monitoring exposes a metric I wanted to add, gitlab_build_info. This will set a gauge to the current version and build time, and as such we can measure how fast deploys are and when the last deploy happened. Metric exposed looks like: `gitlab_build_info{built="20191121.084148",version="v8.15.0-5-gde6eb66"} 1`
-
Nick Thomas authored
Release v8.16.0 See merge request gitlab-org/gitlab-workhorse!444
-
Nick Thomas authored
-
Nick Thomas authored
Set a time limit on git upload-pack requests See merge request gitlab/gitlab-workhorse!24
-
Jacob Vosmaer authored
Upgrade Gitaly client to v1.74.0 Closes #231 See merge request gitlab-org/gitlab-workhorse!443
-
Paul Okstad authored
-
- 21 Nov, 2019 1 commit
-
-
Nick Thomas authored
Add maven route test See merge request gitlab-org/gitlab-workhorse!442
-
- 20 Nov, 2019 2 commits
-
-
Nick Thomas authored
Add NuGet route for package uploads See merge request gitlab-org/gitlab-workhorse!441
-
Nick Thomas authored
When a client does a git fetch over HTTP, workhorse performs an access check based on the HTTP request header, then reads the entire request body into a temporary file before handing off to Gitaly to service it. However, the client has control over how long it takes to read the request body. Since the Gitaly RPC only happens once the request body is read, people can set up a connection before their access is revoked and use it to gain access to code committed days or weeks later. To resolve this, we place an overall limit of 10 minutes on receiving the `upload-pack` request body. Since this is over HTTP, the client is using the `--stateless-rpc` mode, and there is no negotiation between client and server. The time limit is chosen fairly arbitrarily, but it fits well with the existing 10MiB limit on request body size, implying a transfer speed of just 17KiB/sec to be able to fill that buffer and get a "request too large" error instead of "request too slow". Workhorse does not expose the `upload-archive` endpoint directly to the user; the client in that case is always gitlab-rails, so there is no vulnerability there. The `receive-pack` endpoint is theoretically vulnerable, but Gitaly performs a second access check in the pre-receive hook which defeats the attack, so no changes are needed. The SSH endpoints are similarly vulnerable, but since those RPCs are bidirectional, a different approach is needed.
-
- 19 Nov, 2019 2 commits
-
-
Hayley Swimelar authored
-
Hayley Swimelar authored
-
- 11 Nov, 2019 2 commits
-
-
Jacob Vosmaer authored
Upgrade Gitaly client to v1.71.0 Closes #231 See merge request gitlab-org/gitlab-workhorse!439
-
Paul Okstad authored
-
- 05 Nov, 2019 2 commits
-
-
Jacob Vosmaer authored
Ignore CompleteMultipartUpload ETag See merge request gitlab-org/gitlab-workhorse!438
-
Alessio Caiazza authored
Our ETag comparison on CompleteMultipartUpload was based on a reverse engineered protocol. It is not part of the S3 API specification and not every providers compute it in the same way.
-
- 25 Oct, 2019 2 commits
-
-
Jacob Vosmaer authored
Release v8.15.0 See merge request gitlab-org/gitlab-workhorse!437
-
Alessio Caiazza authored
-
- 15 Oct, 2019 3 commits
-
-
Nick Thomas authored
Case insensitive ETag comparison See merge request gitlab-org/gitlab-workhorse!434
-
Alessio Caiazza authored
Some object storage providers returns upcase ETag headers. This commit will perform the check in case insensitive mode
-
Nick Thomas authored
Upgrade gitaly to 1.68.0 See merge request gitlab-org/gitlab-workhorse!435
-
- 14 Oct, 2019 1 commit
-
-
John Cai authored
Gitaly 1.68.0 upgrades GRPC to 1.24.0
-
- 11 Oct, 2019 4 commits
-
-
Jacob Vosmaer authored
Test against go1.13 See merge request gitlab-org/gitlab-workhorse!433
-
Nick Thomas authored
Release v8.14.0 See merge request gitlab-org/gitlab-workhorse!432
-
Nick Thomas authored
-
Nick Thomas authored
-
- 10 Oct, 2019 2 commits
-
-
Nick Thomas authored
Keep HTTP 1.0 cache headers from sendurl proxies See merge request gitlab-org/gitlab-workhorse!431
-
Sean McGivern authored
For maximum compatiblity, the Rails application should also set Date and Pragma, and so we should ensure that these are not overwritten by the object storage provider.
-