1. 10 Feb, 2020 3 commits
  2. 06 Feb, 2020 2 commits
  3. 05 Feb, 2020 1 commit
  4. 29 Jan, 2020 2 commits
  5. 09 Jan, 2020 2 commits
  6. 08 Jan, 2020 1 commit
  7. 24 Dec, 2019 1 commit
  8. 19 Dec, 2019 4 commits
  9. 10 Dec, 2019 2 commits
  10. 09 Dec, 2019 5 commits
  11. 06 Dec, 2019 1 commit
    • Stan Hu's avatar
      Log duration_ms when Workhorse hits a bad gateway · 43ce41ec
      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.
      43ce41ec
  12. 03 Dec, 2019 1 commit
  13. 27 Nov, 2019 6 commits
  14. 21 Nov, 2019 1 commit
  15. 20 Nov, 2019 2 commits
    • Nick Thomas's avatar
      Merge branch 'nuget-object-storage-upload-route' into 'master' · f407257d
      Nick Thomas authored
      Add NuGet route for package uploads
      
      See merge request gitlab-org/gitlab-workhorse!441
      f407257d
    • Nick Thomas's avatar
      Set a time limit on git upload-pack requests · f2ad577a
      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.
      f2ad577a
  16. 19 Nov, 2019 2 commits
  17. 11 Nov, 2019 2 commits
  18. 05 Nov, 2019 2 commits