In internal/cli/init.go, after calling vlt.CreatePassphraseUnlocker(passphraseBuffer), the Init() function redundantly re-reads the unlocker's public key, re-encrypts the long-term private key, and overwrites longterm.age:
// CreatePassphraseUnlocker already wrote longterm.age correctlypassphraseUnlocker,err:=vlt.CreatePassphraseUnlocker(passphraseBuffer)// Then Init does it AGAIN:unlockerPubKeyData,err:=afero.ReadFile(cli.fs,filepath.Join(unlockerDir,"pub.age"))// ... reads pub key, encrypts lt key, writes longterm.age again
CreatePassphraseUnlocker (in internal/vault/unlockers.go) already correctly:
Generates the unlocker keypair
Encrypts the long-term key to the unlocker
Writes longterm.age
The duplicate code in Init overwrites this with a functionally equivalent but separately encrypted blob. This is:
Wasteful: double encryption work
A maintenance hazard: if CreatePassphraseUnlocker changes its encryption scheme, Init would overwrite with the old approach
Confusing: suggests CreatePassphraseUnlocker doesn't handle this step
Fix
Remove the redundant longterm.age encryption and writing from Init().
## Bug
In `internal/cli/init.go`, after calling `vlt.CreatePassphraseUnlocker(passphraseBuffer)`, the `Init()` function redundantly re-reads the unlocker's public key, re-encrypts the long-term private key, and overwrites `longterm.age`:
```go
// CreatePassphraseUnlocker already wrote longterm.age correctly
passphraseUnlocker, err := vlt.CreatePassphraseUnlocker(passphraseBuffer)
// Then Init does it AGAIN:
unlockerPubKeyData, err := afero.ReadFile(cli.fs, filepath.Join(unlockerDir, "pub.age"))
// ... reads pub key, encrypts lt key, writes longterm.age again
```
`CreatePassphraseUnlocker` (in `internal/vault/unlockers.go`) already correctly:
1. Generates the unlocker keypair
2. Encrypts the long-term key to the unlocker
3. Writes `longterm.age`
The duplicate code in `Init` overwrites this with a functionally equivalent but separately encrypted blob. This is:
- **Wasteful**: double encryption work
- **A maintenance hazard**: if `CreatePassphraseUnlocker` changes its encryption scheme, `Init` would overwrite with the old approach
- **Confusing**: suggests `CreatePassphraseUnlocker` doesn't handle this step
## Fix
Remove the redundant longterm.age encryption and writing from `Init()`.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Bug
In
internal/cli/init.go, after callingvlt.CreatePassphraseUnlocker(passphraseBuffer), theInit()function redundantly re-reads the unlocker's public key, re-encrypts the long-term private key, and overwriteslongterm.age:CreatePassphraseUnlocker(ininternal/vault/unlockers.go) already correctly:longterm.ageThe duplicate code in
Initoverwrites this with a functionally equivalent but separately encrypted blob. This is:CreatePassphraseUnlockerchanges its encryption scheme,Initwould overwrite with the old approachCreatePassphraseUnlockerdoesn't handle this stepFix
Remove the redundant longterm.age encryption and writing from
Init().