Overrides tough-cookie library

[surajprsd]

Describe the bug
Using version 0.19.0 and its has issues with request and tough-cookie library vulnerability.

This I have resolved with the overrides option in package.json in my node app as shown below to resolve the tough cookie issue.Please note that we cannot use the new rc4 version as our kubernetes api version is 1.26

"overrides": {
"tough-cookie": "4.1.3"
},

Want to understand if overriding tough-cookie to 4.1.3 in kubernetes/client v 0.19.0 has any known issue or possible issues with the same. Thanks

[mstruebing]

As tough-cookie is a request dependency and not a direct dependency of kubernetes-client/javascript we have no real control over it.

We can not say for sure, 0.19.0 requires [email protected] which is two major versions difference.
At a first look it doesn't seem like the 4.0.0 breaking changes have any affect on the request library, but I did not had a very deep look at the code. https://github.com/salesforce/tough-cookie/releases/tag/v4.0.0

I couldn't find the changelog for version 3.0.0 quickly.

You should try if it works and let us know.

[surajprsd]

oh ok, will test and confirm here. Thanks.
@mstruebing Would there be a future version upgrade for kubernetes/client-node replacing request that supports the same Kubernetes API version (which is currently supported by 0.19.0 ) or Is there an alternative for Kubernetes/client-node?
Assuming kubernetes/client-node and kubernetes-client are the same

[brendandburns]

kubernetes/client-node is different than kubernetes-client, kubernetes/client-node is the official one, kubernetes-client was developed independently by Godaddy and others.

The request version of this client is basically deprecated, we're keeping it around until we're certain that we won't break people.

In the meantime, if you want a non-request based client, you can use this pre-release:
https://www.npmjs.com/package/@kubernetes/client-node/v/1.0.0-rc4

[surajprsd]

@brendandburns Thanks, the latest RC4 doesn't support Kubernetes API v1.26 (using open shift) , hence stuck at this point.
Tough-cookie is the main concern here as it's a critical vulnerability. Hence was trying to understand if overriding tough-cookie is the only option for now

[mstruebing]

With a bit of work involved you could regenerate the API specific code. That means you would be able to use older versions of this client with a newer kubernetes version or newer versions of the client with an older kubernetes version.
There might be issues with our code which we do not generate but I personally never experienced this.
We generate the client ourselves in our company as well.

A downside though is that you need to version/build the code yourself all the time.

I can try to get some steps outlined for how to do this maybe tomorrow.

[brendandburns]

RC4 should support 1.26, it was generated from 1.28 afaik and there's 2 version backward compatability.

Have you tested RC4 against 1.26?

[brendandburns]

Also, I believe you can override the dependency yourself in your own project by editing the package-lock.json file:

https://stackoverflow.com/questions/59096862/how-do-you-bump-a-transitive-dependency-in-package-lock-json

[surajprsd]

@brendandburns done, testing it for issues with override. Tried with RC4 for 1.26 and the library had issues with existing code.

@mstruebing Would be great if you can share the steps to refractor the code. Thanks

[brendandburns]

@surajprsd the easiest thing to do is to override the dependency in your package-lock.json as described above.

I could be wrong, but I don't think we have easy to use docs to regenerate, and I'm not sure it's worth the effort to create them for this niche use-case.

[mstruebing]

Overriding this dependency is definitely the better way here.

If you really want to generate your own client I outline the steps here:

1. Clone the repository
2. Fetch the open api specification from your kubernetes cluster: curl -k $APISERVER/openapi/v2 > "$KUBERNETES_CLIENT_JAVASCRIPT_ROOT/src/gen/swagger.json.unprocessed"
3. Skip fetching the spec from upstream echo "export OPENAPI_SKIP_FETCH_SPEC=1" >> "${KUBERNETES_CLIENT_JAVASCRIPT_ROOT}/settings"
4. npm run generate

That generates you a client you can use with every CRD you have available in your cluster.
You are responsible for generating/versioning it yourself and can not have it as an node dependency which gets fetched from npm. But you are able to modify it the way you like and use all your CRDs with this client.

[jimjaeger]

Are there any update to fix the dependency chain to address CVE-2023-26136? The used request library is not maintained anymore.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[jimjaeger]

/remove-lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[jimjaeger]

/remove-lifecycle stale