Epic: feat(ssh): first-class SSH-only mode - never construct an HTTPS git URL, degrade API-only operations explicitly #187
Labels
No labels
breaking
bug
documentation
enhancement
epic
good first issue
help wanted
refactoring
resolution/duplicate
resolution/invalid
resolution/wontfix
security
severity/critical
severity/high
severity/low
severity/medium
status/abandoned
status/blocked
status/needs-decision
status/needs-info
status/needs-verification
testing
upstream
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
sixfold-space/madtea#187
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Today SSH is a retrofit:
auth use-sshflips an existing remote after the fact,clonebuilds HTTPS URLs,auth loginis token-first, and the docs treat SSH remotes as a you-manage-it side path. The enhancement: make SSH a first-class connection method you can choose from first contact - not a flip away from HTTPS, but a mode where madtea never puts a credential on the git wire and never constructs an HTTPS git URL at all.The honest boundary
Two channels, different physics:
So the mode is precisely: the token, if present, is used only for API calls over TLS; git never sees a credential; with no token at all, madtea still works fully as a git tool.
Scope sketch
protocol = ssh) set atauth logintime ("token + https git", "token + ssh git", or "ssh only, no token") or via a flag. Once set, every code path that builds a git URL builds the SSH form.madtea clone git@host:owner/repo.gitandmadtea clone owner/repounder ssh mode clone over SSH natively - no credential resolution, no GIT_ASKPASS, no HTTPS fallback.auth-side check that a usable key exists (agent or~/.ssh), that the forge host is inknown_hosts(with the fingerprint-verification steer for first contact - TOFU is the one place SSH is weaker than TLS), and assh -T git@host-style verification naming the authenticated user. madtea still does not generate or manage keys.auth loginstep that enables it - never a generic "not configured".git push origin HEAD:refs/for/<branch> -o topic=... -o title=...creates a PR entirely over SSH, no API call. Worth evaluating as the PR-creation path for true token-less operation; merge would still be API/web.Security rationale
git remote -vleak class outright) and no bearer token on the git wire.known_hostsTOFU (hence the preflight), and the fact that madtea guards plaintext token storage (ADR 0013) but cannot guard a passphrase-less key file - the docs should say so plainly.Acceptance (for the eventual build)
Related: ADR 0013 (credential storage), ADR 0017 (standard API target),
docs/guides/setup.mdSSH remotes section,auth use-ssh(the existing flip stays as the migration tool).SSH-only mode has landed end to end. All the slices are merged:
The result is the mode I wanted: with no token at all, madtea is still a full git tool over SSH - clone, push, finish, and even PR creation via AGit - and every operation that genuinely needs the REST API says so plainly instead of failing obscurely. No credential ever touches the git wire or a remote URL. The one honest counterweight, documented in the setup guide, is that known_hosts trust-on-first-use is where SSH is weaker than TLS, and madtea guards token storage but cannot guard a passphrase-less key file.
Closing the epic - every child is done.