release-sdk
release-sdk copied to clipboard
kubernetes-sigs
Transitive dependencies on github.com/hashicorp/go-retryablehttp required to build
What happened:
Cannot build release-sdk commands without pulling in MPL-licensed projects not in the CNCF allowlist.
go mod why github.com/hashicorp/go-retryablehttp shows this path to github.com/hashicorp/go-retryablehttp which is MPL-licensed and not included in the CNCF allowlist:
# github.com/hashicorp/go-retryablehttp
sigs.k8s.io/release-sdk/sign
github.com/sigstore/cosign/cmd/cosign/cli/rekor
github.com/sigstore/rekor/pkg/client
github.com/hashicorp/go-retryablehttp
https://github.com/cncf/foundation/blob/main/license-exceptions/
https://github.com/cncf/foundation/blob/main/allowed-third-party-license-policy.md#cncf-allowlist-license-policy
https://github.com/cncf/foundation/issues/138
What you expected to happen:
No dependencies on MPL-licensed projects not explicitly allowlisted
How to reproduce it (as minimally and precisely as possible):
run go mod vendor to see code actually used/linked by release-sdk and observe go-retryablehttp code is required to build.
Yeah, this needs to be changed in rekor / cosign. Probably a bump to cosign v2 may already fix that problem.
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/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas 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
Looks like we still have this transitive dependency. /remove-lifecycle stale
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/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas 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
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/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas 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
I still see this dep, which gets pulled transitively into other repos by way of dependency on release-sdk.
We should consider splitting out cosign or something, if we can't resolve this on their end.
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/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas 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
We still use this dependency https://cs.k8s.io/?q=github.com%2Fhashicorp%2Fgo-retryablehttp&i=nope&files=go.mod&excludeFiles=vendor&repos= /remove-lifecycle stale
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/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas 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
Created https://github.com/sigstore/rekor/issues/2342 to discuss that issue on the rekor side.
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/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas 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
/lifecycle frozen There's no indication that this will become OK. We do get an ~annual audit from the CNCF about inappropriate licensing. If we can't get sigstore fixed we should consider how to decouple.