AshNote CLI

Selbstzerstörende Secrets direkt aus dem Terminal: ein einziges natives Binary, keine Runtime nötig. Vollständig Zero-Knowledge: Ver- und Entschlüsselung passieren auf deinem Rechner, der Schlüssel reist nur im Link, den du teilst.

Installation

Läuft auf macOS (Apple Silicon & Intel) und Linux. Homebrew on Linux nutzt denselben Tap. Lieber ohne Brew? Die rohen Binaries liegen auf der Release-Seite, einfach in den PATH legen. Die CLI ist quelloffen (Apache-2.0).

Nutzung

Versteckter Prompt: der sichere Standard

ashnote send -i fragt das Secret mit unsichtbarer Eingabe ab, wie sudo. Nichts landet in der Shell-History oder der Prozessliste.

Pipes & Dateien

cat .env | ashnote send --ttl 1h --reads 3 oder ashnote send -f kubeconfig.yaml (Dateien bis 256 KB). Der Link kommt auf stdout. Direkt in pbcopy pipen.

Empfangen

ashnote get "<link>" claimt und entschlüsselt lokal. Text geht auf stdout, Dateien werden gespeichert. Nach dem letzten Lesen ist der Drop für alle weg.

$ ashnote send -i --ttl 1h
secret (hidden):
https://ashnote.io/d/…/…#key ← der Schlüssel hat deinen Rechner nie verlassen

Optionen

-i, --interactive: versteckter Prompt (empfohlen für getippte Secrets)
-f, --file PFAD: Datei statt Text senden
-t, --ttl 5m|1h|24h|3d|7d: Ablauf (Standard 24h)
-r, --reads N: Lesevorgänge bis zum Verbrennen (Standard 1)
-p, --passphrase: zusätzliche Passphrase, lokal in den Schlüssel gemischt
--api URL / Env ASHNOTE_URL: Self-Hosted- oder Staging-Backends

Ehrlichkeit zur Shell-History

ashnote send "secret" als Argument landet in der Shell-History und ist während der Laufzeit in ps sichtbar. Die CLI warnt dich, wenn du das interaktiv tust. Nutze stattdessen -i, stdin oder -f. Ein empfangener Link in der History ist übrigens meist harmlos: Nach dem letzten Lesen ist er kryptografisch wertlos. Bei Multi-Read-Drops hilft ein führendes Leerzeichen vor dem Befehl (setopt HIST_IGNORE_SPACE in der zsh), um ihn ganz aus der History zu halten.