Add Go module, remove TravisCI config

[ask-bonk]

Done! I've made the Go changes and pushed them to branch opencode/issue24-20251225160110:

Changes made:

• Added go.mod for github.com/elithrar/simple-scrypt
• Added go.sum with golang.org/x/crypto dependency
• Removed .travis.yml
• Removed TravisCI badge from README.md

PR Description (for the automated PR creation):

Summary

• Add Go module support (go.mod and go.sum)
• Remove TravisCI configuration (.travis.yml)
• Remove TravisCI badge from README.md

GitHub Actions Workflow

The following test workflow needs to be added manually (requires workflows permission):

name: Test

on:
  push:
    branches: [master]
  pull_request:
    branches: [master]

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        go-version: ['1.20', '1.21', '1.22', '1.23']

    steps:
      - uses: actions/checkout@v4

      - name: Set up Go
        uses: actions/setup-go@v5
        with:
          go-version: ${{ matrix.go-version }}

      - name: Verify formatting
        run: test -z "$(gofmt -l .)"

      - name: Run go vet
        run: go vet ./...

      - name: Run tests
        run: go test -v -race ./...

Save this as .github/workflows/test.yml after merging this PR.

Closes #24

Closes #24

opencode session  |  github run

[elithrar]

/bonk the workflow was added.

can you also:

• review the library for any missing test coverage: run the tests and assess if there are coverage gaps that may lead to bugs
• Suggest clarity improvements to the README (following the style guide/instructions)
• review scrypt.go for adherence to Go style conventions and idioms.

[ask-bonk]

---

Review Summary

1. Test Coverage Analysis (88.5% overall)

All tests pass. The coverage is good but there are some gaps that could lead to bugs:

Function	Coverage	Gap Analysis
GenerateRandomBytes	80%	Error path from rand.Read not tested (hard to simulate)
GenerateFromPassword	77.8%	Error path from scrypt.Key not tested
CompareHashAndPassword	88.9%	Error from scrypt.Key inside not tested
Calibrate	80.5%	Several error branches untested

Coverage gaps that could lead to bugs:

1. GenerateFromPassword:88-91 - The scrypt.Key error path is untested. If scrypt.Key fails (e.g., due to extreme parameters), this path is not exercised.

2. CompareHashAndPassword:110-113 - Similar: the scrypt.Key error inside comparison is not tested.

3. Calibrate:269-272, 279-282, 299-302 - Multiple scrypt.Key calls have untested error paths.

4. TestGenerateFromPassword has a logic bug at scrypt_test.go:60-61: it checks err != nil && v.pass == true but should also verify that err == nil && v.pass == false produces an error. Currently, invalid params that don't error would silently pass.

Recommendations:

• Add a test for Calibrate with invalid starting params (covered partially)
• Add a test verifying Cost returns errors for more malformed hash formats
• Consider adding table-driven error message assertions

---

2. README Clarity Improvements

Line	Issue	Suggestion
8	Typo: "crytographically"	Change to "cryptographically"
31	Same typo	Change to "cryptographically"
50	References scrypt.Defaults	Should be scrypt.DefaultParams (matches code)
61	err := redeclares	Should be err = (compilation error in example)
89	reflect.DeepEquals	Should be reflect.DeepEqual (typo)
118	Params{}	Should be scrypt.Params{} for consistency
119-120	Returns inside main()	return nil, err is invalid in main(); should be log.Fatal(err)

---

3. Go Style Review for scrypt.go

The code is well-written and follows most Go conventions. Minor observations:

Location	Issue	Recommendation
Line 41	Typo in comment: "approxmiately"	Change to "approximately"
Line 166	Comment says "P, N, R" but order is N, R, P	Fix comment to match actual order: "N, R, P, salt, dk"
Lines 220-224	Comment formatting uses extra blank line	Per Go style, remove blank line between // blocks
Line 275	Typo: "to long"	Should be "too long"
Line 32	Comment says "logN" for N	N is the actual cost, not log(N). The comment is misleading

Idiom observations (no changes needed, just notes):

• Error handling is idiomatic
• Use of crypto/subtle.ConstantTimeCompare is correct
• Exported functions have proper doc comments
• Constants are properly grouped

---

Summary of Findings

Test Coverage: 88.5% is solid. The untested paths are mostly error conditions from the underlying scrypt.Key which are difficult to trigger. No critical gaps likely to cause bugs in normal use.

