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

Test against a matrix of golang versions and update various actions versions #34

Merged
merged 26 commits into from
Jun 30, 2023

Conversation

pgporada
Copy link
Member

@pgporada pgporada commented Jun 9, 2023

  • The v4 folder tests now generate an ephemeral ECDSA key pair, extract a PKCS#11 CKA_EC_POINT from that key pair, and pass the existing TestSignECDSA implementation.
  • Added a pre-configured softhsm directory with key material from v4/testdata/.
  • Several unused variables were removed from test files.
  • The main readme has been updated.
  • Fixes TestSignECDSA for newer versions of golang due to
--- FAIL: TestSignECDSA (0.00s)
panic: crypto/elliptic: attempted operation on invalid point [recovered]
	panic: crypto/elliptic: attempted operation on invalid point

Background

Starting in Golang 1.18, crypto/elliptic: IsOnCurve began returning true for invalid field elements (elliptic curve points X and Y). [1]

Relatedly in Golang 1.19, crypto/elliptic: IsOnCurve was updated to explicitly panic when operating on invalid field elements. [2]

However, this should have still been failing on Golang 1.18 (even though it wasn't!!) because the points (1,1) are invalid. I believe what happened here was [3]:

[...] started returning random points when asked to operate on invalid points in Go 1.18, like at the line you linked. (We decided to make it an explicit panic in Go 1.19 to avoid painful debugging sessions like the one we caused you, sorry, but it was too late for Go 1.18.

@pgporada
Copy link
Member Author

Test fail on go1.20.4 and go1.20.5.

unrecognized search:
  Type: 0, Value: 0200000000000000
  Type: 100, Value: 0000000000000000
  Type: 120, Value: 02
  Type: 122, Value: 02
--- FAIL: TestSignECDSA (0.00s)
panic: crypto/elliptic: attempted operation on invalid point [recovered]
	panic: crypto/elliptic: attempted operation on invalid point

goroutine 23 [running]:
testing.tRunner.func1.2({0x5b5340, 0x63fb90})
	/opt/hostedtoolcache/go/1.20.4/x64/src/testing/testing.go:1526 +0x24e
testing.tRunner.func1()
	/opt/hostedtoolcache/go/1.20.4/x64/src/testing/testing.go:1529 +0x39f
panic({0x5b5340, 0x63fb90})
	/opt/hostedtoolcache/go/1.20.4/x64/src/runtime/panic.go:884 +0x213
crypto/elliptic.panicIfNotOnCurve({0x641a28?, 0x732b30?}, 0x0?, 0x4090dd?)
	/opt/hostedtoolcache/go/1.20.4/x64/src/crypto/elliptic/elliptic.go:215 +0xa5
crypto/elliptic.Marshal({0x641a28, 0x732b30}, 0xb?, 0x0?)
	/opt/hostedtoolcache/go/1.20.4/x64/src/crypto/elliptic/elliptic.go:105 +0x31
github.com/letsencrypt/pkcs11key/v4.(*Key).getPublicKeyID(0xc0000882a0, {0x5d59a0?, 0x754bc0})
	/home/runner/work/pkcs11key/pkcs11key/v4/key.go:228 +0x285
github.com/letsencrypt/pkcs11key/v4.(*Key).setup(0xc0000882a0)
	/home/runner/work/pkcs11key/pkcs11key/v4/key.go:275 +0x179
github.com/letsencrypt/pkcs11key/v4.setup(0xc000085380, {0x5d59a0, 0x754bc0})
	/home/runner/work/pkcs11key/pkcs11key/v4/key_test.go:202 +0x135
github.com/letsencrypt/pkcs11key/v4.TestSignECDSA(0xc000085380)
	/home/runner/work/pkcs11key/pkcs11key/v4/key_test.go:261 +0x30
testing.tRunner(0xc000085380, 0x60e838)
	/opt/hostedtoolcache/go/1.20.4/x64/src/testing/testing.go:1576 +0x10b
created by testing.(*T).Run
	/opt/hostedtoolcache/go/1.20.4/x64/src/testing/testing.go:1629 +0x3ea
FAIL	github.com/letsencrypt/pkcs11key/v4	0.007s

@pgporada
Copy link
Member Author

pgporada commented Jun 12, 2023

The test failure begins appearing with go1.19 (release notes). Go1.18.10 doesn't exhibit this.

crypto/elliptic

Operating on invalid curve points (those for which the IsOnCurve method returns false, and which are never returned by Unmarshal or by a Curve method operating on a valid point) has always been undefined behavior and can lead to key recovery attacks. If an invalid point is supplied to Marshal, MarshalCompressed, Add, Double, or ScalarMult, they will now panic.

ScalarBaseMult operations on the P224, P384, and P521 curves are now up to three times faster, leading to similar speedups in some ECDSA operations. The generic (not platform optimized) P256 implementation was replaced with one derived from a formally verified model; this might lead to significant slowdowns on 32-bit platforms.

@pgporada pgporada requested review from jsha and a team June 16, 2023 16:47
Copy link

@aarongable aarongable left a comment

Choose a reason for hiding this comment

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

LGTM with a few nits

.github/workflows/test.yml Show resolved Hide resolved
v4/key_test.go Outdated Show resolved Hide resolved
.gitignore Show resolved Hide resolved
.gitignore Show resolved Hide resolved
.gitignore Outdated Show resolved Hide resolved
@pgporada pgporada requested a review from a team June 20, 2023 20:33
Copy link
Contributor

@jsha jsha left a comment

Choose a reason for hiding this comment

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

Why check in the softhsm token directory rather than initialize it on each run like before? Were you finding that importing the keys was taking up a lot of time in each test run?

If so, I think it would be better to not check in the softhsm token directory (since its format is not guaranteed consistent between versions, I think), but instead have the test generate it once in a gitignored directory and then reuse the cached version. This would have the added advantage the the initialization steps would regularly be run in CI so we would know they still work.

Also, the current version does git operations in the cleanup step of the test. That creates some possibilities for unpleasant surprises that I'd like to avoid. If we go to the "cache instead of check in" approach, we can avoid the need to do git operations during cleanup.

v4/key_test.go Outdated Show resolved Hide resolved
v4/key_test.go Show resolved Hide resolved
@pgporada
Copy link
Member Author

Why check in the softhsm token directory rather than initialize it on each run like before? Were you finding that importing the keys was taking up a lot of time in each test run?

The only reason I have is that I liked the way it was done in the ceremony-demos repo and wanted to replicate it here. Was it the right thing to do? I don't know, but there was precedent.

Also, the current version does git operations in the cleanup step of the test. That creates some possibilities for unpleasant surprises that I'd like to avoid. If we go to the "cache instead of check in" approach, we can avoid the need to do git operations during cleanup.

I took that from ceremony-demos too. I can remove it here and explicitly rm files as needed.

@beautifulentropy
Copy link
Member

@jsha this PR is blocked on your approval (requested changes).

@pgporada pgporada requested a review from jsha June 28, 2023 18:55
@jsha
Copy link
Contributor

jsha commented Jun 28, 2023

Talked in standup - Phil is planning to go back to the Old Ways on this. The reason the ceremony-demos repo does it differently is (we think):

(a) we wanted to have the .yaml files need to include the slot IDs
(b) SoftHSM generates slot IDs randomly
(c) we preferred not to have automagic regeneration of the .yamls

Copy link
Contributor

@jsha jsha left a comment

Choose a reason for hiding this comment

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

Looking nice! One shell nit left.

test.sh Outdated Show resolved Hide resolved
v4/key_test.go Outdated Show resolved Hide resolved
Copy link

@aarongable aarongable left a comment

Choose a reason for hiding this comment

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

LGTM with two comments that don't have to be addressed

Comment on lines +14 to +18
cd v4/testdata
openssl ecparam -name prime256v1 -genkey | openssl pkcs8 -topk8 -nocrypt > entropic_ecdsa.key
openssl req -new -x509 -key entropic_ecdsa.key -out entropic_ecdsa.pem -days 1000 -subj /CN=entropic\ ECDSA
openssl req -new -newkey rsa:2048 -nodes -x509 -keyout silly_signer.key -out silly_signer.pem -days 1000 -subj /CN=silly\ signer
cd -

Choose a reason for hiding this comment

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

(Not for this PR, but for the future: it might be cool to replace this comment and the comment in //v4/testdata/readme.md with a //v4/testdata/generate.go so that the instructions can be simplified to "if you need to regenerate key material, run go generate".)

v4/key_test.go Outdated Show resolved Hide resolved
pgporada and others added 2 commits June 30, 2023 09:29
Co-authored-by: Aaron Gable <aaron@aarongable.com>
@pgporada pgporada requested review from aarongable and jsha June 30, 2023 14:40
@pgporada pgporada merged commit 879185e into master Jun 30, 2023
6 checks passed
@pgporada pgporada deleted the test-against-latest-go branch June 30, 2023 15:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants