Orbit MD 1.1 adds Sign in with GitHub. This post covers how it’s wired, for developers deciding whether to let it near their repositories.
The GitHub App
Sign-in uses a GitHub App, Orbit MD, through the device flow: Orbit shows a code, the user approves it on github.com, and Orbit receives a user token. There’s no client secret in the app. Access is limited to repositories where the app is installed, so a public repository the user can see isn’t reachable until Orbit MD is added to it. Tokens are refreshed in the background and kept in the macOS Keychain through the Security framework, so only Orbit can read them without a prompt. GitHub setup covers installing the app.
Giving the token to git
Orbit still runs the system’s git. The token never goes into a remote URL, a command-line argument or a config file. Each git command gets it through GIT_CONFIG_* environment variables as an http.extraheader, along with rewrites that send git@github.com: addresses over HTTPS, so SSH remotes use the sign-in too.
While someone is signed in, every GitHub site uses only that sign-in. A site it can’t reach is refused with a message instead of falling back to credentials saved on the computer, so Orbit can’t publish under someone else’s login. Sites on other hosts keep using the computer’s own git login.
Roles
Roles come from the repository. A user who can push to the live branch, because it’s unprotected or they’re on a ruleset’s bypass list, is an approver. Write access makes an editor, and read access a viewer, who gets a read-only Orbit. Developer tools appear for admin and maintain. Roles shape the interface; the host’s permissions are what refuse a push.
Commit identity
Commits are authored as the signed-in user, with their GitHub noreply address, set in the environment of each git command. Orbit never writes to the user’s git config.
The release is on GitHub: Orbit MD 1.1.0.
For a less technical take on this, read Orbit MD 1.1: sign in with GitHub.