Wharfsync

Security model

How Wharfsync protects your credentials and your servers, and what it deliberately does not do.

Passwords live in your keychain, not in sftp.json

The old SFTP extensions read passwords straight from .vscode/sftp.json. That file gets committed to git, shared in screenshots and, worst of all, uploaded to the server itself, where anyone who can read the web root can read the password.

Wharfsync keeps passwords and key passphrases in your operating system keychain (through your editor's secret storage). On first run it offers to move any secrets out of your existing sftp.json. It shows you the exact change as a diff first, stores each secret, checks it can read it back, and only then rewrites the file without them. Comments and other settings are kept. No copy of the old file is left behind, because that copy would still contain the passwords.

The config can never be uploaded

This is a hard-coded rule, not a setting: any path inside a .vscode or .wharfsync folder, at any depth and in any letter case, is never uploaded, and nothing is ever downloaded into those folders either. It does not matter what your ignore list says, and a negated pattern cannot override it. Our automated tests upload whole projects to real SFTP, FTP and FTPS servers and then list the server to prove the config is not there.

You are warned about exposed secrets

If sftp.json still contains a password and your project is a git repository with a remote, Wharfsync warns you and offers to move the secrets to your keychain or add the file to .gitignore. It checks this locally: it reads your git config and never contacts GitHub or anyone else to ask whether a repository is public, so it warns for any remote.

Servers are pinned

  • SSH/SFTP host keys are pinned on first use. The first time you connect, Wharfsync shows the server's SHA-256 fingerprint and asks whether to trust it. There is no "accept all" setting. If the key ever changes, Wharfsync refuses to connect and tells you, until you deliberately forget the old key.
  • FTPS certificates that your system trusts are accepted as normal. A self-signed certificate is shown to you with its fingerprint and pinned if you trust it. Your password is sent only after the certificate has been accepted.
  • Plain FTP sends passwords unencrypted, so Wharfsync warns you once per server and suggests SFTP or FTPS.

You confirm anything destructive

  • Every remote delete asks first, and says it cannot be undone.
  • Before overwriting a file that is newer on the server than your copy, or that someone changed on the server since your last transfer, Wharfsync stops and asks.
  • A sync always starts as a dry run you can review. Deletions are confirmed again before they happen.
  • Pro users can mark a server as production. Deploying to it asks "You are about to deploy to PROD" first.
  • Pro keeps a local backup of each remote file before overwriting it, for 7 days.

Logs do not leak secrets

Every line of the Wharfsync output log passes through a redactor that removes the passwords and passphrases in use, licence keys, private keys, and credential-like patterns.

What Wharfsync sends, and to whom

  • Your files and credentials go only to the servers you configure.
  • The only thing sent to us is your licence key, when it is renewed (see the Privacy Notice).
  • There is no telemetry and no analytics. An automated check on every build fails if a telemetry library, or any unexpected web address, appears in the extension.

Licence keys

Licence keys are signed with Ed25519 and verified offline on your computer with a public key built into the extension. They contain no personal details. The licence server stores a random licence ID, the Stripe customer and subscription IDs, and the subscription's status and dates, and nothing else.

Workspace trust

Wharfsync only runs in workspaces you have marked as trusted in your editor, because a workspace's sftp.json decides which servers it connects to.

Reporting a vulnerability

Please email support@wharfsync.com with "Security" in the subject. We will acknowledge your report within 5 working days and will not take action against good-faith research.