2026-07-13 -- unattended git push from the jumphost (SEC-005)

The jumphost clone could not git push: every attempt died with could not read Username for 'https://git.baldurkeep.com'. The branch sat 12 commits ahead of origin for two days as a result -- a real data-loss exposure, since all of the D-112 / OPNsense edge work existed only on this box. Fixed by giving git a stored credential. Operator ruled the posture; recorded as SEC-005.

What was configured

git config --global credential.helper store     # -> ~/.git-credentials, mode 600

The token itself was written by the OPERATOR via a hidden prompt (getpass + /dev/tty), URL-encoded, file created 0600 from os.open so it is never briefly world-readable. The token was never read into agent context -- verification is by using the credential (push succeeds / file survives), never by printing it. Per the CLAUDE.md secrets rule.

Result: f5fd4f5..425d434 pushed; git ls-remote confirms origin HEAD == local HEAD.

Two GitBucket behaviours worth knowing (both cost us a cycle)

1. The git username is NOT the login you type into the web UI. The operator signs in to GitBucket with jesse.austin@neumatrix.com. That address is rejected for git transport. Measured against the real endpoints:

Note the whole API column is 401: GitBucket does not accept PAT basic-auth on /api/v3/, but does accept it for git transport. So an API probe is the WRONG way to validate this credential -- it produces a false negative. Validate against info/refs?service=git-receive-pack, which is what push actually uses.

2. credential.helper store DELETES the credential when the server rejects it. git calls credential reject on a 401, and the store helper erases the matching line. The first (bad-username) push therefore emptied ~/.git-credentials to 0 bytes, and the follow-up diagnostics were all authenticating with an empty string -- which looked like a corrupt/unparseable file and sent the investigation the wrong way for a beat. If the file mysteriously empties, the credential was rejected; it did not fail to write.

Consequence for tooling: validate before writing. The helper script now confirms push rights against GitBucket and only then persists the token, so a bad entry cannot silently wipe the store.

Security posture (SEC-005)

A long-lived, account-wide PAT now sits in plaintext on the jumphost, readable by anything running as jessea123. This is the accepted cost of unattended push, ruled by the operator. Mitigations in place: dedicated token (not a reused personal one), mode 600, and a recorded revoke path. GitBucket has no per-repo token scoping, so least-privilege is not achievable here -- the control is rotation, not scope.

Revoke/rotate: GitBucket -> Account Settings -> Applications. Do it at v1 close, or immediately if the jumphost is shared, rebuilt, or its disk leaves the premises.

Revert

git config --global --unset credential.helper
rm -f ~/.git-credentials

Then revoke the token in GitBucket. Pushes go back to requiring interactive auth.