Image Resizing: [1] Embedded approach

Idea

We do the resizing in the same Workhorse process which handles the image web request.
Rails adds the specific handler in UploadsController, Workhorse handles it and calls a Go lib for the resizing.

Pros

  • Probably, the most simple and straightforward approach
  • Already have a PoC draft (see the notes)
  • Could be a good start, to iterate
  • No new service definition required in Omnibus; it remains an implementation detail of workhorse

Cons

  • Can't control Mem/CPU usage in a flexible way (but maybe it is not such issue for avatars which have a fixed upper dimension bound)
  • Knock-on effects on server process that fronts every single GitLab request -> risky, since no failure isolation

Concerns

For each concern, it is good to have a strategy on how to evolve the solution to solve it and the estimation of doing so.

Concern: Do we have a risk of Mem/CPU going overboard? Is it relevant for avatars? How do we handle this?
Solution: TBD

Security prerequisites

As stated by Jeremy in https://gitlab.com/gitlab-com/gl-security/engineering/-/issues/1043#note_388815325:

  1. Absolutely avoid processing svg files: here is a post mortem of the 3rd party service we are currently using to resize Gitter images. Anyhow it should not be an issue because svg files don't need to be resized.
  2. Enforce strict limits on inputs:
  • file size
  • picture size
  • crosscheck extension matches signature
  1. [ Not Achievable in this implementation] Sandbox the library that will do the image processing, i.e. don't run it as the same linux account than Rails/Workhorse/Gitaly.

Notes

Edited by Aleksei Lipniagov