Unable to sign component descriptor using signing server

[8R0WNI3]

What happened:
When executing ocm sign componentversion, the command fails to send the calculated digest of the component descriptor to the configured signing server. Based on the environment, the error message differs:

Darwin Kernel Version 23.6.0: Mon Jul 29 21:13:04 PDT 2024; root:xnu-10063.141.2~1/RELEASE_ARM64_T6020 arm64:

failed signing example.org/my-component:0.1.0: example.org/my-component:0.1.0: failed signing component descriptor: unable to send http request: Post "https://<signing-server-url>/sign/rsassa-pss?hashAlgorithm=SHA-256": read tcp <first-ip-address>-><second-ip-address>: read: connection reset by peer
finished with 1 error(s)
Error: signing: example.org/my-component:0.1.0: failed signing component descriptor: unable to send http request: Post "https://<signing-server-url>/sign/rsassa-pss?hashAlgorithm=SHA-256": read tcp <first-ip-address>-><second-ip-address>: read: connection reset by peer

Linux 6.8.0-36-generic # 36-Ubuntu SMP PREEMPT_DYNAMIC Mon Jun 10 13:20:23 UTC 2024 aarch64:

failed signing example.org/my-component:0.1.0: example.org/my-component:0.1.0: failed signing component descriptor: unable to send http request: Post "https://<signing-server-url>/sign/rsassa-pss?hashAlgorithm=SHA-256": EOF
finished with 1 error(s)
Error: signing: example.org/my-component:0.1.0: failed signing component descriptor: unable to send http request: Post "https://<signing-server-url>/sign/rsassa-pss?hashAlgorithm=SHA-256": EOF

What you expected to happen:
Signing of component descriptor to finish successfully.

How to reproduce it (as minimally and precisely as possible):
Using the ocm sign componentversion command to sign a component descriptor using a signing server. The commit, which introduced this bug, is dd2e6ba. Earlier versions of OCM cli did not show this behaviour and are able to properly sign the component descriptor. Note that the mentioned change bumped Golang from 1.22.5 to 1.23.2.

[jakobmoellerdev]

Im now trying to reproduce with a signing server. I assume its related to some code that broke that inputs the data stream to the http call but TBH no idea yet. Will let you know once I know some details.

[jakobmoellerdev]

For reference, could you please add the complete command with the relevant signing server configuration so I have a good reproducer?

[jakobmoellerdev]

After a lot of debugging we found out that the issue is due to golang/go#70047 being introduced by default in go1.23 . (see https://tldr.fail/ for background)

To mitigate, you can for now edit your go.mod file before building the cli

go mod edit -godebug=tlskyber=0

We are still thinking about wether we want to introduce this in our general builds as this is only a problem if the signing server is run behind a specific set of networking infrastructure that cannot deal with this new behavior yet.