Repository navigation
fix(keys): build PublicKey.ZERO without reading Key32.zero - #1666
Merged
Merged
Conversation
Key32's companion constructs PublicKeys. When Key32 initialized first, PublicKey's companion ran while Key32.zero was still null, and PublicKey.ZERO threw. Both classes then failed to initialize for the rest of the JVM, which broke every later test that used a key.
github-actions
Bot
added
area: crypto
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A test that touched
Key32.mockbefore anything had loadedPublicKeyfailed withExceptionInInitializerErroratKey.kt:51. Every later test in the same JVM that used a key then failed withNoClassDefFoundError. While working on #1664, one new test in:services:opencodetook 17 of 20 tests down with it.Key32's companion buildsPublicKeys, which initializesPublicKey's companion, andPublicKey.ZEROwas built fromKey32.zero.zerois the last field inKey32's companion, so it was still null whenZEROread it:ZEROnow builds its bytes fromLENGTH_32directly. The app was not exposed: no production code constructs aKey32or reads its companion, and initializingPublicKey,MintorVaultinitializesKey32first as their superclass, an order that already worked.KeyInitOrderTestloadsKey32first in a fresh class loader, so it checks this order no matter what earlier tests in the JVM have loaded. It fails without the change.