`gopkg.in/yaml.v3` is unmaintained

[mtrmac]

… per https://github.com/go-yaml/yaml?tab=readme-ov-file#this-project-is-unmaintained .

We use it for configuration, not for consuming external data, so this should not cause security risks, but, still…

It’s not very clear what to move to. https://github.com/kubernetes-sigs/yaml == sigs.k8s.io/yaml contains a fork of yaml.v3, and Buildah/Podman already depend on that package, so that seems to be a good candidate. But, also, the last tagged release is from Oct 24, 2023 ; and the way the package is used, they include sigs.k8s.io/yaml/goyaml.v2, not sigs.k8s.io/yaml/goyaml.v3.

Short-term, it’s slightly annoying that there are many users of yaml.v3, some somewhat slow-moving, so if we moved, we would probably end up carrying two copies of the code for some time.

I think that for now, waiting a bit and seeing whether a consensus emerges doesn’t hurt.

[mtrmac]

FYI @Luap99

[Luap99]

podman already directly uses sigs.k8s.io/yaml in some parts and in other parts gopkg.in/yaml.v3, so I think migrating everything sigs.k8s.io/yaml should be the goal. Given it is part of k8s I think we can assume it stays maintained (well at least for k8s uses cases).

And because we already carry both copies binary size wise it should not matter.

[mtrmac]

Podman currently includes the sigs.k8s.io/yaml/goyaml.v2 subpackage (a copy of gopkg.in/yaml.v2), not sigs.k8s.io/yaml/goyaml.v3 (a copy of gopkg.in/yaml.v3).

It might be an option to move back to v2, I didn’t now check what the differences are.

[Luap99]

Well sigs.k8s.io/yaml points to the v2 version. So I would suggest we use that at least for the podman callers, I know we switch from v2 to v3 a while back without any concerns so going back to v2 should likely not cause issues either.

[Luap99]

k8s seems to have switched to go.yaml.in/yaml in kubernetes-sigs/yaml#133 (and as proper module not a hard copy anymore)
Starting with sigs.k8s.io/yaml v1.5.0, i.e. see containers/common#2458, we get that new dep.

So the logical conclusion is use go.yaml.in/yaml/v3 and then hope that k8s will update to v3 eventually so we only have one yaml version in our project.

[mtrmac]

I agree, a package “maintained by the official YAML organization” is a great path forward.

[mtrmac]

containers/image#2923 proposes moving to a future go.yaml.in/yaml/v4, and lists the migration plans for indirect dependencies on gopkg.in/yaml.