cni-plugins binaries does not correctly report versions and other differences from upstream release and other distros

[invidian]

It seems installed binaries from cni-plugins binary does not correctly print version

# dnf list --installed | grep cni-plugins
cni-plugins.x86_64                     0.9.1-14.cm2            @mariner-official-base
# /opt/cni/bin/macvlan -v
CNI macvlan plugin version unknown
# /opt/cni/bin/dhcp -v
CNI dhcp plugin version unknown

Example output of those binaries on Ubuntu 18.04:

# /opt/cni/bin/macvlan -v
CNI macvlan plugin v1.2.0
CNI protocol versions supported: 0.1.0, 0.2.0, 0.3.0, 0.3.1, 0.4.0, 1.0.0
# /opt/cni/bin/dhcp -v
CNI dhcp plugin v1.2.0
CNI protocol versions supported: 0.1.0, 0.2.0, 0.3.0, 0.3.1, 0.4.0, 1.0.0

I saw this issue upstream: containernetworking/plugins#758 and indeed it seems Mariner package is built using build_linux.sh, so it's probably affected.

Looking at https://github.com/containernetworking/plugins/blob/main/scripts/release.sh, I think

./build_linux.sh

can be changed to

./build_linux.sh "-ldflags '-X github.com/containernetworking/plugins/pkg/utils/buildversion.BuildVersion=%{version}'"

To restore printed version.

Other difference I see is, that CNI release binaries are statically complied (with -static flag), while Mariner binaries links to glibc:

# ldd /opt/cni/bin/dhcp
        linux-vdso.so.1 (0x00007ffed5ef7000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x00007824ab7c9000)
        libc.so.6 => /lib/libc.so.6 (0x00007824ab5c7000)
        /lib64/ld-linux-x86-64.so.2 (0x00007824ab7e3000)
# cat /etc/os-release
NAME="Common Base Linux Mariner"
VERSION="2.0.20230924"
ID=mariner
VERSION_ID="2.0"
PRETTY_NAME="CBL-Mariner/Linux"
ANSI_COLOR="1;34"
HOME_URL="https://aka.ms/cbl-mariner"
BUG_REPORT_URL="https://aka.ms/cbl-mariner"
SUPPORT_URL="https://aka.ms/cbl-mariner"

# ldd /opt/cni/bin/dhcp
        not a dynamic executable
# cat /etc/os-release
NAME="Ubuntu"
VERSION="18.04.6 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.6 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic

Perhaps this is also something which could be improved?

Package itself could also be updated, v0.9.1. has been released in Feb 5, 2021, a while ago. Ubuntu at the moment ships v1.2.0.

I'm sorry for bundling few issues into one, I can report it separately if needed.

Let me know what you think and I can address all concerns in a single PR.

[mfrw]

Thank you @invidian for the observation and proposed fix as well.
Please feel free to create a PR to address the version issue:
where: ./build_linux.sh -> ./build_linux.sh "-ldflags '-X github.com/containernetworking/plugins/pkg/utils/buildversion.BuildVersion=%{version}'".

With respect to static vs dynamic linking & version upgrade I believe @jslobodzian / @christopherco / @hbeberman might be the right people.

[christopherco]

With respect to static vs dynamic linking & version upgrade I believe @jslobodzian / @christopherco / @hbeberman might be the right people.

We generally favor dynamic linking so when we publish security updates for a given system library, the application does not need to be rebuilt or published, but the vulnerability is patched. There can be exceptions, but this is our general policy around static vs dynamic linking.

[invidian]

We generally favor dynamic linking so when we publish security updates for a given system library, the application does not need to be rebuilt or published, but the vulnerability is patched. There can be exceptions, but this is our general policy around static vs dynamic linking.

All right, that make sense. Although it looks like upstream disables CGO as part of the release, so the binaries does not use glibc etc, so they would only be affected by Go vulnerabilities. It would seem reasonable for me to follow that. What do you think?

[christopherco]

We generally favor dynamic linking so when we publish security updates for a given system library, the application does not need to be rebuilt or published, but the vulnerability is patched. There can be exceptions, but this is our general policy around static vs dynamic linking.

All right, that make sense. Although it looks like upstream disables CGO as part of the release, so the binaries does not use glibc etc, so they would only be affected by Go vulnerabilities. It would seem reasonable for me to follow that. What do you think?

Some interesting datapoints - on both Fedora and Ubuntu, looks like their official containernetworking-plugins package have these binaries dynamically linking against glibc.

# ldd /usr/libexec/cni/dhcp
        linux-vdso.so.1 (0x00007ffdd49ea000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f746920b000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f746902d000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f7469a4a000)
# cat /etc/os-release
NAME="Fedora Linux"
VERSION="38 (Container Image)"
ID=fedora
VERSION_ID=38
VERSION_CODENAME=""
PLATFORM_ID="platform:f38"
PRETTY_NAME="Fedora Linux 38 (Container Image)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:38"
DEFAULT_HOSTNAME="fedora"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f38/system-administrators-guide/"
SUPPORT_URL="https://ask.fedoraproject.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=38
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=38
SUPPORT_END=2024-05-14
VARIANT="Container Image"
VARIANT_ID=container

# ldd /usr/lib/cni/dhcp
        linux-vdso.so.1 (0x00007fff39ede000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe37627c000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe37608a000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fe3762a3000)
# cat /etc/os-release
NAME="Ubuntu"
VERSION="20.04.4 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.4 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal

I wonder if I'm looking at the wrong set of packages for these distros or just missing something...

That being said, in general it does seem reasonable to align our packaging closer to how upstream expects the binaries to be released. Adding @romoh who has more knowledge of our CNI plugins and may have opinions on this.

[invidian]

Hm, I was looking at kubernetes-cni package from pkgs.k8s.io, as described in https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/.

Thanks for checking on other platforms, I thought it's more unified.

[invidian]

I opened #6396 with version bump and version setting.