security patches & related dependency backports to v3?

[thediveo]

I'm forced to use the podman v3 REST API client because Debian and Ubuntu LTS currently only ship podman v3.4 packages.

Using the v3 client causes a govuln hit, as can be seen here: https://deps.dev/go/github.com%2Fthediveo%2Fsealwatcher/v0.8.0

How to best deal with this? Note that upgrading the client isn't possible because a v4 client gets rejected by a v3 server and my users won't upgrade their LTS distros using debian experimental packages.

1. does podman fixes vuln deps in v3?
2. would pinning a newer buildah version in my go.mod be possible and sensible?

[mheon]

Firstly, I'm amazed that CVE got a medium. We discussed it internally and saw no possible way of exploiting it.

@siretart Has Debian considered backporting the fix for it (or, potentially, already done so)?

[siretart]

I'm happy to consider backporting patches and uploading them to stable if they get nominated / reported as a bug to Debian. I've done so at least a couple of times in the past.

[thediveo]

But where does this leave me as a downstream consumer of the source repository? I cannot use v4 as I need to talk to a fixed or unfixed v3 podman in service deployment and a v4 client cannot connect to a v3 podman service.

[davdr]

@thediveo Have you reported it as a bug to Debian as siretart proposes? Looks like this is the way if you want to get the backport into LTS.

[thediveo]

no. I had several devs now that ditched Debian because it isn't worth the permanent hassle and additional efforts, and the devs need to get their jobs done. Spending lots of time trying to make Debian move isn't on their score cards.

[afbjorklund]

I was considering to use the Docker API instead, since it should be more backwards compatible...?

It would also be the same between the other runtimes supported (for k8s), now that I made some duct-tape middleware to talk to containerd. So then I wouldn't have to maintain a separate "podman-env" but only the "docker" stub (for ssh). Either that, or just give up and use the CLI instead. Especially for legacy clients that only talk tcp, they can use "ssh sudo podman" instead of podman.sock ?

[thediveo]

@afbjorklund true, from my experience the Docker API has been long-term stable so far and the client is easy to work with without a need for system headers and libraries. Podman's unstable situation is amplified by Debian and Ubuntu LTS. The situation would be the same for Docker, weren't Docker very supportive and building for several distro package formats stable packages in order to remedy the stubborn packagers' lack of understanding. The decision for a container engine isn't usually made due to some few features, but on the overall perspective.

[afbjorklund]

I explicitly meant using docker client with ssh: DOCKER_HOST for podman.sock (with "docker" and "docker.sock" workarounds)
Instead of getting the Error: unable to connect to Podman socket: server API version is too old. Client "4.0.0" server "3.4.2"...

But involves a lot of other hassle, like managing the host key and the ssh key, that was not there with the legacy tcp interface of docker. The usual workaround, e.g. in lima, is setting up a tunneled local unix socket instead of letting the client do it. But that's also a bit too "different"