I am fine with there being a specific base image but I think that it should be pullable.

On Wed, Feb 26, 2020, 04:06 Wes Turner <wes.turner@gmail.com> wrote:

On Tue, Feb 25, 2020, 10:03 PM Wes Turner <wes.turner@gmail.com> wrote:

Is there a reason the new manylinux does not just extend centos:6?

https://github.com/pypa/manylinux/blob/master/docker/glibc/README.rst :

> Summary: Because of https://mail.python.org/pipermail/wheel-builders/2016-December/000239.html, this a CentOS 6.10 Docker image that rebuilds glibc without vsyscall is necessary to reliably run manylinux2010 on 64-bit hosts. This requires building the image on a system with vsyscall=emulate but allows the resulting container to run on systems with vsyscall=none or vsyscall=emulate.
>
> vsyscall is an antiquated optimization for a small number of frequently-used system calls. A vsyscall-enabled Linux kernel maps a read-only page of data and system calls into a process' memory at a fixed address. These system calls can then be invoked by dereferencing a function pointers to fixed offsets in that page, saving a relatively expensive context switch. [1]
>
> Unfortunately, because the code and its location in memory are fixed and well-known, the vsyscall mechanism has become a source of gadgets for ROP attacks (specifically, Sigreturn-Oriented Programs). [2] Linux 3.1 introduced vsyscall emulation that prevents attackers from jumping into the middle of the system calls' code at the expense of speed, as well as the ability to disable it entirely. [3] [4] The vsyscall mechanism could not be eliminated at the time because glibc versions earlier than 2.14 contained hard-coded references to the fixed memory address, specifically in time(2). [5] These segfault when attempting to issue a vsyscall-optimized system call against a kernel that has disabled it.