build(secmem-crypto): require secmem v0.2.0 (secmem-crypto/v0.2.0) - #40
Merged
Conversation
Dependency-only patch, released as secmem-crypto/v0.1.1. The module pinned secmem v0.1.0, so anyone importing only secmem-crypto kept resolving the core that faults the process when a mutating call follows ReadOnly(). Bumping the require propagates that fix to crypto-only consumers. No secmem-crypto API or behavior change: the only source additions since its v0.1.0 are the FuzzSignerLifecycle fuzzer and seed corpus, both test-only, so gorelease puts this at the patch level. Note on ordering: this cannot build until v0.2.0 is a pushed tag — Go reads the required version's go.mod to build the module graph even in workspace mode (verified: 'unknown revision v0.2.0'). Merge and tag v0.2.0 first, then re-run this PR's checks.
go mod edit -require does not touch go.sum, so secmem-crypto lacked the v0.2.0 sums and the examples module (which consumes crypto) needed its own go.mod/go.sum refresh. Both now tidy and build standalone under GOWORK=off.
Re-running gorelease after the require bump (not before it) reports secmem-crypto/v0.2.0. The bump is itself the change that forces a minor: this module's exported API returns *secmem.SecureBuffer, so raising its secmem floor to v0.2.0 raises the minimum for every consumer, which is a dependency-graph change rather than a patch.
deadpoets
force-pushed
the
build/secmem-crypto-v0.1.1
branch
from
July 20, 2026 23:44
398df68 to
686e890
Compare
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
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.
Dependency-only release so crypto-only consumers get the crash fix.
secmem-cryptov0.1.0 pinssecmem v0.1.0, so anyone importing only this module still resolves the core that faults the process when a mutating call followsReadOnly(). Bumping therequirepropagates the fix without touching a line of crypto source.Version corrected: v0.2.0, not v0.1.1
I originally planned
v0.1.1, based on agoreleaserun made before the dependency bump — at that point only test files had changed, so patch was right. Re-running it after the edit gives:The bump is itself the change that forces a minor: this module's exported API hands back
*secmem.SecureBuffervalues, so raising itssecmemfloor to v0.2.0 raises the minimum for every consumer — a dependency-graph change they should opt into deliberately, not receive in a patch. It also keeps the two modules version-aligned.Also fixed here
go mod edit -requiredoes not updatego.sum, which broke two jobs:go.sum: one or more sums are missingexamples/module consumes crypto and needed its owngo.mod/go.sumrefreshBoth are now tidied and verified building standalone under
GOWORK=off.Expected remaining failure
secret-scanwill stay red while GitHub's API Requests / Actions partial outage persists. Its log shows a 503 onGET /repos/.../pulls/40/commits— a read, with 4991 rate-limit remaining, not a 403. Nothing to fix in this repo.Tag after merge: