Skip to content

build(secmem-crypto): require secmem v0.2.0 (secmem-crypto/v0.2.0) - #40

Merged
deadpoets merged 3 commits into
mainfrom
build/secmem-crypto-v0.1.1
Jul 21, 2026
Merged

build(secmem-crypto): require secmem v0.2.0 (secmem-crypto/v0.2.0)#40
deadpoets merged 3 commits into
mainfrom
build/secmem-crypto-v0.1.1

Conversation

@deadpoets

@deadpoets deadpoets commented Jul 20, 2026

Copy link
Copy Markdown
Owner

Dependency-only release so crypto-only consumers get the crash fix.

secmem-crypto v0.1.0 pins secmem v0.1.0, so anyone importing only this module still resolves the core that faults the process when a mutating call follows ReadOnly(). Bumping the require propagates 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 a gorelease run made before the dependency bump — at that point only test files had changed, so patch was right. Re-running it after the edit gives:

Suggested version: v0.2.0 (with tag secmem-crypto/v0.2.0)

The bump is itself the change that forces a minor: this module's exported API hands back *secmem.SecureBuffer values, so raising its secmem floor 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 -require does not update go.sum, which broke two jobs:

  • apicompatgo.sum: one or more sums are missing
  • examples — the examples/ module consumes crypto and needed its own go.mod/go.sum refresh

Both are now tidied and verified building standalone under GOWORK=off.

Expected remaining failure

secret-scan will stay red while GitHub's API Requests / Actions partial outage persists. Its log shows a 503 on GET /repos/.../pulls/40/commits — a read, with 4991 rate-limit remaining, not a 403. Nothing to fix in this repo.

Tag after merge:

git tag -s secmem-crypto/v0.2.0 -m "..."
git push origin secmem-crypto/v0.2.0

@deadpoets deadpoets changed the title build(secmem-crypto): require secmem v0.2.0 (secmem-crypto/v0.1.1) build(secmem-crypto): require secmem v0.2.0 (secmem-crypto/v0.2.0) Jul 20, 2026
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
deadpoets force-pushed the build/secmem-crypto-v0.1.1 branch from 398df68 to 686e890 Compare July 20, 2026 23:44
@deadpoets
deadpoets merged commit f006acc into main Jul 21, 2026
19 checks passed
@deadpoets
deadpoets deleted the build/secmem-crypto-v0.1.1 branch July 21, 2026 00:56
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.

1 participant