Offline-Wiederherstellungssoftware entwickeln, die ein Geheimnis in Teile aufteilt

## Wiederherstellungssoftware so bauen, dass sie Jahre später in schweren Momenten funktioniert Behandeln Sie Wiederherstellungssoftware als Infrastruktur, die möglicherweise jahrelang unberührt bleibt, bevor jemand in einer schwierigen Lage darauf angewiesen ist. Ein Fehler kann erst auftreten, wenn kein Maintainer verfügbar ist; optimieren Sie deshalb auf dauerhafte Korrektheit statt auf schnellen Abschluss. - Verstehen Sie vor einer Änderung das bestehende System einschließlich der Gründe für seine Grenzen und Konventionen. - Halten Sie sich an etablierte Muster und Standards, statt eine nur lokal bequeme Ausnahme einzuführen. - Gestalten Sie Anleitungen, Meldungen und Schnittstellen für Menschen, die technisch unerfahren, überfordert oder in Trauer sein können. - Prüfen Sie das tatsächliche Ergebnis und nicht nur den Abschluss der zugewiesenen Bearbeitung. Sorgfalt, Einfühlungsvermögen, Übertragbarkeit und langfristige Betriebsfähigkeit sind technische Anforderungen und keine freiwillige Verfeinerung. ## Vor dem Ändern oder Entfernen einer Funktion alle verbundenen Stellen verfolgen Suchen Sie, bevor Sie eine Konstante, Hilfsfunktion, einen Typ, eine Liste oder eine Konfigurationsquelle hinzufügen. Ermitteln Sie die maßgebliche Definition und leiten Sie daraus ab, damit parallele Kopien nicht auseinanderdriften. - Verfolgen Sie vor dem Ändern oder Entfernen einer Funktion jedes verbundene Element in Quelltext, Stilen, Übersetzungen, Typen, Tests, Kommentaren, Dokumentation und Erstellungskonfiguration. - Entfernen Sie veraltetes Verhalten vollständig. Kommentieren Sie es nicht aus, verbergen Sie es nicht durch Gestaltung und belassen Sie es nicht hinter einer Bedingung. - Suchen Sie nach der Änderung erneut nach verwandten Kennungen und Begriffen, damit verbleibende Verweise absichtlich und nicht überraschend gefunden werden. - Prüfen Sie die abschließenden Änderungen auf sachfremde Bearbeitungen, duplizierte Logik, ungenutzten Quelltext und unvollständige Bereinigung. Eine Funktion gilt erst dann als entfernt, wenn ihr vollständiger Abhängigkeits- und Verweisgraph bearbeitet wurde. ## Eine gemeinsame Kryptologik für Kommandozeile und Browser nutzen Halten Sie kryptografische Vorgänge und anderes Kernverhalten in einer gemeinsamen Implementierung, die sowohl vom Befehlszeilen- als auch vom Browserpfad genutzt wird. Schlanke Adapter dürfen sich unterscheiden, doch sicherheitsrelevante Logik, Konstanten, Formate und Validierungsregeln sollten eine einzige maßgebliche Quelle haben. - Ordnen Sie vor einer Bearbeitung zu, welche Laufzeitumgebung für Erstellung, Wiederherstellung, Paketierung, Verhalten der Benutzeroberfläche und Bereitstellung zuständig ist. - Verwenden Sie gegebenenfalls browsernativen Quelltext für einen schlanken Offline-Wiederherstellungspfad und ein kompiliertes Browsermodul für die Erstellung, wenn diese Grenze Wiederverwendung oder Übertragbarkeit verbessert. - Erzeugen Sie Offline- und netzwerkgestützte Varianten mit Funktionsschaltern zur Erstellungszeit, damit das Offline-Artefakt keinen ungenutzten Netzwerkquelltext enthält. - Stellen Sie kompilierte Funktionen über eine kleine, ausdrückliche Vermittlungsschicht bereit, statt ihr Verhalten in der Wirtssprache zu duplizieren. - Halten Sie die Wahl von Laufzeitumgebung und Modulen über alle Pakete hinweg einheitlich. Wenn eingebettete Ressourcen eine zirkuläre Abhängigkeit erzeugen würden, laden Sie das erzeugte Modul beim Start der Anwendung und schleusen Sie seine Bytes über eine ausdrückliche Schnittstelle ein, statt den Zyklus zu erzwingen. ## Die Wiederherstellung vollständig offline halten und nur bewährte Verschlüsselung nutzen Eigenständige Wiederherstellungsartefakte müssen sich ohne Installation lokal öffnen lassen und die Wiederherstellung ohne Server oder Netzwerkverbindung abschließen. Jedes verteilte Paket muss in sich geschlossen und vom ursprünglichen Repository unabhängig bleiben. - Erlauben Sie Netzwerkzugriff nur für eng begrenzte und dokumentierte Varianten, etwa ein zeitgesteuertes Freigabeartefakt, das kurz einen externen Signalgeber prüft, oder eine selbst betriebene Seite, die ihr Archiv vom selben Server abruft. - Halten Sie jedes eigenständige Artefakt für Empfänger vollständig offlinefähig, selbst wenn eine optionale Servervariante existiert. - Stellen Sie sicher, dass weniger Schlüsselteile als der erforderliche Schwellenwert keinerlei Informationen über das Geheimnis preisgeben, auch nicht durch hinzugefügte Metadaten. - Verwenden Sie etablierte Verfahren für Verschlüsselung, Geheimnisteilung mit Schwellenwert und Zeitverriegelung; erfinden Sie niemals eigene kryptografische Primitive. - Platzieren Sie jede Zeitverriegelungsschicht als mehrstufige Absicherung innerhalb der primären Verschlüsselungsschicht. - Verlangen Sie für jede kryptografische Änderung Tests, eine Prüfung und eine klare Begründung. Fügen Sie dem Wiederherstellungspfad keine Telemetrie, Nutzungsanalyse, entfernten Schriftarten, Abhängigkeiten von Inhaltslieferdiensten oder andere verborgene Netzwerkanforderungen hinzu. ## Paketformate stabil halten und alles Nötige zur Wiederherstellung einbetten Behandeln Sie Paketaufbau, Format der verschlüsselten Nutzdaten, Kodierung der Schlüsselteile und Wiederherstellungsschritte als Bestandteile des Protokolls. Änderungen daran erfordern Migrationsplanung, aktualisierte Testdaten, Kompatibilitätstests und eine dokumentierte Begründung. - Sorgen Sie dafür, dass die Wiederherstellung über Plattformen, Browser und Sprachen hinweg funktioniert. - Betten Sie Skripte, Stile, Vorlagen und andere erforderliche Ressourcen ein, statt sich auf externe Dienste oder kurzlebige Formate zu verlassen. - Nehmen Sie in jedes Empfängerpaket verständliche Textanweisungen und druckbare Anleitungen, die Metadaten des verschlüsselten Archivs sowie eine personalisierte Wiederherstellungsseite auf. - Ist das verschlüsselte Manifest höchstens 10 MB groß, betten Sie es in die personalisierte Seite ein, damit die Wiederherstellung ohne separate Datei funktioniert; beachten Sie eine ausdrückliche Option zum Abschalten der Einbettung. - Lassen Sie die browsergestützte Erstellung geeignete Manifeste automatisch einbetten, wenn dieser Pfad keine separate Übersteuerung besitzt. - Vermeiden Sie für Menschen, die Pakete erstellen oder wiederherstellen, Laufzeitabhängigkeiten von Entwicklungswerkzeugen. Versprechen Sie nach der Verteilung der Schlüsselteile keinen nachträglichen Widerruf und behaupten Sie nicht, das System werde garantiert für immer funktionieren. Streben Sie Langlebigkeit an, ohne Gewissheit zu übertreiben. ## Zuerst einen fehlschlagenden Test schreiben und bei Seitenänderungen Browsertests ergänzen Schreiben Sie zuerst einen fehlschlagenden Test, beobachten Sie den Fehler und bringen Sie ihn anschließend zum Bestehen. Ein Test, dessen Fehlschlag nie beobachtet wurde, prüft möglicherweise nicht das beabsichtigte Verhalten. - Ergänzen Sie für jede Änderung, die eine Wiederherstellungs- oder Erstellungsseite im Browser betrifft, einen Test auf Browserebene. - Verwenden Sie gezielte Einheiten- und Integrationstests für Kernlogik, Archivverarbeitung, Konfiguration und Befehlsverhalten. - Führen Sie Browser-Ende-zu-Ende-Tests aus, wenn Sie die HTML-Struktur, Browserquelltext, die Anordnung oder Sichtbarkeit beeinflussende Stile oder kompilierte Browseranbindungen ändern. - Verlangen Sie keine langsamen Browsertests für reine Übersetzungsarbeiten, Dokumentationsänderungen, Textanpassungen oder Änderungen ausschließlich an interner Logik, die das Browserverhalten nicht beeinflussen können. - Führen Sie die einschlägigen Tests selbst aus, bevor Sie den Abschluss melden; überlassen Sie die Verifizierung nicht anderen. Suchen Sie nach jeder Änderung nach verwandten Begriffen, erstellen Sie die betroffenen Artefakte erneut, führen Sie die passenden Tests aus und prüfen Sie das Ergebnis. ## Die Build- und Testbefehle des Repositorys statt behelfsmäßiger Werkzeuge verwenden Verstehen Sie die vollständige Erstellungskette von der Kompilierung des Benutzeroberflächen-Codes über Browsermodule bis zum endgültigen Befehlszeilenprogramm. Erzeugte Skripte und kompilierte Module können in spätere Stufen eingebettet werden, daher ist die Reihenfolge der Befehle ein Bestandteil der Korrektheit. - Verwenden Sie die maßgeblichen Befehle des Repositorys für Erstellung, Tests, lint, statische Seiten und Entwicklungsserver. - Verwenden Sie den Testwrapper des Projekts, statt das Testprogramm der Sprache direkt aufzurufen, wenn erzeugte Ressourcen vor Kompilierung oder Einbettung vorhanden sein müssen. - Führen Sie den enger gefassten dokumentierten Befehl für einen einzelnen Test nur aus, wenn seine Voraussetzungen bereits erzeugt wurden. - Beschränken Sie netzwerkabhängige Testsammlungen auf Änderungen, die diese Verbindungen benötigen. - Wenn eine Abhängigkeit oder ein Erstellungswerkzeug nicht verfügbar ist, wechseln Sie in die festgelegte reproduzierbare Entwicklungsumgebung des Repositorys, statt ein behelfsmäßiges Paketausführungsprogramm zu verwenden. Erzeugen Sie statische Artefakte aus eingebetteten Quellen und halten Sie private Wiederherstellungsartefakte aus der Bereitstellung auf öffentlichen Seiten heraus, sofern der Veröffentlichungsentwurf sie nicht ausdrücklich einschließt. ## Ruhige, klare Texte für Menschen in einer belastenden Aufgabe schreiben Verfassen Sie an Benutzer gerichtete Texte so, als wäre jedes Wort für einen Menschen gewählt worden, der vor einer folgenreichen und belastenden Aufgabe steht. Freundlichkeit soll aus Klarheit, Rhythmus und Voraussicht entstehen und nicht aus gespielter Beruhigung. - Bevorzugen Sie direkte, menschliche Sprache gegenüber technischen Formulierungen: Beschreiben Sie den nächsten Schritt, ohne den Leser zum Entschlüsseln der Implementierung zu zwingen. - Sprechen Sie Menschen direkt an und vermeiden Sie passive Anweisungen, wenn ein klarer aktiver Satz möglich ist. - Verwenden Sie einheitliche und auf die Zielgruppe abgestimmte Begriffe. Bevorzugen Sie in nach außen gerichteten Texten „Menschen, denen Sie vertrauen“ und „Teile“; in Anleitungen für Empfänger können Beziehungswörter wie „Freunde“ angemessen sein. - Vermeiden Sie Ausrufezeichen, Füllwörter, überzogene Behauptungen, mechanische Formulierungen und erzwungene Begeisterung. - Verwenden Sie Gedankenstriche mit Leerzeichen auf beiden Seiten statt doppelter Bindestriche oder Gedankenstriche ohne Leerzeichen. - Halten Sie Statusmeldungen knapp, aber menschlich, und vermitteln Sie Erfolge ruhig, statt sie zu verschweigen. Bevorzugen Sie eine weiche, warme, nicht unternehmensgeprägte Bildsprache mit zurückhaltendem Kontrast. Zentralisieren Sie die Farbwerte, vermeiden Sie reines Schwarz, leuchtendes Rot und unternehmensgeprägtes Blau, und halten Sie jede bewusste visuelle Ausnahme getrennt und dokumentiert. ## Dokumentation aktualisieren und Änderungsprotokolle danach schreiben, was Nutzer bemerken Wenn sich Verhalten ändert, aktualisieren Sie die zugehörige Dokumentation, Hinweise für Mitwirkende und Betriebsanweisungen in derselben Änderung. Architekturnotizen müssen Laufzeitgrenzen, erzeugte Ressourcen, Netzwerkausnahmen und die zur Reproduktion der Ergebnisse erforderlichen Befehle erläutern. - Halten Sie Konfigurations- und Erstellungsanweisungen mit der Implementierung synchron. - Aktualisieren Sie Testdaten und Migrationshinweise, wenn sich ein stabiles Format ändert. - Richten Sie Einträge im Änderungsprotokoll daran aus, was sich für die Menschen geändert hat, die die Software verwenden. - Beginnen Sie mit dem sichtbaren Ergebnis und fügen Sie nur so viel Umsetzungskontext hinzu, wie zum Verständnis nötig ist. - Lassen Sie interne Umstrukturierungen und Neuordnung des Quelltexts weg, sofern sie das beobachtbare Verhalten nicht verändern. Lesen Sie vor einem neuen Eintrag benachbarte Einträge, damit Sprachstil und Detailtiefe einheitlich bleiben. ## Beiträge an externe Dienste vom Beitragenden selbst prüfen und einreichen lassen Lesen Sie vor jeder Aktion, die in ein externes Aufgabenverwaltungssystem oder einen Dienst zur Verwaltung von Quellcode schreibt, die Beitragsrichtlinie des Projekts. Wenn diese Richtlinie menschliche Verantwortung verlangt, halten Sie vor dem Absenden an und erklären Sie, dass die beitragende Person für jede Zeile Quelltext und Prosa verantwortlich ist. - Zeigen Sie den vorgeschlagenen Änderungssatz, die Commit-Nachricht oder die Beitragsbeschreibung zur menschlichen Prüfung. - Bitten Sie die beitragende Person, das Material in eigenen Worten zu bearbeiten, Erklärungen ehrlich abzugeben und commit, push und Einreichung selbst vorzunehmen. - Entfernen Sie vor der Einreichung erzeugte Fußzeilen, Mitautorenzeilen, Füllmaterial und automatisierte Herkunftshinweise. - Führen Sie den externen Schreibvorgang nur aus, wenn die beitragende Person nach Erläuterung der Verantwortungsanforderung ausdrücklich darauf besteht. - Wenn sie dennoch darauf besteht, halten Sie den Text knapp und direkt, fügen Sie keine automatisierten Herkunftshinweise hinzu und wiederholen Sie die Anforderung einer menschlichen Prüfung ein letztes Mal. Unterstützung bei lokaler Bearbeitung und reine Lesezugriffe lösen diese Einschränkungen für externe Schreibvorgänge nicht aus. Die Veröffentlichungsautomatisierung soll vor der Veröffentlichung weiterhin Erstellungsläufe, Tests, lint und Browserprüfungen ausführen sowie plattformübergreifende Pakete, Prüfsummen und repräsentative Artefakte erzeugen.