You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Dependency on go-cose version that does not exist. #2162
The indirect dependency on "github.com/veraison/go-cose@v1.2.0" [https://github.com/microsoft/hcsshim/blob/8beabacfc2d21767a07c20f8dd5f9f3932dbf305/go.mod#L99] cannot be resolved.
This is due to v1.2.0 being retracted by the developer:
[https://github.com/veraison/go-cose/pull/153]
This dependency should be updated to reference the current release "github.com/veraison/go-cose@v1.1.0"
To explain;
I think go-cose retracted a published version since the last version of hcsshim was published.
It plays havoc with our internal build process, in that we are unable to allow "go mod" and "tidy" to run without explicitly pinning specific dependencies, which is never best practice, especially if there are other third-party libraries in the mix.
When building and fetching dependencies everything blows up with an unresolved dependency on go-cose v1.2.0 because the go.mod for hcsshim specifies go-cose v1.2.0 as a dependency. The dependency resolution step of the go build process attempts to go and download this specific go-cose version and fails because it doesn't exist.
Ideally, the fix here would be for the maintainers of hcsshim to update the go.mod to reference an active "published" version of go-cose (followed by a run of "go mod tidy" to ensure that the go.sum file is present and correct).
Hopefully, that makes a bit more sense. Sorry for my original cryptic message.
The issue reported that the indirect dependency github.com/veraison/go-cose@v1.2.0 (at commit 8beabac) was unresolvable because the upstream maintainers retracted it (veraison/go-cose#153), and suggested downgrading to v1.1.0.
Findings
No code changes required — the dependency has already been moved past the retracted version on main:
go.mod, test/go.mod, and vendor/modules.txt all pin github.com/veraison/go-cose v1.3.0.
v1.3.0 exists on the module proxy and its own go.mod carries retract directives for v1.2.0 ("published in error") and v1.2.1, so Go tooling will never re-select the broken versions transitively.
Upgrading to v1.3.0 is preferable to the v1.1.0 downgrade suggested in the issue.
Activity
lktoken commentedon Jul 17, 2024
Can someone explain this?
lingdie commentedon Jul 31, 2024
Can someone explain this?
andrew-lawson-tumelo commentedon Sep 2, 2024
To explain;
I think go-cose retracted a published version since the last version of hcsshim was published.
It plays havoc with our internal build process, in that we are unable to allow "go mod" and "tidy" to run without explicitly pinning specific dependencies, which is never best practice, especially if there are other third-party libraries in the mix.
When building and fetching dependencies everything blows up with an unresolved dependency on go-cose v1.2.0 because the go.mod for hcsshim specifies go-cose v1.2.0 as a dependency. The dependency resolution step of the go build process attempts to go and download this specific go-cose version and fails because it doesn't exist.
Ideally, the fix here would be for the maintainers of hcsshim to update the go.mod to reference an active "published" version of go-cose (followed by a run of "go mod tidy" to ensure that the go.sum file is present and correct).
Hopefully, that makes a bit more sense. Sorry for my original cryptic message.
stlaz commentedon Sep 25, 2024
Please note that this now also breaks Kubernetes vendoring in stricter environments (i.e. with
GOPROXY=direct).It'd be great if you could make a stable release with the vendor fixed.
rawahars commentedon May 26, 2026
The issue reported that the indirect dependency
github.com/veraison/go-cose@v1.2.0(at commit8beabac) was unresolvable because the upstream maintainers retracted it (veraison/go-cose#153), and suggested downgrading tov1.1.0.Findings
No code changes required — the dependency has already been moved past the retracted version on
main:go.mod,test/go.mod, andvendor/modules.txtall pingithub.com/veraison/go-cose v1.3.0.v1.3.0exists on the module proxy and its owngo.modcarriesretractdirectives forv1.2.0("published in error") andv1.2.1, so Go tooling will never re-select the broken versions transitively.v1.3.0is preferable to thev1.1.0downgrade suggested in the issue.The issue can be closed as resolved.