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:
-
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 becausesvg
files don't need to be resized. - Enforce strict limits on inputs:
- file size
- picture size
- crosscheck extension matches signature
- [
⚠ 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
- PoC draft: gitlab-workhorse!531 (closed) and !37342 (merged)
- Still need to pick a library that would do the job. https://github.com/h2non/bimg is an option, uses
libvps
which is mentioned to be fast (https://github.com/libvips/libvips)
Edited by Aleksei Lipniagov