[revopushbot]

First part of the final clean-up (REV-144): a security fix.

Problem

~/.revopush.config holds the access key, but it was written with default permissions (usually 644), so any other user on the machine could read it.

Fix

In script/auth/connection.ts:

• New files are created as 600, readable and writable only by the owner.
• Logging in again over an existing file tightens the file before the new key is written, so the key is never in a file others can read.
• Files saved by older versions are tightened whenever the CLI reads them, which happens on every command. Users don't need to log in again. If tightening fails (for example, the file belongs to another user), the error is ignored, so it can never log anyone out.

Tests

• test/connection.ts covers a new file, saving over a 644 file, and reading a 644 file. It's skipped on Windows, where file modes don't apply.
• The tests set 644 explicitly, so a strict umask can't make them pass without the fix. All three fail on main.
• configFilePath is exported, so the tests check the same file the code writes.

Verification

Check	main	This branch
revopush login against a fake server, new config file	644	600
Existing 644 file, then any command (whoami)	stays 644	600
45 CLI commands against a fake server	Same output and server requests	Same output and server requests

• Tests: all 162 pass on macOS and on Linux (Docker, Node 20.19.0).
• Build, lint and format: tsc, lint and format are clean.

Known edge cases (from review, not handled)

• sudo -E logins: if someone logged in with sudo -E, the file belongs to root. It used to stay readable by the normal user; now it is 600, so that user has to log in again without sudo.
• File owned by another user: if the config file in your home folder belongs to another user but you can still write to it, tightening fails and is ignored, and the key is still written to it. This setup is unlikely.

🤖 Generated with Claude Code

[revopushbot]

Closing without merging: we're keeping the config file permissions as they are, so customer setups don't change behaviour unexpectedly.