enject

Verstecke .env-Geheimnisse vor neugierigen KI-Augen.

(Hinweis: Dieses Projekt hieß früher enveil und wurde in enject umbenannt)

KI-Codierungstools wie Claude Code, Copilot, Cursor und andere können Dateien in Ihrem Projektverzeichnis lesen, was bedeutet, dass eine unverschlüsselte .env-Datei ein versehentlicher Geheimnis-Dump ist, der nur darauf wartet, passiert zu werden. Das ist nicht nur Theorie. Es ist ein bekanntes Problem, das mir mehrfach passiert ist (selbst nachdem ich Claude explizit angewiesen hatte, nicht in Claudes settings.json zu schauen). enject löst dies, indem sichergestellt wird, dass Klartext-Geheimnisse niemals auf der Festplatte existieren. Ihre .env-Datei enthält nur symbolische Verweise; die tatsächlichen Werte befinden sich in einem verschlüsselten lokalen Speicher und werden beim Start direkt in Ihren Kindprozess eingefügt.

Dieses Projekt ist inspiriert von Filip Hrics Lösung/Blogbeitrag, die ein ähnliches Konzept unter Verwendung von 1Password nutzt. Ich wollte eine eigenständige Lösung, die nicht auf Drittanbieterdienste angewiesen ist, woraus diese Lösung entstand. Und ja, dieses Projekt wurde fast vollständig mit Claude Code zusammen mit einer Reihe manueller Überprüfungen und Tests erstellt.

Vorteile und Einschränkungen

Dieses Projekt wurde hauptsächlich entwickelt, um das bekannte Problem zu entschärfen, dass KI-/LLM-Tools versehentlich .env-Geheimnisse in Ihrem Projekt lesen. Weitere Vorteile sind die Verhinderung von Geheimnislecks, falls eine .env versehentlich in ein Repository committet wird, die Möglichkeit, .env-Dateien mit Verweisen anstelle von Klartext-Geheimnissen zu teilen, und die Möglichkeit, den verschlüsselten Speicher selbst zu teilen.

Dieses Projekt ist kein Allheilmittel, um zu verhindern, dass ein KI-Agent Ihre Geheimnisse erhält. Ein Agent kann beispielsweise immer noch Code schreiben (versehentlich oder durch Prompt-Injection), der Geheimnisse zur Laufzeit an die Terminalausgabe oder eine Datei exfiltriert. Wir raten dringend davon ab, sich auf dieses Tool oder allgemein auf .env-Dateien zu verlassen, um Produktionsgeheimnisse zu speichern.

Funktionsweise

Ihre .env-Datei sieht so aus:

DATABASE_URL=en://database_url
STRIPE_KEY=en://stripe_key
PORT=3000

Technisch gesehen ist es sicher, sie zu committen (tun Sie das vielleicht trotzdem nicht), und was noch wichtiger ist: sicher für alle KI-Tools, die versehentlich (oder vielleicht nicht so versehentlich) darin herumschnüffeln.

Wenn Sie enject run -- npm start ausführen, passiert Folgendes:

1. Sie werden nach Ihrem Master-Passwort gefragt (niemals sichtbar, niemals in der Shell-Historie)
2. Aus Ihrem Passwort wird mit Argon2id (64 MB Speicher, 3 Iterationen) ein 256-Bit-AES-Schlüssel abgeleitet
3. Der lokale Speicher wird mit AES-256-GCM entschlüsselt – die Speicherdatei ist eine 12-Byte-Zufalls-Nonce, gefolgt von authentifiziertem Chiffretext
4. Jeder en://-Verweis wird gegen die entschlüsselte Zuordnung aufgelöst
5. Der Schlüssel und die Passwortbytes werden aus dem Speicher entfernt
6. Ihr Kindprozess wird mit den aufgelösten Werten in seiner Umgebung gestartet

Die Speicherdatei ist ein binäres Blob. Ohne das Master-Passwort ist sie nicht von zufälligem Rauschen zu unterscheiden. Die Nonce wird bei jedem Schreibvorgang neu generiert, sodass eine Wiederverwendung der AES-GCM-Nonce unmöglich ist. Jede Änderung am Chiffretext – selbst ein einzelnes umgekipptes Bit – führt dazu, dass die Authentifizierung fehlschlägt und die Entschlüsselung verweigert wird.

---

Installation

Via Cargo

Diese Version befindet sich noch in der Alpha-Phase, daher muss bei der Installation die aktuelle Version angehängt werden, wenn cargo install aufgerufen wird

