Description of problem (please be detailed as possible and provide log snippests): We currently have a redundant dependency on Vault SDKs that we don't use. Due to a change in Vault licensing, we need to replace the BSL libraries using BSL license. We have the BSL license in use in the following containers: mcg-operator-container odf-multicluster-operator-container odf-operator-container rook-ceph-operator-container odr-operator-container Libraries: https://github.com/hashicorp/consul - BSL https://github.com/hashicorp/terraform - BSL https://github.com/hashicorp/vault - BSL https://github.com/hashicorp/go-uuid - MPL. https://github.com/hashicorp/errwrap - MPL https://github.com/hashicorp/go-cleanhttp - MPL https://github.com/hashicorp/go-hclog - MIT https://github.com/hashicorp/go-immutable-radix - MPL https://github.com/hashicorp/go-multierror - MPL https://github.com/hashicorp/go-retryablehttp - MPL https://github.com/hashicorp/go-rootcerts - MPL https://github.com/hashicorp/go-secure-stdlib -MPL https://github.com/hashicorp/go-sockaddr - MPL https://github.com/hashicorp/go-plugin - MPL https://github.com/hashicorp/eventlogger - MPL https://github.com/hashicorp/go-discover - MPL https://github.com/hashicorp/go-kms-wrapping - MPL https://github.com/hashicorp/go-memdb - MPL https://github.com/hashicorp/go-msgpack - MIT https://github.com/hashicorp/go-raftchunking - MPL https://github.com/hashicorp/go-version - MPL
For Rook, I tracked the top-level Vault gomod inclusion (github.com/hashicorp/vault) to github.com/libopenstorage/secrets which imports github.com/hashicorp/vault/command. Because 'command' is part of the Vault product, it is BUSL-1.1 licensed. My quick initial investigation shows that it should be straightforward to change to using github.com/hashicorp/vault/api in libopenstorage/secrets to make use of Vault's MPL-2.0 licensed API code. The risk I identified is that libopenstorage/secrets does not have very regular contributors. I created an issue and tagged 6 recent contributors and reviewers to the project to try to get a commitment to merging the code within 2 weeks: https://github.com/libopenstorage/secrets/issues/79 If I don't get a positive response, then Rook will have to resort to using Vaul's API directly rather than using the libopenstorage/secrets library, which is not preferred. In the meantime, I'll begin making changes to a personal fork of libopenstorage/secrets to verfiy that the changes I'm proposing will fix the licensing issue. --- I cannot speak to whether other ODF components will need to make different changes. I was able to find the source of the inclusion by deleting the line `github.com/hashicorp/vault v1.13.7 // indirect` in Rook's `go.mod` file and running `go mod tidy` to find output like below, and then investigating each import manually: go: finding module for package github.com/hashicorp/vault/sdk/version go: downloading github.com/hashicorp/vault/sdk v0.10.2 go: downloading github.com/hashicorp/vault v1.15.0 go: github.com/rook/rook/pkg/daemon/ceph/osd/kms imports github.com/libopenstorage/secrets/vault/utils imports github.com/hashicorp/vault/command/agent/auth tested by github.com/hashicorp/vault/command/agent/auth.test imports github.com/hashicorp/vault/http imports github.com/hashicorp/vault/sdk/version
I have a draft PR already up and one interested developer willing to take a look already. Library PR: https://github.com/libopenstorage/secrets/pull/80 I'm waiting to make sure that Rook's CI passes with the changes proposed before moving from "draft" PR to "ready" state. Rook CI: https://github.com/rook/rook/pull/13032
I don't see any links to other BZs where ODF components need updating. Any component that uses Rook's API will need updated. Also, any component that uses libstorage/secrets directly will need updated. Those would be noobaa, ocs-operator, and odf-operator to my knowledge. There could be other components as well that I'm unaware of. Do those BZs exist already, but aren't linked here? Or do those need created?
The easiest way that I know to verify dependencies for Golang apps is to check out the code repo associated with any given container, and `checkout` the git hash noted in the pod labels/vars, then look at the `go.mod` file.
I've checked the go.mod file of the rook commit 103536c37b9f9063f4abe9db7c59150125b75908 I got from inspecting the rook operator image. The list of vault libraries listed there is github.com/hashicorp/vault/api v1.10.0 github.com/hashicorp/errwrap v1.1.0 // indirect github.com/hashicorp/go-cleanhttp v0.5.2 // indirect github.com/hashicorp/go-hclog v1.5.0 // indirect github.com/hashicorp/go-multierror v1.1.1 // indirect github.com/hashicorp/go-retryablehttp v0.7.4 // indirect github.com/hashicorp/go-rootcerts v1.0.2 // indirect github.com/hashicorp/go-secure-stdlib/parseutil v0.1.7 // indirect github.com/hashicorp/go-secure-stdlib/strutil v0.1.2 // indirect github.com/hashicorp/go-sockaddr v1.0.5 // indirect github.com/hashicorp/hcl v1.0.1-vault-5 // indirect github.com/hashicorp/vault/api/auth/approle v0.5.0 // indirect github.com/hashicorp/vault/api/auth/kubernetes v0.5.0 // indirect I checked the licenses in each of them. They are either MPL or MIT, which is OK.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Important: Red Hat OpenShift Data Foundation 4.14.0 security, enhancement & bug fix update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2023:6832