SECURITY, IN THE OPEN

Your files.
Your keys.

Tether encrypts dotfiles on your machine before they reach Git. It checks synced packages before it installs them. You control the repository, the passphrase and the machines you trust.

Read the encryption code ↗

Encrypted before
they leave.

Personal dotfiles
AES-256-GCM
Encryption key
Protected with age
Storage
Your Git repository
Synced packages
Checked before install
Machine records
Signed with SSH keys

FOLLOW A FILE

Plaintext here.
Encrypted in Git.

Your local shell reads your dotfiles normally. Tether stores an encrypted copy in your sync repository.

PERSONAL DOTFILE ENCRYPTION
  1. Local dotfile.zshrc · Readable on your machine
  2. Encrypt locallyAES-256-GCM · Fresh nonce
  3. Sync through Gitzshrc.enc · Encrypted contents
Encryption is enabled by default. Package manifests remain readable in Git.

Authenticated encryption.

Tether uses a 256-bit key and a new random 96-bit nonce for each encryption operation.

The authentication tag detects changes to the encrypted contents.

A portable encrypted key.

Tether protects your encryption key with age and your passphrase. The encrypted key travels with your Git repo.

Your passphrase does not go into the repository.

Local files stay readable.

Your shell needs plaintext dotfiles. Protect your devices and local accounts, including the cached encryption key.

Encryption in Git does not protect an unlocked machine.

ONE PASSPHRASE. YOUR MACHINES.

Unlock your setup.
Keep control.

The first machine creates an encryption key. Other machines retrieve the encrypted key from your repo.

Run tether unlock to decrypt and cache it locally. Run tether lock to clear the cache.

Locking clears the key cache. Your local plaintext dotfiles remain on disk.

Terminal
tether unlock
tether lock
ON YOUR NEXT MACHINE
  1. Get the keyencryption.key.age from your repo
  2. Enter your passphraseDecrypt the key with age
  3. Read your dotfilesDecrypt and apply locally
The decrypted key cache stays local. Tether does not sync it to Git.

SUPPLY-CHAIN SECURITY

Synced packages.
Checked first.

Tether checks each synced package before it installs it. Machines sign their records, and you choose which machines to trust.

See the package checks

CHECK BEFORE A TEAM PUSH

Spot credentials
before your team does.

Before tether sync or the daemon pushes team dotfiles, Tether scans them for potential secrets and blocks the push when it finds one. A team-only sync and team files promote do not scan. Personal dotfiles are not scanned. They reach Git encrypted, unless you turn encryption off.

What the scanner looks for.

  • AWS access keys and GitHub tokens
  • API keys and bearer tokens
  • SSH and RSA private keys
  • Passwords and database credentials
  • High-entropy strings

What the scanner cannot promise.

Pattern matching can miss secrets or flag harmless text. Review your configuration and choose what you sync.

Use a private repository. Package manifests and repository metadata remain visible to people with repository access.

Review scanning patterns ↗

KNOW THE BOUNDARIES

Understand the protection.

Encryption protects stored contents.

Repository access alone does not reveal encrypted dotfile contents without the key or passphrase.

AES-GCM detects tampering with encrypted data. Git transport security depends on your SSH or HTTPS configuration.

Your repo can change, too.

Anyone with push access can edit manifests and machine records. Signed records and your local trust list limit what a sync installs from those changes. See supply-chain security.

Protect each machine’s ~/.tether/signing_key. Anyone with that key can sign records as that machine.

Your device needs protection, too.

Malware and compromised local accounts can access plaintext files or cached keys.

Use device encryption, a strong passphrase, and two-factor authentication for your Git host. Review secret warnings before syncing.

VERIFY THE DETAILS

The code is open.

Read the implementation and its tests.

Report a security issue.

Email security@tether-cli.com with the affected version, reproduction steps, and potential impact.

Keep vulnerability details out of public issues until a fix is available.