You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The GGShield RPM is shipping its own versions of libraries that are already available in RHEL9 and EL9 clones:
libbz2.so.1 --> bzip2-libs
libcrypto.so.1 --> libxcrypt-compat
libexpat.so.1 --> expat
libgcc_s.so.1 --> libgcc
liblzma.so.5 --> xz-libs
libssl.so.1.1 --> compat-openssl11
libtinfo.so.6 --> ncurses-libs
libuuid.so.1 --> libuuid
libz.so.1 --> zlib
(libpython3.9.so.1.0 is also available in EL9)
...and these packages from EPEL provide the other two:
libffi.so.6 --> libffi3.1
libreadline.so.7 --> readline7
EPEL is a commonly trusted 3rd-party package source (perhaps distributing GGShield for RHEL in EPEL would be a good idea).
I'm guessing some sort of cross-distro build system is being utilized to create portable packages which is resulting in bundling of libraries. There are a couple of concerns with that approach:
Operating system patching doesn't patch the bundled libraries
Size (not really an issue on VMs, but contributes to container image bloat)
SSL certificates and crypto policies
Regarding item 3, by shipping your own copy of libssl you are bypassing the operating system trust store and crypto policies. The Python Certifi package waters this argument down a bit since it hard codes its own trust store, but regarding crypto policies, RHEL and clones have global crypto policies that state which ciphers are allowed to be used (and key strengths and other details) that are enforced by the bundled OpenSSL libraries (and others not relevant to GGShield):
Hi Jason. We build ggshield Linux standalone packages (rpm, deb, tarball) using Rocky Linux 8 and bundle the necessary libraries in the generated package.
As you pointed out, this approach has some drawbacks, but it allows us to efficiently reach a maximum number of developers using Linux.
The GGShield RPM is shipping its own versions of libraries that are already available in RHEL9 and EL9 clones:
libbz2.so.1
-->bzip2-libs
libcrypto.so.1
-->libxcrypt-compat
libexpat.so.1
-->expat
libgcc_s.so.1
-->libgcc
liblzma.so.5
-->xz-libs
libssl.so.1.1
-->compat-openssl11
libtinfo.so.6
-->ncurses-libs
libuuid.so.1
-->libuuid
libz.so.1
-->zlib
(
libpython3.9.so.1.0
is also available in EL9)...and these packages from EPEL provide the other two:
libffi.so.6
-->libffi3.1
libreadline.so.7
-->readline7
EPEL is a commonly trusted 3rd-party package source (perhaps distributing GGShield for RHEL in EPEL would be a good idea).
I'm guessing some sort of cross-distro build system is being utilized to create portable packages which is resulting in bundling of libraries. There are a couple of concerns with that approach:
Regarding item 3, by shipping your own copy of
libssl
you are bypassing the operating system trust store and crypto policies. The Python Certifi package waters this argument down a bit since it hard codes its own trust store, but regarding crypto policies, RHEL and clones have global crypto policies that state which ciphers are allowed to be used (and key strengths and other details) that are enforced by the bundled OpenSSL libraries (and others not relevant to GGShield):https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening
The text was updated successfully, but these errors were encountered: