Obsync

Obsidian Sync CLI for syncing vaults on headless Linux servers with full end-to-end encryption.

Security Scan

The skill's stated purpose (an Obsidian sync CLI) matches what the instructions describe, but the runtime instructions reference environment variables and secret-handling behaviors that are not declared in the metadata and raise practical security/privacy concerns.

Purpose & Capability

Name, description, required binary (obsync), and install method (Homebrew formula bpauli/tap/obsync; source build option) are coherent with an Obsidian Sync CLI. Commands (login, pull/push/watch, install systemd service) align with a vault-syncing tool and require an Obsidian account/subscription as expected.

Instruction Scope

SKILL.md instructs the agent and user to run obsync commands, configure a keyring backend, optionally export OBSYNC_KEYRING_PASSWORD, install and manage per-user systemd services, and writes config to ~/.config/obsync/config.json. Those actions are within the tool's purpose, but the instructions reference environment variables (OBSYNC_KEYRING_BACKEND, OBSYNC_KEYRING_PASSWORD, OBSYNC_CONFIG) and file-based keyring usage that are not declared in the skill metadata and that could lead to storing secrets in plaintext or on-disk in an insecure way.

Install Mechanism

Install uses a Homebrew formula (bpauli/tap/obsync) and offers building from source (Go 1.25+). Homebrew is a reasonable low-risk install mechanism, but this is a third‑party tap (not the official core tap) so users should inspect the tap/formula and upstream GitHub release artifacts before trusting the binary.

Credentials

Metadata declares no required env vars or primary credential, yet the instructions explicitly reference several env vars (OBSYNC_KEYRING_BACKEND, OBSYNC_KEYRING_PASSWORD, OBSYNC_CONFIG) and expect login credentials (email/password, optional MFA). The omission in metadata is an inconsistency; additionally, suggesting exporting a plaintext OBSYNC_KEYRING_PASSWORD or using a file-based keyring on headless servers increases the risk of secret exposure and may be disproportionate without guidance on secure storage/access control.

Persistence & Privilege

The skill suggests installing per-user systemd service units (obsync@<vault-id>.service), enabling lingering for always-on sync, and storing config under ~/.config/obsync. This grants a persistent user-level daemon and on-disk config/secrets, which is expected for a sync agent but is a persistent footprint the user should review. The skill does not set always:true and does not request system-wide privileges in the metadata.

What to consider before installing

This skill appears to be what it says (an Obsidian sync CLI) but has a few red flags you should address before installing: 1) Inspect the Homebrew formula (bpauli/tap/obsync) and the GitHub repo/release artifacts to confirm the binary's provenance; do not blindly trust a third-party tap. 2) The SKILL.md references environment variables (OBSYNC_KEYRING_BACKEND, OBSYNC_KEYRING_PASSWORD, OBSYNC_CONFIG) and login credentials but the metadata does not declare them — treat any instructions to export passwords as risky. Prefer using a secure OS keyring rather than exporting plaintext passwords or using file-backed keyrings on multi-user systems. 3) When installing the systemd user service, review the generated unit file and the file locations/permissions for ~/.config/obsync and any on-disk keyring files to ensure secrets are not world-readable. 4) On shared or CI-hosted servers, avoid setting OBSYNC_KEYRING_PASSWORD in environment variables; consider a dedicated user account and strict filesystem permissions. 5) If you need higher assurance, build obsync from source yourself (Go 1.25+) or review the source code to confirm secret handling and network endpoints. Finally, request the skill author update metadata to declare the env vars and credential needs explicitly so the behavior is transparent.

Use obsync to sync Obsidian vaults on headless Linux servers. Requires an Obsidian Sync subscription and account credentials.

Setup (once)

• obsync login (enter email, password, and optional MFA code)
• For headless servers: export OBSYNC_KEYRING_BACKEND=file
• Optionally set keyring password: export OBSYNC_KEYRING_PASSWORD=mysecret
• Verify: obsync list

Output

• Default: human-friendly terminal output with colors and spinners.
• Use --json / -j for JSON output.
• Use --verbose / -v for debug logging.

Common commands

• Log in: obsync login
• List vaults: obsync list
• Pull vault: obsync pull "My Notes" ~/notes -p "e2e-password"
• Pull and save password: obsync pull "My Notes" ~/notes -p "e2e-password" -s
• Push local changes: obsync push "My Notes" ~/notes -p "e2e-password"
• Watch (continuous sync): obsync watch "My Notes" ~/notes -p "e2e-password"
• Install systemd service: obsync install "My Notes" ~/notes
• Check service status: obsync status "My Notes"
• View service logs: journalctl --user -u obsync@<vault-id>.service -f
• Uninstall service: obsync uninstall "My Notes"

Flags

• -p, --password — E2E encryption password
• -s, --save-password — save E2E password to keyring for future use
• -v, --verbose — enable debug logging
• -j, --json — JSON output to stdout
• --config — path to config file (or OBSYNC_CONFIG env var)
• --version — print version and exit

Notes

• Requires a valid Obsidian Sync subscription.
• E2E encryption uses AES-256-GCM with scrypt key derivation.
• Pull/push compare files by SHA-256 hash — only changed files are transferred.
• Watch mode uses WebSocket for remote changes and fsnotify for local changes (500ms debounce).
• Large files are handled with 2MB chunked transfers.
• Automatic reconnection with exponential backoff (1s-60s) on connection loss.
• The .obsidian/ directory (themes, plugins, settings) is synced.
• For headless servers without a desktop keyring, use OBSYNC_KEYRING_BACKEND=file.
• For always-on sync on headless servers, enable lingering: loginctl enable-linger $USER.
• Config is stored at ~/.config/obsync/config.json.