Skip to content
Snippets Groups Projects
  • Simon McVittie's avatar
    451b114f
    capture-libs: Don't treat libcrypt.so.1 as part of glibc · 451b114f
    Simon McVittie authored
    
    libcrypt.so.1 is build-time optional since glibc 2.28, and is not built
    by default since 2.38. In newer distributions like Debian >= 11 and
    Ubuntu >= 20.04, it's usually replaced by libxcrypt, either compiled
    to be a drop-in replacement for glibc's libcrypt.so.1 (as in Debian,
    and therefore the Steam Runtime), or with its own SONAME libcrypt.so.2
    and optionally a secondary build as libcrypt.so.1 (as in Arch).
    
    Because libxcrypt implements a superset of the glibc libcrypt.so.1 ABI,
    adding some functions and symvers of its own, it is backward- but not
    forward-compatible: it's OK to use libxcrypt libcrypt.so.1 as a
    replacement for glibc libcrypt.so.1, but it is not OK to do the opposite.
    This means it would be incorrect for us to use a system copy of glibc
    libcrypt.so.1 (perhaps from glibc 2.32 or newer) as a replacement for a
    container's libxcrypt libcrypt.so.1, even if the system copy of glibc
    is strictly newer than the container's glibc (for example,
    Steam Runtime 3 'sniper' is based on Debian 11, so it comes with
    glibc 2.31 and libxcrypt).
    
    Unlike libpthread, libdl and librt, symbols from `libcrypt.so.1` were
    never absorbed into `libc.so.6`, so we don't have to apply the reasoning
    seen in 4c2e3e3b "capture-libs: Add a special case to support glibc 2.34+".
    
    In practice we've always got away with it in the past, but it's something
    that could cause a crash or incompatibility. I'm now looking into the
    possibility of backporting libxcrypt into Steam Runtime 1 and 2
    (steamrt/tasks#332), which makes it more important to get this right.
    
    Accordingly, exclude libcrypt.so.1 from that special treatment, and
    instead set it up to be compared separately using the same comparators
    we use for glibc: by public symvers, then by public symbols, and as a
    last resort by name.
    
    Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
    451b114f
    History
    capture-libs: Don't treat libcrypt.so.1 as part of glibc
    Simon McVittie authored
    
    libcrypt.so.1 is build-time optional since glibc 2.28, and is not built
    by default since 2.38. In newer distributions like Debian >= 11 and
    Ubuntu >= 20.04, it's usually replaced by libxcrypt, either compiled
    to be a drop-in replacement for glibc's libcrypt.so.1 (as in Debian,
    and therefore the Steam Runtime), or with its own SONAME libcrypt.so.2
    and optionally a secondary build as libcrypt.so.1 (as in Arch).
    
    Because libxcrypt implements a superset of the glibc libcrypt.so.1 ABI,
    adding some functions and symvers of its own, it is backward- but not
    forward-compatible: it's OK to use libxcrypt libcrypt.so.1 as a
    replacement for glibc libcrypt.so.1, but it is not OK to do the opposite.
    This means it would be incorrect for us to use a system copy of glibc
    libcrypt.so.1 (perhaps from glibc 2.32 or newer) as a replacement for a
    container's libxcrypt libcrypt.so.1, even if the system copy of glibc
    is strictly newer than the container's glibc (for example,
    Steam Runtime 3 'sniper' is based on Debian 11, so it comes with
    glibc 2.31 and libxcrypt).
    
    Unlike libpthread, libdl and librt, symbols from `libcrypt.so.1` were
    never absorbed into `libc.so.6`, so we don't have to apply the reasoning
    seen in 4c2e3e3b "capture-libs: Add a special case to support glibc 2.34+".
    
    In practice we've always got away with it in the past, but it's something
    that could cause a crash or incompatibility. I'm now looking into the
    possibility of backporting libxcrypt into Steam Runtime 1 and 2
    (steamrt/tasks#332), which makes it more important to get this right.
    
    Accordingly, exclude libcrypt.so.1 from that special treatment, and
    instead set it up to be compared separately using the same comparators
    we use for glibc: by public symvers, then by public symbols, and as a
    last resort by name.
    
    Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>