HOME / SECURITY

TRANSPARENCY IS A FEATURE

Trust the code.
Know the limits.

Clear security behavior, explicit warnings and publicly reviewable source. We would rather explain the real trade-offs than hide them behind marketing.

IMPORTANT · VERSION 1.0.2

Saved credentials are not encrypted.

BetterTTY currently uses secrets.mode = plain-v1. Saved passwords and private-key contents can be stored as human-readable values in BetterTTY.json, its backups and exported configurations. There is no built-in encrypted credential vault or master password in version 1.0.2.

Use BetterTTY only on trusted machines, protect the files with operating-system permissions, and never post private configurations, SSH keys or logs publicly.

Read the complete source security notes ↗

HOW WE HANDLE SSH TRUST

Verify before authenticating.

Authentication doesn't mean blindly trusting whoever answers on a port. BetterTTY verifies a server's host key and asks you to make deliberate trust decisions.

01

Unknown host

Review the host-key fingerprint against an independent trusted source before trusting it.

02

Changed key

A changed host key must not be silently accepted. Investigate unexpected changes before reconnecting.

03

Portable trust records

Trusted known-host records can support multiple valid algorithms for the same host and port.

PRACTICAL PRECAUTIONS

Keep your environment private.

✓ Do

  • Use an OS account and device you trust.
  • Protect BetterTTY.json and every backup/export.
  • Verify host-key fingerprints out of band.
  • Review diagnostic logs before sharing.
  • Back up remote files before overwriting them.
  • Verify release origin and SHA-256 checksums.

✕ Don't

  • Assume passwords or private keys are encrypted at rest.
  • Commit real configs to GitHub.
  • Accept unexpected SSH fingerprint changes without investigation.
  • Rely on SFTP upload overwrite atomicity.
  • Assume disabled logging means zero operational data exists elsewhere.
  • Treat an exported config as a sanitized sessions-only bundle.

CURRENT PRODUCT LIMITS

What 1.0.2 doesn't do.

Some features are intentionally conservative or planned for the future. They are not silently advertised as shipping today.

Security & credentials

  • No master password or encrypted at-rest credential vault.
  • Exported configuration and backups can contain plaintext secrets.
  • No automatic sanitizing of shared configuration files.
  • Diagnostic metadata can contain host, user and path identifiers.

Terminal & management

  • Multi-Exec is a placeholder only, not command broadcasting.
  • Session traffic is not OS-wide network monitoring.

SFTP transfers

  • No folder synchronization or mirroring.
  • No transfer resume or parallel transfers.
  • No recursive delete for non-empty directories.
  • No rename, chmod/chown or metadata preservation.
  • No symlink following during recursive folder transfer.
  • Remote overwrites are not atomic.

Distribution

  • No claim of Apple notarization unless a specific release is notarized.
  • The listed Mac package is Intel x86_64, not universal.
!
Remember the overwrite risk

An interrupted upload may leave a partial remote target. In particular, replacing an existing remote file is not guaranteed crash-safe. Back up important remote targets first.

OPEN SOURCE

Inspect. Question. Improve.

Security work benefits from scrutiny. Read the source, review a relevant document, or report a reproducible bug through GitHub.

View source ↗Report an issue ↗Documentation ↗

Please do not post real credentials, private keys, or sensitive infrastructure identifiers in public issues.