Use of a third party library maintained by a Sanctioned Entity

[RichardoC]

What happened?

The easyjson library is maintained by Mail.ru. This is owned by VK, which is owned by Gazprom Media, and thus is subject to EU and USA Sanctions

This is a dependancy via https://github.com/go-openapi/swag which is used by the client-go library.

I suspect Kubernetes want to either fork easyjson, or migrate to a library that isn't maintained by a sanctioned entity.

I did attempt to report this via the process documented at https://kubernetes.io/security but didn't get a response for weeks.

What did you expect to happen?

Kubernetes to rely on libraries that aren't maintained by entities subject to U.S.A. and E.U. sanctions

How can we reproduce it (as minimally and precisely as possible)?

N/A

Anything else we need to know?

N/A

Kubernetes version

All modern versions, this appears in the go.mod of Kubernetes 1.15+

Cloud provider

N/A

OS version

# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here

Install tools

Container runtime (CRI) and version (if applicable)

Related plugins (CNI, CSI, ...) and versions (if applicable)

[k8s-ci-robot]

This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[k8s-ci-robot]

@RichardoC: The label(s) sig/given, sig/client-go, sig/relies, sig/on, sig/this. cannot be applied, because the repository doesn't have them.

In response to this:

/sig api-machinery given client-go relies on this.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[RichardoC]

/sig api-machinery

Since client-go relies on this.

[dims]

What a tangled web we weave

[dims]

Also, @RichardoC please open an issue in https://github.com/cncf/foundation asking CNCF to put together a guidance for $TITLE and then we can follow that guidance in all projects. We should not be doing a one of thing just for k8s.

For example, i have one there cncf/foundation#290

[cici37]

/sig architecture
/remove-sig api-machinery

[BenTheElder]

x-ref: mailru/easyjson#385

[BenTheElder]

cncf/foundation#550 (comment)

Given CNCF guidance that this is not a problem, I don't think we'll be trying to remove this dependency, we'd have to convince all of the projects through which we transitively depend on this to also switch, which looks non-trivial in this case #117553 (comment)

We pin all dependencies and check the sources into vendor and build from those, reviewing the source code changes on dependency update PRs (more on that in the linked comment above).

If a package is unmaintained and lacking fixes, then we may attempt to remove it for that reason, but we don't appear to have any other known-issues here.

[dims]

https://github.com/mailru/easyjson seems to be unmaintained as well ... so more reason to at least track it

[dims]

/close

[k8s-ci-robot]

@dims: Closing this issue.

In response to this:

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.