Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

crypto/secp256k1: fix 32-bit tests when CGO_ENABLED=0 #28602

Merged
merged 1 commit into from
Nov 28, 2023
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions crypto/secp256k1/secp256_test.go
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,9 @@
// Use of this source code is governed by a BSD-style license that can be found in
// the LICENSE file.

//go:build !gofuzz && cgo
// +build !gofuzz,cgo

Comment on lines +5 to +7
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are all of the tests here cgo-only? Or is it some subset? Because if the latter, then we should move those into secp256_cgo_test.go or something like that

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, so the answer to my question is "yes". However, the tests are really in the wrong location, aren't they?
I took one at random, TestSignDeterministic, moved it up a level from secp256k1 into crypto:

func TestSignDeterministic(t *testing.T) {
	seckey, err := ecdsa.GenerateKey(S256(), rand.Reader)
	if err != nil {
		panic(err)
	}
	msg := make([]byte, 32)
	copy(msg, "hi there")

	sig1, err := Sign(msg, seckey)
	if err != nil {
		t.Fatal(err)
	}
	sig2, err := Sign(msg, seckey)
	if err != nil {
		t.Fatal(err)
	}
	if !bytes.Equal(sig1, sig2) {
		t.Fatal("signatures not equal")
	}
}

When invoking it here, the test covers both the cgo implementation or nocgo, depending on flag usage.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The package crypto/secp256k1 is inherently a cgo-based implementation. I think we could definitely move those tests, but to fix the build, we should just merge this PR.

package secp256k1

import (
Expand Down