cargo install enject --version 0.2.0-alpha 

Aus dem Quellcode

Erfordert Rust 1.70+.

git clone https://github.com/greatscott/enject
cd enject
cargo build --release

Die kompilierte Binärdatei befindet sich unter target/release/enject. Installieren Sie sie einmal an einem Ort in Ihrem PATH, damit Sie sie von jedem Projekt aus ausführen können:

macOS / Linux (bash oder zsh)

# Option A: ~/.local/bin (kein sudo erforderlich, unter Linux üblich)
mkdir -p ~/.local/bin
cp target/release/enject ~/.local/bin/

# Option B: /usr/local/bin (erfordert sudo, systemweit verfügbar)
sudo cp target/release/enject /usr/local/bin/

# Option C: ~/.cargo/bin (bereits im PATH, wenn Sie rustup verwendet haben)
cp target/release/enject ~/.cargo/bin/

Wenn Sie Option A verwendet haben und ~/.local/bin noch nicht in Ihrem PATH ist, fügen Sie Folgendes zu Ihrer Shell-Konfiguration hinzu (~/.zshrc, ~/.bashrc oder ~/.bash_profile):

export PATH="$HOME/.local/bin:$PATH"

Laden Sie es dann neu:

source ~/.zshrc   # oder ~/.bashrc

Überprüfen Sie, ob es funktioniert:

enject --version

Projektspezifische Einrichtung (einmal pro Projekt ausführen)

Die Binärdatei ist global installiert – Sie müssen sie nie neu installieren. Aber jedes Projekt erhält seinen eigenen verschlüsselten Speicher:

cd your-project
enject init

Dies erstellt .enject/ im aktuellen Verzeichnis mit der Projektkonfiguration und dem verschlüsselten Speicher. Fügen Sie es zu .gitignore hinzu – es sollte niemals committet werden.

---

Verwendung

Speicher initialisieren

Führen Sie dies einmal pro Projekt im Projektstammverzeichnis aus:

enject init

Dies generiert ein zufälliges 32-Byte-Salt, schreibt .enject/config.toml, erstellt einen leeren verschlüsselten Speicher unter .enject/store und fordert Sie auf, ein Master-Passwort festzulegen. Fügen Sie .enject/ zu Ihrer .gitignore hinzu – der Speicher sollte niemals committet werden.

Geheimnisse hinzufügen

enject set some_database_url
# Eingabe: Wert für 'database_url': (versteckt)

enject set some_api_key

Werte werden immer interaktiv eingegeben. Es gibt keine Möglichkeit, einen Wert als Befehlszeilenargument zu übergeben – dies verhindert, dass Geheimnisse in der Shell-Historie oder in der ps-Ausgabe erscheinen.

Geheimnisse in .env referenzieren

DATABASE_URL=en://some_database_url
MY_API_KEY=en://stripe_key
PORT=3000

Einfache KEY=VALUE-Zeilen werden unverändert durchgereicht. Nur en://-Verweise werden aufgelöst.

Ihre App ausführen

enject run -- npm start
enject run -- python manage.py runserver
enject run -- cargo run

Alles nach -- wird unverändert an das Betriebssystem übergeben. Der Kindprozess erbt Ihre gesamte Shell-Umgebung (sodass PATH, HOME usw. vorhanden sind) mit den .env-Werten, die darübergelegt werden.

Weitere Befehle

enject list              # gespeicherte Schlüsselnamen anzeigen (niemals Werte)
enject delete <key>      # ein Geheimnis entfernen
enject import <file>     # alle Werte in einer Klartext-.env verschlüsseln, als en://-Vorlage neu schreiben
enject rotate            # Speicher mit einem neuen Master-Passwort neu verschlüsseln
### Bewusst fehlende Befehle

Es gibt kein `get` und kein `export`. Das Ausgeben eines Geheimniswerts auf stdout erzeugt einen KI-lesbaren Leckvektor – der ganze Sinn von enject ist es, Werte von der Festplatte und aus jedem lesbaren Ausgabestrom fernzuhalten.

---

## Sicherheitsüberprüfung

Jede Sicherheitsinvariante hat einen entsprechenden automatisierten Test und einen manuellen Inspektionspfad.

### Alle automatisierten Tests ausführen

```bash
cargo test

31 Tests, die alle nachfolgend genannten Behauptungen abdecken.

---

1. Geheimnisse werden niemals als Klartext auf die Festplatte geschrieben

Automatisiert: store::password::tests::test_encrypt_decrypt_roundtrip