Show HN: ラップトップは、あなたの秘密がまだプレーンテキストで残っている最後の場所

jitpass - just-in-timeパスワード 開発マシン用のjust-in-time認証情報。 ドキュメント・クイックスタート・サポートツール・コマンドリファレンス・セキュリティステータス: macOSのみ（Apple Silicon）、開発中。 jitとは（30秒で説明） あなたの秘密情報は、.envファイル、~/.aws/credentials、~/.zshrc exports、.npmrcトークン、MCP設定など、マシン上の様々な場所にプレーンテキストで存在します。あなたとして実行されているものは何でもそれらを読み取ることができます。悪意のあるcurl | sh、怪しいnpm install、またはあなたの完全な権限を持つエディタで実行されているAIエージェントなどです。jitは、各秘密情報をTouch IDで保護されたローカルの暗号化されたボールトに移動し、ファイルを書き換えてツールが引き続き機能するようにします。ディスク上にはデコイが置かれます。実際の値は、生体認証プロンプトの後、要求した特定のプロセスに対してのみ、メモリ内に表示されます。結果として、一度ロックを解除すると、jitはツール（またはエージェント）に認証情報を渡す前に尋ね、それ以外の時間はディスク上にデコイがあります。 起動方法 Codeから起動 claudeから起動 brew install jitpass/tap/jitpass またはHomebrewなしで: curl -sL https://dl.jitpass.com/jitpass/jit/releases/latest/download/jitpass_darwin_arm64.tar.gz | tar -xz jit sudo mv jit /usr/local/bin/ Apple Siliconのみ — Intel Macでは、ソースからgo install github.com/jitpass/jit/cmd/jit@latestでビルドしてください。 どちらかの方法を選んでください。以前にtarballからインストールしていてHomebrewに切り替える場合は、brew install後に古いコピーを削除してください（sudo rm /usr/local/bin/jit）。そうしないと、PATHに2つのjitが存在し、別々にアップグレードされるため、jit doctorがそれを検出します。 リリースはDeveloper IDで署名され、Appleによって公証されているため、どちらの方法でもGatekeeperプロンプトなしで実行できます。Homebrewはダウンロードを検疫し、Gatekeeperは公証チケットに対してそれらをクリアします。一方、curl（およびgo install）は、検疫フラグを一切設定しません。私たちの言葉を鵜呑みにせず、何を取得したかを確認するには、jit doctorを実行してください — そのjit行は署名CZC6BH93GJと報告し、jit upgradeが何かをインストールする前に実行するのと同じチェックを使用します。 アップグレード: brew upgrade jitpass、またはjit upgrade — 検証済みのセルフアップデート（スワップ前にDeveloper-ID署名とチェックサムの両方をチェックし、サービスを再起動します）。どちらの方法でも、ボールトは変更されません。 Homebrewはシェル補完をバイナリと共にインストールするため、jit <TAB>はサブコマンド、フラグ、ボールトパス、ラップ可能なツール名を最初から補完します。tarballまたはソースからインストールした場合は、自分で追加してください：echo 'source <(jit completion zsh)' >> ~/.zshrc && exec zsh どちらの方法でも、jit doctorは補完がシェルに到達していないかどうかを教えてくれます。 実際の使い方 jit scan # 読み取り専用。スキャンするファイルを変更せず、実際の値を表示しません。 jit vault init # ボールトを作成します（マスターキーはログインキーチェーンに保存）。 jit migrate --dry-run # マシン全体での修正計画をプレビューします。 jit migrate # 適用します：計画を表示し、[y/N]を尋ね、Touch IDを1回使用します。 jit migrate ~/code/myapp # または、1つのプロジェクトのみを修正します。 jit run -- npm run dev # ツールを実行します。実際の値はそのプロセスにのみ注入されます。 jit scan --path は、パスを指定しない場合、ホームディレクトリ全体をスキャンするため、大きなディレクトリでは少し時間がかかります。特定の場所に直接アクセスするには、パスを指定します：jit scan ~/.aws。 日常的には、ほとんど jit run -- <cmd> を使用します。独自のログイントークンを持つCLI（gh、glab、stripeなど）の場合、jit wrap gh を一度実行すると、その後は通常通りghと入力し続けるだけで済みます。 何が jit wrap、jit migrate、または何も必要としないか分からない場合？知る必要はありません。jit scan は、見つかったすべてをjitが保護するもの（1つのコマンド — ラップも含まれます）と、あなただけが修正できるものに分割します。ベアのjit migrate は、その計画全体を実行します： $ jit scan YOUR SECRETS: 7 — 0 protected by jit (0%) ▱▱▱▱▱▱▱▱▱▱ to 100%: one command +71% · 2 secrets only you can fix +29% jit will protect these — 5 secrets in 4 files, 0% → 71% → jit migrate ~/.zshrc STRIPE_API_KEY, DB_PASSWORD ~/.config/gh/hosts.yml GitHub CLI token · wraps gh ... only you can protect these — 2 secrets, 71% → 100% [rotate, then delete every copy] ! A production database password in 2 files → rotate it now, then delete every copy （jit scan --full は、Severitiesを含む従来のカテゴリ別インベントリと、Wrappable CLI Tokensセクションを依然として提供します。） 日常的なツール 認証情報を一度移行すれば、ツールはこれまで通り使用できます。 # AWS（およびTerraform、すべてのAWS SDK） jit migrate ~/.aws/credentials # キーはボールトに移動します。プレーンテキストファイルは残りません。 aws s3 ls # オンデマンドでボールトから解決されます。プレフィックスやフラグはありません。 terraform apply # 同じ認証情報、同じコマンド。 # GCP application-default credentials（マシン全体で共有される認証情報） jit migrate ~/.config/gcloud/application_default_credentials.json terraform apply # googleプロバイダーはADCを読み取ります。Touch IDプロンプト後に機能します。 # Docker / docker-compose jit migrate ~/.docker/config.json # レジストリログインはボールトに移動します。 jit run -- docker compose up # jitはこれを実行のために注入します。 docker login ghcr.io # これは引き続き機能します。ヘルパーはボールトに保存します。 # かつて ~/.zshrc にあったシェルエクスポート jit migrate ~/.zshrc # 1行のフックを残します。新しいシェルでは変数はそのままです。 ./deploy.sh # これらの変数を読み取るスクリプトは変更なく機能します。 # かつてプロンプトで入力し、現在はシェル履歴にあるトークン jit migrate ~/.zsh_history # 各トークンはボールトに移動します。コマンドは残りますが、秘密情報は残りません。 jit guard history # 次の記録を停止します（zsh）。 # （ベアの`jit migrate`も計画でこれを申し出て、確認を求めます。） # 独自のトークンを持つCLI（gh、stripe、glab） jit wrap gh # 一度だけ実行します。 gh pr list # トークンは呼び出しごとに注入され、永続的に使用できます。 最初に各ツールが実際の認証情報を要求する際に、jitは一度尋ね、ボールトがロックされるまで回答を記憶します。ボールトロックの上にどのように配置されるか、--trustが何をするか、ツールごとのプロンプトをオフにする方法については、Two Touch ID momentsを参照してください。 一部のツールはセットアップ不要で、他のツールはjit runを必要とするのはなぜですか？ 1つのルール：ツールはjitに秘密情報を自分で要求できますか？AWS（credential_process経由）、ログイン時のシェル、Dockerのレジストリログイン（credential helper経由）はすべて可能です。そのため、余分なタイピングは不要です。実行時にファイルを読み取るだけのツール（docker compose、プレーンSDK）は要求できないため、jit runはその値を渡します。マシン全体で共有される認証情報ファイル（GCP ADC、sops、npm、netrc）は、日常と同じように機能します。ツールを実行し、プロセスごとのプロンプトを承認してください。スクリプトやCIで応答するプロンプトがない場合、またはプロジェクト固有の設定が到達できないハードゲートを設けたい場合にのみ、jit run --with <name> を追加してください。サポートされているツールリストには、各ツールの正確な入力方法と、各ツールの配信方法が記載されています。 2回のTouch IDモーメント、1回ではありません jitは2つの異なるモーメントで指紋を要求し、2つの異なるジョブを実行します。 ボールトのロック解除。 ボールトがロックされた後にjitを初めて使用する際、1回のTouch IDでセッション全体（5分間のアクティビティ後に再ロックされ、どれだけ忙しくても8時間以上はロックされません）のボールトが開かれます。一度ロック解除すれば、コマンドごとにロック解除する必要はありません。 ツールへの認証情報の受け渡し。 それに加えて、特定のツールが実際の認証情報を要求する最初の際、jitはそれを渡す前に尋ね、要求しているものを明示します。これにより、ボールトが開いている間に、あなたが実行していないプログラムがあなたのキーを静かに使用することを防ぎます。 $ aws s3 ls Touch ID -> ボールトをロック解除します # ゲート1: 5分間ボールトを開きます Touch ID -> awsがaws認証情報を要求しています # ゲート2: このツール、この認証情報... ...あなたのバケット... $ aws s3 cp ./file s3://bucket/ # 同じツール、同じセッション: プロンプトなし。 $ terraform apply Touch ID -> terraformがaws認証情報を要求しています # 別のツール: それ自体で要求します。 ゲート2は、ロック解除されたボールトが自由な状態になるのを防ぎます。awsを自分で使用した後でも、それらの同じキーにアクセスしようとする怪しいnpm installは、それを名前付けたプロンプトをトリガーするため、拒否することができます。 2番目のゲートは不要ですか？オフにしてください。ボールトロックは維持されます（オフにする場合もTouch IDが必要で、閉じられたウィンドウを再開します）： jit service consent off # ボールトがロック解除されている間、ツールはサイレントに解決されます。 jit service consent on # ツールごとに再度尋ねます（デフォルト）。 何かを開始する