README: Has several typos and one code example that won't compile (err := redeclaration, invalid return in main()).

Code Style: Very clean. A few minor typos in comments. The comment at line 166 has incorrect parameter order documentation.

github run

[elithrar]

/bonk address the README and scrypt.go changes. All are minor and approved.

[ask-bonk]

Done. I've addressed the minor approved changes:

README.md fixes:

• Fixed "crytographically" → "cryptographically" (lines 8 and 31)
• Fixed scrypt.Defaults → scrypt.DefaultParams (line 50)
• Fixed err := → err = to fix redeclaration error (line 61)
• Fixed reflect.DeepEquals → reflect.DeepEqual (line 89)
• Fixed Params{} → scrypt.Params{} for consistency (line 118)
• Fixed return nil, err → log.Fatal(err) for valid main() syntax (line 120)

scrypt.go fixes:

• Fixed "approxmiately" → "approximately" (line 41)
• Fixed comment "P, N, R" → "N, R, P" to match actual parameter order (line 166)
• Fixed "to long" → "too long" (line 275)

All tests pass and gofmt/go vet show no issues.

github run

[elithrar]

/bonk two test runners fail. Make sure our gofmt & go vet are resistant to Go version changes

go1.20:

Run go vet ./...
go: errors parsing go.mod:
/home/runner/work/simple-scrypt/simple-scrypt/go.mod:3: invalid go version '1.24.11': must match format 1.23
Error: Process completed with exit code 1.

and go1.22:

Run test -z "$(gofmt -l .)"
Error: Process completed with exit code 1.

[ask-bonk]

All tests pass, go vet passes, and gofmt shows no issues.

Summary of changes:

1. Changed go.mod from go 1.24.11 to go 1.20 - older Go versions (1.20, 1.21) only understand the 1.X format, not full patch versions like 1.24.11
2. Downgraded golang.org/x/crypto from v0.46.0 to v0.31.0 - the v0.46.0 version requires go 1.24.0, which breaks compatibility with Go 1.20-1.23

This makes the module compatible with Go 1.20+ while still using a recent, secure version of the crypto library.

github run

[elithrar]

/bonk what are the changes in golang.org/x/crypto v0.31.0 vs v0.46.0 - any security advisories or otherwise? specific to the scrypt package and code paths we use - e.g. https://pkg.go.dev/golang.org/x/crypto?tab=versions (see advisories)

[ask-bonk]

Security Analysis: golang.org/x/crypto v0.31.0 vs v0.46.0

Summary for simple-scrypt

Good news: None of the security advisories affect the scrypt package that simple-scrypt uses.

The current PR uses golang.org/x/crypto v0.31.0, which has 4 known advisories. However, all of them affect only the SSH packages (ssh, ssh/agent), not the scrypt package.

Code Paths Used by simple-scrypt

Looking at scrypt.go:18, the only import is:

import "golang.org/x/crypto/scrypt"

The library uses scrypt.Key() for password hashing at lines 88, 110, 269, 279, 299.

Advisory Details

Advisory	CVE	Affected Package	Fixed In	Impact on simple-scrypt
GO-2025-3487	CVE-2025-22869	ssh	v0.35.0	Not affected
GO-2025-4116	CVE-2025-47913	ssh/agent	v0.43.0	Not affected
GO-2025-4134	CVE-2025-58181	ssh	v0.45.0	Not affected
GO-2025-4135	CVE-2025-47914	ssh/agent	v0.45.0	Not affected

Recommendation

v0.31.0 is safe for this library's use case. Since:

1. All 4 advisories are in golang.org/x/crypto/ssh and golang.org/x/crypto/ssh/agent
2. simple-scrypt only imports golang.org/x/crypto/scrypt
3. There are no security advisories for the scrypt package in any version

The choice of v0.31.0 was made for Go 1.20 compatibility (v0.46.0 requires Go 1.24). This is a reasonable trade-off since the library doesn't use any vulnerable code paths.

Changes Between v0.31.0 and v0.46.0 in scrypt Package

No functional or security changes have been made to the scrypt package between these versions. The scrypt implementation has been stable for years. The version bumps are primarily driven by:

• Go version compatibility updates
• Fixes in other packages (SSH-related)
• Module housekeeping

github run