Add //go:build darwin to secure_enclave.m and secure_enclave.h so Go
ignores them on non-darwin platforms. Without this, the lint stage fails
on Linux with 'Objective-C source files not allowed when not using cgo
or SWIG' because the !darwin stub (macse_stub.go) doesn't use CGO.
Pin all three FROM lines with SHA256 digests per REPO_POLICIES.md:
- golangci/golangci-lint:v2.1.6@sha256:568ee1c1...
- golang:1.24-alpine@sha256:8bee1901...
- alpine:3.23@sha256:25109184... (was alpine:latest)
Also replaced mutable 'alpine:latest' tag with 'alpine:3.23'.
Restructure Dockerfile to match upaas/dnswatcher pattern:
- Separate lint stage using golangci/golangci-lint:v2.1.6 image
- Builder stage for tests and compilation (no lint dependency)
- Add fmt-check Makefile target
- Decouple test from lint in Makefile (lint runs in its own stage)
- Run gofmt on all files
- docker build verified passing locally
The previous checkout SHA was invalid, causing immediate CI failure.
Use the known-good actions/checkout v4.2.2 SHA. Simplify trigger to
on: [push] to match other repos. Keep --ulimit memlock=-1:-1 for
10MB secret tests that need mlock.
- Install golangci-lint v2 via binary download instead of go install
(avoids Go 1.25 requirement of golangci-lint v2.10+)
- Add darwin build tags to tests that depend on macOS keychain:
derivation_index_test.go, pgpunlock_test.go, validation (keychain tests)
- Move generateRandomString to helpers_darwin.go (only called from
darwin-only keychainunlocker.go)
- Fix unchecked error returns flagged by errcheck linter
- Add gnupg to builder stage for PGP-related tests
- Use --ulimit memlock=-1:-1 in CI for memguard large secret tests
- Add //nolint:unused for intentionally kept but currently unused test helpers
Per new policy: CI actions simply run 'docker build .'. The Dockerfile
now installs golangci-lint and runs 'make check' early in the build
process, so a successful docker build implies all checks pass.
- Dockerfile: add golangci-lint install and 'make check' before final build
- CI workflow: simplify to just 'docker build .' (no Go setup needed)
- Makefile targets unchanged
Audit of the codebase found 9 locations where errors or anomalous
conditions were silently swallowed or only logged via Debug(). Users
should be informed when something unexpected happens, even if the
program can continue.
Changes:
- DetermineStateDir: warn on config dir fallback to ~/.config
- info_helper: warn when vault/secret stats cannot be read
- unlockers list: warn on metadata read/parse failures (fixes FIXMEs)
- unlockers list: warn on fallback ID generation
- checkUnlockerExists: warn on errors during duplicate checking
- completions: warn on unlocker metadata read/parse failures
- version list: upgrade metadata load failure from Debug to Warn
- secrets: upgrade file close failure from Debug to Warn
- version naming: warn on malformed version directory names
Closes#19
When an unlocker directory exists but is missing unlocker-metadata.json,
log a debug warning and skip it instead of returning a hard error that
crashes the entire 'unlocker ls' command.
Closes#1
Change NewCLIInstance() and NewCLIInstanceWithFs() to return
(*Instance, error) instead of panicking on DetermineStateDir failure.
Callers in RunE contexts propagate the error. Callers in command
construction (for shell completion) use log.Fatalf. Test callers
use t.Fatalf.
Addresses review feedback on PR #18.
Verifies that getLongTermPrivateKey reads the derivation index from
vault metadata instead of using hardcoded index 0. Test creates a
mock vault with DerivationIndex=5 and confirms the derived key
matches index 5.
Previously, getLongTermPrivateKey() always used derivation index 0 when
deriving the long-term key from a mnemonic. This caused wrong key
derivation for vaults with index > 0 (second+ vault from same mnemonic),
leading to silent data corruption in keychain unlocker creation.
Now reads the vault's actual DerivationIndex from vault-metadata.json.
- isValidSecretName() now rejects names with '..' path components (e.g. foo/../bar)
- GetSecretObject() now calls isValidSecretName() before building paths
- Added test cases for mid-path traversal patterns
When os.UserConfigDir() fails, DetermineStateDir falls back to
os.UserHomeDir(). Previously the error from UserHomeDir was discarded,
which could result in a dangerous root-relative path (/.config/...) if
both calls fail.
Now DetermineStateDir returns (string, error) and propagates failures
from both UserConfigDir and UserHomeDir.
Closes#14
The isValidSecretName() regex only allowed lowercase letters [a-z], rejecting
valid secret names containing uppercase characters (e.g. AWS access key IDs).
Changed regex from ^[a-z0-9\.\-\_\/]+$ to ^[a-zA-Z0-9\.\-\_\/]+$ and added
tests for uppercase secret names in both vault and secret packages.
Add isValidSecretName() check at the top of GetSecretVersion(), matching
the existing validation in AddSecret(). Without this, crafted secret names
containing path traversal sequences (e.g. '../../../etc/passwd') could be
used to read files outside the vault directory.
Add regression tests for both GetSecretVersion and GetSecret.
Closes#13
