Skip to content

Investigate changing from alpine in analyzers

Problem to solve

Original bug report: This has caused some issues with python users. The issue is found in dependency scanning for GitLab-provided dependency scanning containers for Python. When using alpine in your base image, manylinux1 wheels will not work there. (possibly due to alpine wheels put in Pypi.)

User builds one without alpine using jessie (i.e. FROM python:3.6-jessie) works with every package in Pypi.

Outcome: We are using alpine due to its small size.

It's recommended to build from source, and then the distro doesn't really matter: if the install requires system libraries we don't provide by default, then there will be custom setup, and the exact setup instructions will defer depending on the distro.

Further details

Currently the Docker images of these analyzers are based on Debian:

The Docker images of these are based on Linux Alpine:

Currently debian:stable-slim is about 30 MB, whereas alpine:latest is about 3 MB. This 27 MB difference doesn't seem significant compared to the size of the images of the analyzers.

Proposal

We should investigate

Conclusion

In the case of gemnasium-python, it's worth switching to Debian Buster slim (about 80 MB bigger) because it makes the environment manylinux2010 compatible, making possible to install many Python packages out of the box. See gitlab-org/security-products/analyzers/gemnasium-python!37 (comment 263938092)

There would be no benefit from switching to Debian in the case of gemnasium because this analyzer directly scans lock files, and does not install dependencies. This may change in the future, when supporting Gemfile, package.json, and composer.json without lock files. There seems to be no benefit either in the case of retire.js. That said, switching to Debian would eliminate discrepancies, and possibly simplify the documentation when covering the customization of the analyzers.

Edited by Fabien Catteau