1. 13 Feb, 2019 1 commit
  2. 06 Feb, 2019 1 commit
  3. 04 Feb, 2019 1 commit
  4. 31 Jan, 2019 1 commit
    • Nick Thomas's avatar
      Verify that LFS upload requests are genuine · 5b075413
      Nick Thomas authored
      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.
      5b075413
  5. 22 Jan, 2019 2 commits
    • Nick Thomas's avatar
      Verify that LFS upload requests are genuine · 87c5abfc
      Nick Thomas authored
      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.
      87c5abfc
    • Andrew Newdigate's avatar
      Upgrade gitlab-workhorse to 8.1.0 · 51322670
      Andrew Newdigate authored
      51322670
  6. 11 Dec, 2018 1 commit
  7. 10 Dec, 2018 1 commit
  8. 06 Dec, 2018 1 commit
  9. 04 Dec, 2018 1 commit
  10. 30 Nov, 2018 1 commit
  11. 28 Nov, 2018 1 commit
  12. 23 Nov, 2018 1 commit
  13. 14 Nov, 2018 1 commit
  14. 07 Nov, 2018 1 commit
  15. 02 Oct, 2018 1 commit
  16. 27 Sep, 2018 1 commit
  17. 06 Sep, 2018 1 commit
  18. 16 Aug, 2018 1 commit
  19. 30 Jul, 2018 1 commit
  20. 04 Jul, 2018 1 commit
  21. 07 Jun, 2018 1 commit
  22. 01 Jun, 2018 1 commit
  23. 22 May, 2018 1 commit
  24. 01 May, 2018 1 commit
  25. 12 Apr, 2018 1 commit
  26. 07 Mar, 2018 1 commit
  27. 02 Mar, 2018 1 commit
  28. 28 Feb, 2018 1 commit
  29. 06 Feb, 2018 1 commit
  30. 22 Jan, 2018 1 commit
  31. 09 Jan, 2018 1 commit
  32. 08 Jan, 2018 1 commit
  33. 14 Nov, 2017 1 commit
  34. 30 Oct, 2017 1 commit
  35. 05 Oct, 2017 1 commit
  36. 20 Sep, 2017 1 commit
  37. 11 Jul, 2017 1 commit
  38. 06 Jul, 2017 1 commit
  39. 22 Jun, 2017 1 commit