feat(ssh): clone over SSH natively in ssh modes - no HTTPS URL construction, no credential resolution #345
No reviewers
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!345
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "issue-293-ssh-clone-native"
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?
Summary
Under git-protocol ssh or ssh-only,
madtea clone owner/repobuilds git@host:owner/repo.git (host resolved through the same precedence chain as credentials, token not required), and an explicit git@ or ssh:// URL clones as first contact - no credential resolution, no GIT_ASKPASS, no HTTPS fallback. A structural test pins that the ssh clone path never constructs an https URL or invokes GIT_ASKPASS. In ssh-only mode an explicit https:// URL skips credential resolution entirely and clones unauthenticated as-given - a leftover token never touches the git wire or the API - and auth guidance points at the SSH preflight. In plain ssh mode an explicit https URL remains a deliberate per-invocation override, matching the gh yardstick. Post-clone remotes keep the SSH form; auth use-ssh stays the migration tool. https and unset modes pinned unchanged.Closes #293.
Closes #293