OpenGewerk 0.7.0

Die siebte Fassung bringt den größten Teil von Phase 2, dem Kern für Elektro und PV. Zu den Prüfungen kommen das Protokoll der Wiederholungsprüfung nach DIN VDE 0105-100, das Geräteverzeichnis mit der Prüfung nach DGUV Vorschrift 3, die Prüfung der Elektroinstallation als Prüfbericht je Objekt und die Prüffrist der Erstprüfung, jeweils mit der Frist der nächsten Prüfung. Für PV, Wallbox und Speicher gibt es das Inbetriebsetzungsprotokoll nach VDE-AR-N 4105, die PV-Anlagendokumentation, die Netzbetreiber mit Anmeldung, Fertigmeldung und der Ausfüllhilfe für das Marktstammdatenregister, die Inbetriebnahme von Wallbox und Speicher und die Förderunterlagen. Am Auftrag stehen jetzt das Abnahmeprotokoll mit der Gewährleistungsfrist, die Aufforderung zur Abnahme und die Mängel mit Status und Mängelbericht.

Dazu kommen Material und Lager: Verkaufspreise aus Einkaufspreis und Aufschlag, der Metallzuschlag, der Import aus DATANORM mit eigenen Bildschirmen, die Kennzeichnung einer Haltbarkeitsgarantie des Herstellers, Lagerorte und Fahrzeuge mit Bestand, der Lieferschein und das Scannen von Material auf der Baustelle. Für die Leute im Betrieb gibt es die Mitarbeiterakte, Urlaub und Krankheit mit den gesetzlichen Feiertagen, das Zeitkonto, die Plantafel und das Kalender-Abo. Entwürfe lassen sich löschen, im Büro und auf der Baustelle.

Noch nicht dabei sind aus Phase 2 die Serviceaufträge, der Notdienst, Wartungsverträge mit Dauerrechnung, die Erinnerungen an Kunden, Leads und die Kommunikationshistorie, die DSGVO-Funktionen, die Hilfe und der Import aus Messgeräten. Ein Update braucht keinen eigenen Schritt, die neuen Migrationen laufen beim Start. Vor dem produktiven Einsatz stehen weiter die fachliche Abnahme der Regelpakete und Grenzwerte (#31) und der Praxistest der E-Rechnung bei einem echten Empfänger (#133).

Hinzugefügt

• Mängel und Reklamationen mit Status und Mängelbericht (#311), nach der Feature-Gliederung v2.61 und den Tafeln aus Version 123 des Canvas: Ein Mangel hängt an einem Auftrag, an einer Anlage oder an beiden, mit Beschreibung, wer ihn gemeldet hat und wann, der Frist des Kunden zur Beseitigung und Fotos, die bei den Dateien des Auftrags oder der Anlage liegen und dem Mangel zugeordnet sind (Migration 0119). Auf der Baustelle entsteht er am Auftrag ohne Netz, im Büro auch als Reklamation an einer Anlage. Jeder Schritt (in Bearbeitung, behoben, abgenommen) ist ein eigener Eintrag mit Person und Uhrzeit; abgenommen ist ein Mangel erst mit Name und Unterschrift des Kunden auf dem Gerät, danach ändert er sich nicht mehr. Die Vorbehalte eines unterschriebenen Abnahmeprotokolls werden von der Datenbank zu Mängeln, eine Zeile je Mangel. Ein Mangel nach der Abnahme zeigt, ob der Tag seiner Meldung in der Gewährleistung liegt. Aus der Frist des Kunden wird die neue Frist „Mangel beseitigen“, und je Auftrag gibt es den Mängelbericht als PDF mit Verlauf, Unterschrift und Fotos. Warum: Bisher standen Mängel nur als Text im Abnahmeprotokoll, ohne Stand, ohne Frist und ohne Nachweis, wann sie beseitigt und abgenommen wurden.

• Abnahmeprotokoll nach § 640 BGB mit Gewährleistungsfrist ab Abnahme (#310), nach der Feature-Gliederung v2.60 und den Tafeln aus Version 121 des Canvas: Die Abnahme ist ein Formular am Auftrag, auf dem Gerät ausgefüllt und vorbelegt aus Kunde und Auftrag, mit dem Ergebnis (abgenommen, mit Vorbehalten, verweigert), den Vorbehalten wegen bekannter Mängel, dem Vorbehalt einer Vertragsstrafe, Bauwerk, VOB/B und Wartung, Foto und den Unterschriften von Auftraggeber und Auftragnehmer; danach ändert es sich nicht mehr. Bauwerk und VOB/B stehen am Auftrag, mit einem Vorschlag nach der Art (Migration 0118). Aus dem letzten unterschriebenen Protokoll wird die neue Frist „Gewährleistung endet“, fünf oder zwei Jahre nach § 634a BGB, vier nach § 13 Abs. 4 VOB/B und bei VOB/B ohne übertragene Wartung zwei für die wartungsbedürftigen Teile, als Regelpaket warranty. Das PDF des Protokolls nennt das Ende der Gewährleistung; die Aufforderung zur Abnahme mit Frist entsteht am Auftrag als Brief, bei einer privaten Kundin mit dem Hinweis nach § 640 Abs. 2 Satz 2 BGB. An der Anlage folgt die Gewährleistung aus der Abnahme, die Herstellergarantie hat ein eigenes Feld. Warum: Mit dem Tag der Abnahme beginnt die Gewährleistung, und bisher hielt OpenGewerk weder den Tag noch die Frist.

• Wallbox und Speicher: Inbetriebnahme, Förderunterlagen und Prüfintervalle (#307), nach der Feature-Gliederung v2.59 und den Tafeln aus Version 120 des Canvas: Eine Wallbox bekommt ihr Inbetriebnahmeprotokoll als Erstprüfung nach DIN VDE 0100-600 mit den Anforderungen der DIN VDE 0100-722, mit RCD je Ladepunkt höchstens 30 mA, Schutz bei Gleichfehlerströmen (RCD Typ B oder Fehlergleichstrom-Überwachung höchstens 6 mA, beides als Regel im Paket Elektro 0.9.0) und der Prüffrist bis zur ersten Wiederholungsprüfung, aus der die Frist an der Anlage wird; der Prüfbericht je Objekt nennt es als Prüfung der Anlage. Ein Speicher bekommt das Inbetriebnahmeprotokoll nach den Angaben des Herstellers neben dem nach VDE-AR-N 4105, das allein hinter der Fertigmeldung an den Netzbetreiber geht. Speicher und Wallbox nennen ihre nutzbare Kapazität und Bemessungsleistung (Migration 0117), und Anmeldung, Fertigmeldung und Ausfüllhilfe drucken sie statt leerer Zeilen. Förderprogramme sind Vorlagen unter „Stammdaten“: die Nachweise eines Programms in seiner Reihenfolge, aus OpenGewerk oder vom Betreiber, und der Text der Fachunternehmererklärung mit Platzhaltern. An einer PV-Anlage, einem Speicher oder einer Wallbox entstehen daraus die Förderunterlagen als ein PDF: die Liste der Nachweise mit dem, was beiliegt, fehlt oder der Betreiber bringt, dahinter Erklärung, Seriennummern, Inbetriebnahmeprotokolle, Fotos und Rechnungen. Neue Rechte „Förderprogramme ansehen“ und „Förderprogramme pflegen“ für Inhaber und Büro. Warum: Nach der Montage einer Wallbox oder eines Speichers fehlten Protokoll, Frist und die Unterlagen für die Förderung, und Förderprogramme wechseln zu oft, um sie in den Code zu schreiben.

• Netzbetreiber, Netzbetreiber-Anmeldung und die Ausfüllhilfe für das Marktstammdatenregister (#306), nach der Feature-Gliederung v2.58 und den Tafeln aus Version 117 des Canvas: Unter „Stammdaten“ pflegen Inhaber und Büro ihre Netzbetreiber mit dem, was sie verlangen, ihrem Portal, einem Ansprechpartner und der Eintragung des Betriebs in ihr Installateurverzeichnis (Nummer, gültig bis, verantwortliche Elektrofachkraft). Vor dem letzten Tag einer Eintragung erinnert die neue Frist „Eintragung im Installateurverzeichnis läuft ab“ (Paket Elektro 0.8.0). Eine PV-Anlage und ein Speicher oder eine Wallbox, die zu keiner PV-Anlage gehören, nennen ihren Netzbetreiber und die Kennung dort (Migration 0116). Daraus entstehen Anmeldung und Fertigmeldung als vorausgefüllte Datenblätter mit der Eintragung des Betriebs als E-Installateur-Nachweis; hinter der Fertigmeldung folgen die unterschriebenen Inbetriebsetzungsprotokolle. Die Ausfüllhilfe nennt jede Frage, die das Register nach der Anlage zur MaStRV an Betreiber, Solareinheit, EEG-Anlage und Speicher stellt, mit der Antwort aus der Anlage oder einer Zeile für den Betreiber, und oben seine Frist von einem Monat nach der Inbetriebnahme (§ 5 Abs. 5 MaStRV, als Regel im Paket). Neue Rechte „Netzbetreiber ansehen“ und „Netzbetreiber pflegen“ für Inhaber und Büro. Warum: Jede PV-Anlage, jeder Speicher und jede Wallbox geht an den Netzbetreiber, und alles, was er und das Register fragen, steht schon in Kunde, Objekt und PV-Struktur.

• Die PV-Anlagendokumentation (#305), nach der Feature-Gliederung v2.57 und den Tafeln aus Version 115 des Canvas: die Prüfung der Gleichstromseite nach DIN EN IEC 62446-1 als Formular, je String aus der PV-Struktur mit Polarität, Leerlaufspannung, Kurzschlussstrom und Isolationswiderstand gegen den Mindestwert von 1 MΩ (Paket Elektro 0.7.0); die Ertragsprognose als Wert mit Quelle an der PV-Anlage (Migration 0115); „Stringplan und Komponentenliste“ als PDF aus der Struktur; und an der PV-Anlage im Büro „Übergeben“, das die Mappe für den Betreiber festhält: Komponenten, Stringplan, Ertragsprognose und die letzten unterschriebenen Protokolle, so wie an diesem Tag, als ein PDF. Eine Übergabe lässt sich weder ändern noch löschen. Warum: Ein Betrieb übergibt jede PV-Anlage mit ihren Unterlagen, und was er übergeben hat, muss er später genau so wieder zeigen können.

• Das Inbetriebsetzungsprotokoll nach VDE-AR-N 4105 (#304), nach der Feature-Gliederung v2.56 und den Tafeln aus Version 113 des Canvas: An einer PV-Anlage oder einem Speicher entsteht es nach Formular F.9 der Fassung 2026-03, vorbelegt aus dem Kunden des Objekts und der PV-Struktur (Anlagenbetreiber mit Anschrift, Wechselrichter, Speicher, Zählernummer, SAmax, PAmax und Modulleistung). Die Begrenzung der Einspeisung auf 60 Prozent ohne intelligentes Messsystem steht als Regel mit Gültigkeit ab dem 25.02.2025 im Paket Elektro 0.6.0 und wird gemessen wie ein Messwert. Anlagenbetreiber und Elektrofachbetrieb unterschreiben auf dem Gerät, der Betrieb zuletzt; dafür nimmt der Schritt „Unterschreiben“ auf der Baustelle jetzt alle Unterschriften eines Formulars auf. Neu in der Formular-Engine des Fundaments ist das Feld „Datum“, hier für den ersten Netzparallelbetrieb, und ein Formular kann sagen, für welche Arten von Anlagen es ist, was es aus der Struktur vorbelegt und dass es keine Prüfung ist: der Prüfbericht je Objekt nennt es nicht. Warum: Jeder PV-Anlage folgt das Protokoll für den Netzbetreiber, und alles, was es fragt, steht schon in Kunde, Objekt und PV-Struktur.

• Die Prüfung der Elektroinstallation als Prüfbericht je Objekt (#302), nach der Feature-Gliederung v2.53 und den Tafeln aus Version 109 des Canvas: Am Objekt im Büro öffnet „Prüfung der Elektroinstallation“ ein PDF, dessen erste Seite das Ergebnis des Ganzen nennt, je Anlage die letzte unterschriebene Prüfung der ganzen Anlage (Wiederholungsprüfung oder Erstp...

OpenGewerk 0.6.5

Eine Korrekturfassung zu 0.6.4. Deren Migration 0095_address_confirmations bestätigte auf einer Instanz keine E-Mail-Adresse, die es schon gab, anders als unter 0.6.4 beschrieben; ein solches Konto ließ sich nicht zum Betreiber benennen und nicht über add-staff oder add-tenant an die Arbeit setzen. Wer 0.6.3 oder älter betreibt, aktualisiert gleich auf 0.6.5.

Aktualisiert wird wie bei jeder Fassung, vorher gesichert. Eine Migration kommt dazu, 0096_confirm_existing_addresses; von 0.6.3 aus laufen 0095 und 0096 zusammen.

Behoben

• Jede E-Mail-Adresse, die es vor 0.6.4 schon gab, gilt jetzt als bestätigt, wie es unter 0.6.4 versprochen war. Die Migration 0096_confirm_existing_addresses holt das nach. Warum: 0095_address_confirmations lief auf einer Instanz als Eigentümer der Tabellen, und der darf auth_users unter FORCE ROW LEVEL SECURITY nur lesen; ihr UPDATE traf keine Zeile, ohne Fehler. Ein Konto blieb so unbestätigt, ließ sich nicht zum Betreiber benennen und nicht über add-staff oder add-tenant an die Arbeit setzen. 0096 bestätigt nur Konten, die es vor 0095 gab: kommen beide Migrationen mit demselben Update, alle; hat eine Instanz 0.6.4 schon, die vor dem Erscheinen von 0.6.4 angelegten. Ein Konto, das seitdem über einen Link mit einer nie erreichten Adresse entstand, bleibt unbestätigt. Zwei Tests migrieren als Eigentümer und prüfen beide Wege.

Installieren und aktualisieren

Das Paket opengewerk-0.6.5.tar.gz enthält den Ordner opengewerk/docker. Zum Installieren entpacken, mit tar --no-same-owner -xzf opengewerk-0.6.5.tar.gz, und im Ordner opengewerk sh docker/start.sh aufrufen. Für ein Update das neue Paket genauso an dieselbe Stelle entpacken, die .env bleibt, und derselbe Befehl. Gebaut wird dabei nichts, geholt werden die Abbilder dieser Fassung, für x86_64 und ARM64:

• ghcr.io/opengewerk/opengewerk:0.6.5 (sha256:475eef1abbe3c48f12c0cfc25b2814bb6e219aefc6b657e2357c0b03233ae349)
• ghcr.io/opengewerk/backup:0.6.5 (sha256:941e2c98c0b0b0ff3112339162d769a30ee28a08fecfe3bcf5fa7c55094a072c)

Dieselben Abbilder liegen mit denselben Digests und Signaturen auch auf Docker Hub, als opengewerk/opengewerk:0.6.5 und opengewerk/backup:0.6.5. Das Paket holt sie trotzdem aus ghcr.io, denn Docker Hub begrenzt anonyme Pulls.

Gebraucht werden Docker und Docker Compose ab 2.22. Beide Abbilder sind ohne Schlüssel über Sigstore signiert. Prüfen:

cosign verify ghcr.io/opengewerk/opengewerk:0.6.5 \
  --certificate-identity https://github.com/opengewerk/opengewerk/.github/workflows/release.yml@refs/tags/v0.6.5 \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

Das Paket ist im selben Lauf genauso signiert. Vor dem Entpacken prüfen, mit opengewerk-0.6.5.tar.gz.sigstore.json daneben:

cosign verify-blob opengewerk-0.6.5.tar.gz \
  --bundle opengewerk-0.6.5.tar.gz.sigstore.json \
  --certificate-identity https://github.com/opengewerk/opengewerk/.github/workflows/release.yml@refs/tags/v0.6.5 \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

OpenGewerk 0.6.4

Bitte gleich auf 0.6.5 aktualisieren. Die Migration 0095_address_confirmations dieser Fassung bestätigt auf einer Instanz keine E-Mail-Adresse, die es schon gibt, anders als unten beschrieben; 0.6.5 holt das mit 0096_confirm_existing_addresses nach.

Diese Fassung enthält eine Sicherheitskorrektur. Was betroffen war, steht im Abschnitt „Sicherheit“ und im Advisory. Wer OpenGewerk betreibt, aktualisiert bitte bald.

Eine Sicherheitsfassung mit dem letzten Punkt aus der Sicherheitsprüfung der Handwerkersoftware vom Oktober 2026: Eine neue E-Mail-Adresse gilt erst, wenn der Link in einer Mail an sie geöffnet ist (#754). Damit ist jeder Befund und jeder Hinweis dieser Prüfung behoben.

Ohne Mailserver der Instanz ändert sich ab dieser Fassung keine E-Mail-Adresse mehr, der Name schon; wer Adressen ändern will, richtet im Bereich der Instanz einen Mailserver ein. Jede Adresse, die es beim Update schon gibt, gilt als bestätigt. Wer ein Konto zum Betreiber benennt oder über add-staff oder add-tenant an die Arbeit setzt, braucht dafür eine bestätigte Adresse.

Aktualisiert wird wie bei jeder Fassung, vorher gesichert. Eine Migration kommt dazu, 0095_address_confirmations.

Sicherheit

• Eine neue E-Mail-Adresse gilt erst, wenn der Link in einer Mail an sie geöffnet ist (#754). Unter „Konto“ und als Berichtigung unter „Zugänge“ wartet sie, an sie geht ein Link, der einen Tag und einmal gilt, und bis dahin gilt die bisherige; „Mail erneut senden“ und „Verwerfen“ stehen daneben. Die Seite des Links bestätigt erst mit einem Knopf. Danach steht die Änderung im Änderungsprotokoll jedes Betriebs des Kontos, ein offener Link für ein neues Passwort endet, und die bisherige Adresse bekommt einen Hinweis. Ohne Mailserver der Instanz ändert sich keine Adresse, der Name schon. Wer die Instanz betreibt, ein Konto über add-staff oder add-tenant an die Arbeit setzt oder es per Link einlädt, findet es nur noch über eine bestätigte Adresse; eine Einladung per Mail bestätigt sie beim Einlösen. Die Migration 0095_address_confirmations bringt die Tabelle auth_address_confirmations und setzt jede Adresse, die es schon gibt, auf bestätigt (Moritz, 30.10.2026). Warum: Eine Adresse kam bisher ohne Nachweis an ein Konto, und spätere Vergaben fanden das Konto genau über sie; wer eine fremde Adresse eintrug, bekam so eine Benennung oder einen Zugang, der einer anderen Person galt (Befund N28 der Sicherheitsprüfung).

Behoben

• „Faktor zurücksetzen“ steht auch in der Liste der Zugänge mit Dialogen (StaffDialogsScreen), die OpenGewerk Haustechnik nutzt, mit derselben Rückfrage wie in StaffScreen. Warum: #762 hatte den Knopf nur in StaffScreen eingebaut; in der Haustechnik setzte den zweiten Faktor eines Zugangs dann nur reset-second-factor auf dem Server zurück, obwohl die Route der Leitung offensteht.
• Der Knopf „Faktor zurücksetzen“ heißt für Bildschirmleser „Faktor zurücksetzen für “, in beiden Listen der Zugänge. Warum: Sein Name war „Zweiten Faktor von zurücksetzen“ und enthielt den sichtbaren Text nicht; wer mit Sprache steuert, sagt, was er sieht, und traf ihn so nicht. Die Prüfung der Breiten in der Haustechnik (axe, label-content-name-mismatch) hat es gezeigt.

Installieren und aktualisieren

Das Paket opengewerk-0.6.4.tar.gz enthält den Ordner opengewerk/docker. Zum Installieren entpacken, mit tar --no-same-owner -xzf opengewerk-0.6.4.tar.gz, und im Ordner opengewerk sh docker/start.sh aufrufen. Für ein Update das neue Paket genauso an dieselbe Stelle entpacken, die .env bleibt, und derselbe Befehl. Gebaut wird dabei nichts, geholt werden die Abbilder dieser Fassung, für x86_64 und ARM64:

• ghcr.io/opengewerk/opengewerk:0.6.4 (sha256:17a45e3a5d4f2c038d28a3528012ec72eb305e30971ba7c54baaebe4900b0e85)
• ghcr.io/opengewerk/backup:0.6.4 (sha256:60d264a7cf9706b838838b2650b05656db06bfc2362ed98f27bc28b5ad19ba97)

Dieselben Abbilder liegen mit denselben Digests und Signaturen auch auf Docker Hub, als opengewerk/opengewerk:0.6.4 und opengewerk/backup:0.6.4. Das Paket holt sie trotzdem aus ghcr.io, denn Docker Hub begrenzt anonyme Pulls.

Gebraucht werden Docker und Docker Compose ab 2.22. Beide Abbilder sind ohne Schlüssel über Sigstore signiert. Prüfen:

cosign verify ghcr.io/opengewerk/opengewerk:0.6.4 \
  --certificate-identity https://github.com/opengewerk/opengewerk/.github/workflows/release.yml@refs/tags/v0.6.4 \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

Das Paket ist im selben Lauf genauso signiert. Vor dem Entpacken prüfen, mit opengewerk-0.6.4.tar.gz.sigstore.json daneben:

cosign verify-blob opengewerk-0.6.4.tar.gz \
  --bundle opengewerk-0.6.4.tar.gz.sigstore.json \
  --certificate-identity https://github.com/opengewerk/opengewerk/.github/workflows/release.yml@refs/tags/v0.6.4 \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

OpenGewerk 0.6.3

Diese Fassung enthält eine Sicherheitskorrektur. Was betroffen war, steht im Abschnitt „Sicherheit“ und im Advisory. Wer OpenGewerk betreibt, aktualisiert bitte bald.

Eine Sicherheitsfassung mit den Korrekturen aus der Sicherheitsprüfung der Handwerkersoftware vom 27. bis 29.10.2026: 16 bestätigte Befunde, keiner kritisch oder hoch, und 29 Hinweise, die behoben oder gehärtet sind. Sie betreffen vor allem Belege, die beim Ausstellen und Stornieren jetzt gesperrt werden, den Abgleich, die Anmeldung mit zweitem Faktor und Grenzen für alles, was sich die Betriebe einer Instanz teilen. Einer, die Bestätigung einer neuen E-Mail-Adresse, steht noch aus (#754).

Das Update meldet einmal jedes Gerät ab, weil die Cookies der Anmeldung jetzt __Host-better-auth.* heißen; danach meldet sich jeder neu an. Wer einen Passkey als zweiten Faktor hat und sich mit dem Passwort anmeldet, richtet daraus keine App mehr ein und ändert nichts an seinen Passkeys, sondern meldet sich dafür mit dem Passkey an. Neu im Bereich der Instanz sind unter „Einstellungen“ die Grenzen eines Betriebs, ab Werk ohne Grenze für den Speicher. Das Installationspaket ist jetzt signiert und lässt sich vor dem Entpacken mit cosign verify-blob prüfen.

Aktualisiert wird wie bei jeder Fassung, vorher gesichert. Sechs Migrationen kommen dazu, 0089_line_waits_for_its_document, 0090_sign_only_a_report, 0091_document_bounds, 0092_audit_value_nonces, 0093_second_factor_changes und 0094_tenant_limits.

Sicherheit

• Im Bereich der Instanz gibt es unter „Einstellungen“ die Karte „Betriebe“: „Speicher je Betrieb“ ist eine Grenze in GB für alles, was ein Betrieb im Dateispeicher ablegt, ab Werk ohne Grenze; „Inhaber dürfen weitere Betriebe anlegen“ ist ab Werk an, und ein Konto legt höchstens fünf eigene Betriebe an. Ein Betrieb an seiner Grenze bekommt beim Hochladen 507 mit einem Satz, alle anderen legen weiter ab. Die Liste der Betriebe zeigt in der neuen Spalte „Belegt“, wie viel jeder belegt. Beide Einstellungen stehen in der Migration 0094_tenant_limits. Warum: Der Dateispeicher ist einer für alle Betriebe der Instanz, und nur die freie Reserve für Datenbank, Drucke und Sicherung begrenzte, was einer behält; der erste Betrieb, der sie erreichte, sperrte das Hochladen für alle anderen. Und jeder Inhaber konnte beliebig viele eigene Betriebe anlegen, die keiner löscht und die jeden Durchgang der Hintergrundläufe und jeden Start der Instanz verlängern.
• Hat ein Konto einen zweiten Faktor, ändert eine Anmeldung ohne ihn nichts mehr daran: eine App einrichten, einen Passkey hinzufügen oder löschen und sich unter „Konto“ bestätigen, etwa für Name und E-Mail, geht nur noch aus einer Sitzung mit dem Passkey oder dem Code aus der App, sonst antwortet der Server mit 403. Das Tor schickt ein solches Konto zur neuen Anmeldung statt zur Einrichtung der App. Wer seinen einzigen zweiten Faktor verloren hat, bekommt ihn vom Inhaber unter „Zugänge“ zurückgesetzt („Faktor zurücksetzen“), ein Konto, das auch in einem anderen Betrieb arbeitet oder die Instanz betreibt, mit reset-second-factor auf dem Server; die App und alle Passkeys gehen, alle Geräte werden abgemeldet, das Passwort bleibt. Das Einrichten einer App und jedes Zurücksetzen stehen als Zeile der neuen Tabelle second_factor_changes (Migration 0093_second_factor_changes) im Änderungsprotokoll jedes Betriebs, in dem der Zugang arbeitet, und das Konto bekommt eine Mail. Warum: Ein Konto, dessen zweiter Faktor ein Passkey ist, meldet sich auch mit dem Passwort allein an, und aus einer solchen Sitzung ließ sich eine App einrichten, deren Sitzung dann jede leitende Rolle und den Bereich der Instanz öffnete, ohne dass der Passkey je vorgezeigt wurde; die Einrichtung der App stand nirgends und meldete sich nicht. Dabei fiel auf, dass die Liste der Zugänge ein Konto, dessen zweiter Faktor ein Passkey ist, nie als „zweiter Faktor eingerichtet“ zeigte: Ihre Abfrage verglich den Passkey mit seiner eigenen Kennung statt mit dem Konto.
• Wer einen Passkey löscht oder neue Wiederherstellungscodes erzeugt, meldet damit alle anderen Geräte des Zugangs ab, wie mit einem neuen Passwort; was sie in einem Mandanten offen hatten, wird geschlossen. Warum: Eine Sitzung hält nicht fest, welcher Passkey oder welcher Code ihr den zweiten Faktor gab, und eine, die mit dem gelöschten Passkey oder einem Code des alten Satzes begann, kam so weiter in jede Rolle, die einen zweiten Faktor verlangt, solange sie benutzt wurde. Die Dialoge unter „Konto“ sagen es dazu.
• Der Cursor eines Abrufs geht nicht mehr über die Nummer hinaus, die der Zähler des Mandanten vor der ersten Tabelle zeigte, und eine Übertragung des Postausgangs trägt höchstens 2000 Vorgänge (413 darüber); der Web-Client teilt seinen Postausgang zusätzlich in Teile von höchstens 1000. Warum: Bestätigte während eines Abrufs eine Transaktion Zeilen in zwei Tabellen, sah der Abruf nur die höhere Nummer, und das Gerät bekam die niedrigere nie; und acht Megabyte der kleinsten Vorgänge waren Zehntausende Zeilen in einer Transaktion, die den Zähler des Mandanten hält.
• Die Cookies der Anmeldung heißen __Host-better-auth.* statt __Secure-better-auth.*. Das Update meldet einmal jedes Gerät ab, danach meldet sich jeder neu an. Warum: Ein Cookie mit __Secure- darf auch eine andere Subdomain derselben Domain setzen, etwa eine Firmenwebsite neben der Instanz, und mit dem Token einer eigenen Sitzung davor gesetzt las die Anmeldung dieses statt des eigenen. Ein Cookie mit __Host- behält der Browser nur für genau den Host, der es gesetzt hat.
• Ein Beleg wird beim Ausstellen, beim Stornieren und beim Schreiben seiner Positionen gesperrt. Das Ausstellen liest den Beleg mit einer Zeilensperre, bevor es festhält, was in den Schnappschuss kommt, und die Vorgänger, die es abzieht, mit einer geteilten Sperre; das Stornieren sperrt die Rechnung vor seinen Prüfungen; die Routen der Positionen sperren den Entwurf wie der Abgleich seit #582, und der Trigger an den Positionen wartet mit der Migration 0089_line_waits_for_its_document auf eine Transaktion, die den Beleg gerade ausstellt oder unterschreibt. Warum: Eine Position, die im selben Moment geschrieben wurde, kam in den Beleg, aber nicht in seinen Schnappschuss, und ein Storno konnte eine Rechnung treffen, auf die gerade eine Zahlung oder eine abziehende Folgerechnung kam. Beides widerspricht der Festschreibung, die die GoBD verlangen.
• Ein Anhang, den das Gerät hält, öffnet nur noch als Bild oder PDF in einem neuen Fenster; jede andere Datei wird unter ihrem Namen gespeichert, wie der Server sie ausgibt (shownInPlace, jetzt im Fundament der Domäne). Eine Vorschau, die kein Bild ist, wird weder behalten noch gezeigt. Warum: Geöffnet wurde jede Datei vom Gerät als blob-Seite im Ursprung der Anwendung, unter dem Typ, den ein Browser beim Hochladen angab, eine XML-Datei eingeschlossen, und über eine Version, die eine andere Datei des Mandanten als Vorschau nennt, kam so eine auch auf die Geräte anderer.
• Die Leser für Tabellen im Fundament gehen ihre Eingabe einmal durch: CSV wird Wert für Wert gelesen (readCsv), sodass die Grenzen beim Lesen gelten; Formate einer Arbeitsmappe, ihre Attribute und Deklarationen werden ohne Muster gelesen, die von jeder Stelle aus neu probierten; ein geteilter Text wird einmal zum Text einer Zelle statt für jede Zelle, die auf ihn zeigt. Der CSV-Export setzt auch Werte mit Komma oder Tabulator in Anführungszeichen. Warum: Eine hochgeladene Tabelle konnte den gemeinsamen Prozess mit dem Quadrat ihrer Größe beschäftigen oder ein Vielfaches ihrer Größe in den Speicher legen, und ein Programm, das das Komma oder den Tabulator für das Trennzeichen hält, begann mitten in einem exportierten Wert eine Zelle, vor der kein Apostroph mehr stand.
• Die Anmeldung reicht nur noch Pfade an better-auth weiter, für die es eine Route gibt; jeder andere unter /api/auth bekommt vorher eine 404, auch die beiden Routen mit einem Wert im Pfad, die hier niemand braucht. Die Route für das Logo liest ihren Body selbst, nach den Guards und ohne ihn zu entpacken, statt eines Parsers davor. Warum: Die Ratengrenzen von better-auth legten für jeden ausgedachten Pfad eine Zeile in der Datenbank an, von jedem und ohne Sitzung, und der Parser vor dem Logo las und entpackte den Body jeder Anfrage mit einem Bildtyp, bevor gefragt war, wer sie schickt.
• Die Sperre nach zehn falschen Codes bei der Anmeldung zählt jeden Versuch, bevor der Code geprüft wird, und der zehnte setzt sie im selben Schritt; das gilt für den Code aus der App und für Wiederherstellungscodes. Die Sperre von better-auth ist dafür abgeschaltet. Warum: better-auth sah vor dem Code nach, ob das Konto gesperrt ist, und zählte erst danach, sodass gleichzeitig geschickte Versuche alle bis zum Code kamen; im Test waren es 25 von 25 statt 10.
• Drei Wege gehen in einem Durchgang statt mit dem Quadrat ihrer Eingabe: der DATANORM-Leser findet die gefüllten Zeilen ohne ein Muster, das eine lange Zeile aus Leerzeichen von jeder Stelle aus neu probierte; der Stromkreisplan gruppiert Abschnitte und Stromkreise einmal, statt sie für jeden Verteiler und Abschnitt neu zu filtern; der Abruf eines Geräts fragt je Zeile über einen Index, ob die Person sie angelegt hat, statt die Liste all ihrer Einträge zu durchsuchen. Warum: Alle drei laufen im gemeinsamen Prozess oder auf dem gemeinsamen Pool, und eine Eingabe eines Mandanten hielt so die Anfragen aller anderen über Sekunden bis Minuten auf.
• Das Installationspaket ist ab dieser Fassung signiert wie die Abbilder, ohne Schlüssel über Sigstore, und die Release-Seite trägt die Datei opengewerk-<fassung>.tar.gz.sigstore.json und den Befehl cosign verify-blob dazu. Warum: Das Paket legt fest, welche Abbilder der Start prüft und gegen welchen Workflow, und seine Skripte laufen mit den Rechten von Docker; die Prüfsumme daneben stammt ...

OpenGewerk 0.6.2

Diese Fassung enthält eine Sicherheitskorrektur. Was betroffen war, steht im Abschnitt „Sicherheit“ und im Advisory. Wer OpenGewerk betreibt, aktualisiert bitte bald.

Eine Sicherheitsfassung. Das Abbild baut auf Node 24.22.1, und der Renderer für PDFs läuft auf 2.57.3, das dieselbe Fassung von Node mitbringt; beide schließen damit die Lücken aus dem Sicherheitsrelease von Node vom 21.10.2026, darunter CVE-2026-111497. Dazu kommen die Bausteine, die das Fundament seit 0.6.1 für OpenGewerk Haustechnik bekam: Routen, die nur ein Mitglied verlangen, ein Schlüssel der Instanz zum Signieren von PDFs und Buchungen im Lager ohne die Person, die gebucht hat. In der Handwerkersoftware zu sehen ist davon nur, dass die Karte eines Etiketts das PDF herunterlädt.

Aktualisiert wird wie bei jeder Fassung, vorher gesichert. Eine Migration kommt dazu, 0088_instance_signing, mit den Spalten für den Schlüssel der Instanz.

Hinzugefügt

• Eine Route kann sagen, dass sie nur ein Mitglied des Mandanten verlangt und kein Recht (RequiresMembership): der Guard stellt fest, wer fragt, im Mandanten der Sitzung, und reicht die Identität mit dem Grund membership weiter; der Gang über die Routen zählt sie als eigene Art (needsMembershipOnly). Warum: OpenGewerk Haustechnik zeigt die eigenen Qualifikationen und die eigene Pflichtenübertragung einer Person ohne ein Recht, weil es ihre eigenen Daten sind (OpenGewerk/opengewerk-haustechnik#543).
• Die Instanz hat einen Schlüssel zum Signieren von PDFs, mit einem Zertifikat, das sie sich selbst ausstellt, und das Fundament eine CMS-Signatur, wie PAdES sie in ein PDF setzt (signDetached, instanceSigningKey). Der Schlüssel entsteht mit dem ersten signierten PDF oder in den Einstellungen der Instanz, versiegelt in instance_settings, und das Protokoll der Instanz hält ihn nie; ein früheres Zertifikat bleibt bekannt. Warum: OpenGewerk Haustechnik signiert jedes PDF mit einer Unterschrift darin, damit eine spätere Änderung in jedem PDF-Programm auffällt (OpenGewerk/opengewerk-haustechnik#457). Die Handwerkersoftware signiert noch nichts und zeigt die Karte "Signatur der PDFs" deshalb nicht; sie bekommt die Spalten mit der Migration 0088_instance_signing.

Geändert

• Die Karte eines Etiketts lädt das PDF herunter, unter dem Namen "Etikett" mit dem gedruckten Code, statt es in einem Tab zu öffnen; der Knopf heißt "PDF herunterladen". Warum: in einem Tab ohne die Leiste eines PDF-Programms, etwa in der installierten Anwendung, ließ sich das Etikett ansehen, aber nicht speichern (OpenGewerk/opengewerk-haustechnik#509).
• Eine Buchung im Lager darf ohne die Person stehen, die gebucht hat (stock_movements.booked_by nimmt null). Warum: OpenGewerk Haustechnik lässt die Person nach drei Jahren gehen und behält die Buchung (OpenGewerk/opengewerk-haustechnik#412). Die Handwerkersoftware legt die Tabelle nicht an.
• Das Security-Review steht auf 731e352 von opengewerk/.github (OpenGewerk/.github#45), dem Stand, der ein angehobenes Submodul selbst belegt, wie in den übrigen Repositories der Organisation.

Sicherheit

• Das Abbild baut auf node:24-alpine mit Node 24.22.1 statt 24.22.0, und der Renderer für PDFs läuft auf browserless/chromium 2.57.3 statt 2.57.1, das ebenfalls Node 24.22.1 mitbringt. Warum: Node 24.22.1 schließt die Lücken aus dem Sicherheitsrelease vom 21.10.2026, darunter CVE-2026-111497 (der Brotli-Decoder schreibt außerhalb seines Puffers, was fremden Code ausführen lässt).

Installieren und aktualisieren

Das Paket opengewerk-0.6.2.tar.gz enthält den Ordner opengewerk/docker. Zum Installieren entpacken, mit tar --no-same-owner -xzf opengewerk-0.6.2.tar.gz, und im Ordner opengewerk sh docker/start.sh aufrufen. Für ein Update das neue Paket genauso an dieselbe Stelle entpacken, die .env bleibt, und derselbe Befehl. Gebaut wird dabei nichts, geholt werden die Abbilder dieser Fassung, für x86_64 und ARM64:

• ghcr.io/opengewerk/opengewerk:0.6.2 (sha256:56f2002edc53eecb769d5037de41161be4f10134c5b90d77af7a365d5046f903)
• ghcr.io/opengewerk/backup:0.6.2 (sha256:524b6ba82044b3ed48f5099237db92972f18476fdb69576f46a08674224265bd)

Dieselben Abbilder liegen mit denselben Digests und Signaturen auch auf Docker Hub, als opengewerk/opengewerk:0.6.2 und opengewerk/backup:0.6.2. Das Paket holt sie trotzdem aus ghcr.io, denn Docker Hub begrenzt anonyme Pulls.

Gebraucht werden Docker und Docker Compose ab 2.22. Beide Abbilder sind ohne Schlüssel über Sigstore signiert. Prüfen:

cosign verify ghcr.io/opengewerk/opengewerk:0.6.2 \
  --certificate-identity https://github.com/opengewerk/opengewerk/.github/workflows/release.yml@refs/tags/v0.6.2 \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

OpenGewerk 0.6.1

Diese Fassung enthält eine Sicherheitskorrektur. Was betroffen war, steht im Abschnitt „Sicherheit“ und im Advisory. Wer OpenGewerk betreibt, aktualisiert bitte bald.

Eine Sicherheitsfassung. Teil 2 der Prüfung vor der nächsten Fassung von OpenGewerk Haustechnik hat im gemeinsamen Fundament vier Wege gefunden, auf denen eine offene Sitzung mehr konnte, als die Bestätigung mit Passwort und Code erlauben soll: den zweiten Faktor lesen, abschalten oder mit neuen Codes umgehen, die Betreiber der Instanz ändern, den Namen eines Zugangs ohne Spur ändern und das gespeicherte Passwort eines Mailservers ohne Verschlüsselung hinausschicken. Alle vier sind geschlossen, die Advisories erscheinen mit dieser Fassung. Dazu kommen Vite 8.3.3 und der Renderer 2.57.1.

Aktualisiert wird wie bei jeder Fassung, vorher gesichert; eine Migration gibt es nicht. Danach fragt „Konto“ für neue Wiederherstellungscodes nach Passwort und Code, der Bereich der Instanz fragt vor dem Benennen oder Entfernen eines Betreibers und vor einem Betrieb für jemand anderen nach der Bestätigung, und wer bei einem Mailserver ohne Verschlüsselung den Port ändert, gibt das Passwort neu ein.

Geändert

• Der Renderer für PDFs läuft auf browserless/chromium 2.57.1, im Stapel, im Job der E-Rechnung und im Befehl für die Entwicklung mit demselben Digest. Die Fassung bringt Node 24.22 und schließt eine Verbindung über WebSocket nach einer Zeitüberschreitung sauber; der Job prüft, dass er denselben Renderer nutzt wie der Betrieb, deshalb ziehen alle drei Stellen gemeinsam nach.

Behoben

• Die Prüfung der Breiten wartet nach dem Laden einer Seite höchstens zehn Sekunden auf ein ruhiges Netz und misst ohne Service Worker. Sie war gelegentlich rot an einer Seite, die niemand angefasst hatte, weil das Vorladen der Anwendung oder die Suche nach einer neuen Fassung das Netz länger als 30 Sekunden beschäftigte (OpenGewerk/opengewerk-haustechnik#492); ob eine Seite steht, entscheidet weiter, ob ihr Inhalt gezeichnet ist.

Sicherheit

• Teil 2 der Sicherheitsprüfung für OpenGewerk Haustechnik (OpenGewerk/opengewerk-haustechnik#360) fand vier Wege, auf denen eine offene Sitzung mehr konnte, als die Bestätigung mit Passwort und Code erlauben soll. Alle vier sind geschlossen:
  • Das Geheimnis der Authenticator-App lesen und die App abschalten ging mit Sitzung und Passwort; beide Routen von better-auth sind abgeschaltet. Neue Wiederherstellungscodes gibt es nur nach Passwort und Code, nicht am ersten Tag nach einem neuen Passwort, und der Zugang bekommt eine E-Mail darüber. Unter „Konto“ fragt das Formular dafür nach beidem.
  • Benennen und Entfernen eines Betreibers und ein Betrieb mit Einladung für jemand anderen verlangen dieselbe Bestätigung wie der Mailserver der Instanz, denn wer Betreiber wird, kann diesen danach ändern. Jede Änderung an den Betreibern geht per E-Mail an alle Betreiber und an den entfernten.
  • /update-user von better-auth änderte den Namen eines Zugangs ohne Bestätigung und ohne Eintrag im Protokoll. Abgeschaltet ist jetzt jede Route von better-auth, die die Oberfläche nicht nutzt, und ein Test hält die Liste der übrigen.
  • Das gespeicherte Passwort eines Mailservers ging bei gleichem Server und Benutzer auch an einen anderen Port ohne Verschlüsselung, über eine Prüfung ohne Bestätigung. Ohne TLS geht es jetzt nur noch über genau die gespeicherte Verbindung, mit TLS weiter an jeden Port desselben Servers.
• Vite 8.3.3 in beiden Oberflächen, mit der Sperrdatei. Die Fassung bringt launch-editor 2.14.2, das unter Windows % in Argumenten nicht maskierte (Dependabot-Alerts 1 und 2); betroffen war nur der Server für die Entwicklung, nicht das gebaute Paket.

Installieren und aktualisieren

Das Paket opengewerk-0.6.1.tar.gz enthält den Ordner opengewerk/docker. Zum Installieren entpacken, mit tar --no-same-owner -xzf opengewerk-0.6.1.tar.gz, und im Ordner opengewerk sh docker/start.sh aufrufen. Für ein Update das neue Paket genauso an dieselbe Stelle entpacken, die .env bleibt, und derselbe Befehl. Gebaut wird dabei nichts, geholt werden die Abbilder dieser Fassung, für x86_64 und ARM64:

• ghcr.io/opengewerk/opengewerk:0.6.1 (sha256:125b44a3a8b13d9aab6c6cbbc99386a31bb436b8e640ecb32967e9ceee26d31f)
• ghcr.io/opengewerk/backup:0.6.1 (sha256:275285344209d79e01e595f0d5c7ac8a1e9d051805e2275545fb8a474c29956b)

Dieselben Abbilder liegen mit denselben Digests und Signaturen auch auf Docker Hub, als opengewerk/opengewerk:0.6.1 und opengewerk/backup:0.6.1. Das Paket holt sie trotzdem aus ghcr.io, denn Docker Hub begrenzt anonyme Pulls.

Gebraucht werden Docker und Docker Compose ab 2.22. Beide Abbilder sind ohne Schlüssel über Sigstore signiert. Prüfen:

cosign verify ghcr.io/opengewerk/opengewerk:0.6.1 \
  --certificate-identity https://github.com/opengewerk/opengewerk/.github/workflows/release.yml@refs/tags/v0.6.1 \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

OpenGewerk 0.6.0

Diese Fassung enthält eine Sicherheitskorrektur. Was betroffen war, steht im Abschnitt „Sicherheit“ und im Advisory. Wer OpenGewerk betreibt, aktualisiert bitte bald.

Die sechste Fassung schließt acht Sicherheitslücken, die eine Prüfung vor der nächsten Fassung von OpenGewerk Haustechnik im gemeinsamen Fundament gefunden hat; die Advisories erscheinen mit ihr. Am schwersten wog, dass die Anmeldung den Körper einer Anfrage ohne Grenze las, bevor irgendetwas geprüft war. Dazu kommen der zweite Faktor an der Sitzung statt am Konto, eine Grenze für das Ablegen von Dateien, kein HTTP-Cache für Antworten der Anwendung, Grenzen nach der Adresse hinter dem Reverse Proxy, Konflikte des Abgleichs, die Gerät und Person gehören, und eine Sicherung, die nur fertig und verschlüsselt auf das Ziel kommt und nur eigene Archive zurückspielt. Die Dienste laufen gehärtet, der Renderer in einem eigenen Netz, und das Paket nennt jedes Abbild mit Digest und prüft seine Signatur vor dem Start.

Das meiste, was seit 0.5.0 sonst dazukam, sind Bausteine des Fundaments für OpenGewerk Haustechnik. In der Handwerkersoftware zeigt das Änderungsprotokoll geänderte Werte, ein Ansprechpartner hat eine zweite Nummer, und eine neue Fassung wird von selbst übernommen.

Aktualisiert wird wie bei jeder Fassung, vorher gesichert; die Migrationen 0069_contacts_kept bis 0087_purge_attachments laufen von selbst. Danach:

• Wer die Instanz betreibt, trägt unter „Instanz verwalten“, „Einstellungen“ den Mailserver der Instanz ein. Über ihn gehen jetzt der Link zu einem neuen Passwort und der Hinweis auf einen neuen Passkey, und bis er eingetragen ist, geht keines von beiden hinaus.
• Wer nur mit dem Passwort auf einem Konto mit Authenticator-App angemeldet war, meldet sich neu an.
• Sicherungen von vor dem Update spielt restore.sh nur mit --skip-origin-check zurück. Wer verschlüsselt sichert, löscht auf dem Ziel jedes Archiv .tar.gz ohne Gegenstück .age.

Hinzugefügt

• Eine Anwendung, die ihre Fristen an Orten hält, die nicht jeder sieht, sagt dem Fundament, wer eine Frist dort bekommen darf (MayAnswer, im Lauf der Fristen und in den Regeln der Liste, OpenGewerk/opengewerk-haustechnik#473). Die Erinnerung geht dann an die erste Person in der gewohnten Reihenfolge, die das darf, die Leitung eingeschlossen, und an niemanden, wo es niemand darf; die Liste nennt dieselbe Person, und als Person einer Frist lehnt die Route jemanden ab, der den Ort nicht sieht. Ohne die Frage bleibt alles, wie es war. Warum: die Erinnerung ging nach der Mitgliedschaft und nannte einer Person ohne den Bereich Art, Tag und Kennung der Frist, gefunden in der Sicherheitsprüfung der Haustechnik.

• Ein Dokument und seine Dateien lassen sich nach Ablauf einer Aufbewahrung endgültig löschen (#658), auf dem einen Weg, den eine Anwendung dafür öffnet: purge_attachment(dokument, titel) löscht die Fassungen, lässt das Dokument als gelöschte Hülle mit dem gegebenen Titel stehen, damit ein Gerät davon erfährt. Die Zeile jeder Datei in files, auf die danach kein Schlüssel mehr zeigt, nimmt ein Trigger der Fassung mit, samt dem Eintrag, wer sie abgelegt hat; die Anwendung selbst darf in files nicht löschen, eine Datei geht nur mit der Fassung, die sie nennt. Wann, entscheidet die Anwendung mit application_attachment_may_go; ohne sie geht nichts, und die Riegel lehnen jedes andere Löschen einer Fassung oder einer Datei ab, auch für den Eigentümer der Tabellen. Das Änderungsprotokoll schreibt dabei nichts ab. Diese Anwendung öffnet den Weg nicht; Migration 0087_purge_attachments. Warum: die Haustechnik markierte ein Dokument nach Ablauf der Aufbewahrung nur als entfernt, und Titel, Dateinamen und Dateien blieben.

• Der Dateispeicher räumt sich auf (#657): einmal am Tag nimmt ein Lauf die Bytes jeder Datei heraus, die kein Betrieb mehr hält und die älter als ein Tag ist, dazu liegengebliebene Reste abgebrochener Schreibvorgänge. Welche Namen noch gehalten werden, beantwortet files_held mit den Rechten des Eigentümers (Migration 0086_file_sweep, Policy readable_by_the_owner an files); ein erneutes Ablegen derselben Bytes macht eine Datei wieder neu, und eine Datei wird vor dem Löschen beiseitegelegt, damit ein gleichzeitiges Ablegen sie nicht verliert. Warum: mit dem Löschen nach Ablauf einer Aufbewahrung verschwinden Zeilen, und die Bytes blieben sonst für immer auf der Platte.

• Vorlagen für den Reverse Proxy unter docker/proxy/, apache.conf für Apache 2.4 und nginx.conf für nginx, jede für sich vollständig: die Weiterleitung von HTTP auf HTTPS, das Zertifikat unter dem Pfad, den certbot anlegt, der Proxy auf 127.0.0.1:23700 mit Host, Protokoll und ergänztem X-Forwarded-For, die Grenzen je Pfad und 300 Sekunden für lange Drucke, ohne Sicherheits-Header. Jede Zeile, die zur eigenen Instanz passen muss, trägt einen Kommentar. Die Vorlagen liegen auch im Installationspaket, die CI prüft beide mit nginx -t und httpd -t in der ältesten Fassung, die eine noch unterstützte Distribution mitbringt, und in der neuesten (docker/test-proxy.sh), und das README hat dazu den Abschnitt „Reverse Proxy“. Die Zeilen für Apache, die bisher dort standen, begrenzten nichts: Apache wendet LimitRequestBody auf eine Anfrage, die es mit ProxyPass weiterreicht, nicht an. Die Vorlage vergleicht deshalb die Länge, die eine Anfrage angibt, mit mod_rewrite. Warum: wer installiert, musste sich den vHost bisher aus einzelnen Zeilen im README zusammensetzen.

• Ein Weg in die Ansicht für unterwegs im Kontomenü des Büros (für opengewerk-haustechnik#464): unter einem Strich zwischen „Instanz verwalten“ und „Abmelden“ steht der Satz entry.goTo.site der Anwendung mit einem Telefon und der Zeile „Große Knöpfe, auch ohne Netz“, auch im Bereich der Instanz; in der Handwerkersoftware heißt er „Zur Baustellenansicht“. Er merkt sich die Wahl wie der Weg ins Büro im Menü vor Ort und öffnet /m/, danach führt / auf diesem Gerät in die Ansicht für unterwegs, bis dort wieder das Büro gewählt wird. Warum: vor Ort gab es einen Weg ins Büro, im Büro keinen zurück; wer am Schreibtisch oder auf einem Tablet in der Desktop-Ansicht wechseln wollte, hatte nur die Leiste mit dem Vorschlag, die nicht immer erscheint, oder musste /m von Hand eingeben.

• Eine zweite Nummer am Ansprechpartner, „Mobil“ (für opengewerk-haustechnik#428): contactsSchema hat die Spalte mobile, contactTextFields das Feld zwischen Telefon und E-Mail, und Formular, Karte im Büro, die Zeile je Person und die Liste vor Ort zeigen sie wie die erste Nummer, zum Antippen. Vor Ort steht die erste Nummer jetzt mit einem Hörer, die mobile mit einem Telefon in der Hand. Die Handwerkersoftware bekommt die Spalte mit der Migration 0080_contact_mobile, ihr Abgleich nennt sie „Mobil“, und die Vorschau eines Kunden zeigt beide Nummern. Warum: viele Ansprechpartner haben Festnetz mit Durchwahl und ein Mobiltelefon, und bisher blieb die zweite Nummer in der Funktion oder ging verloren; Moritz hat am 18.10.2026 das eigene Feld entschieden.

• Maßnahmen der Instanz (für opengewerk-haustechnik#358): Teil B der technischen und organisatorischen Maßnahmen (B.1 bis B.9 der Vorlage zur Auftragsverarbeitung auf opengewerk.de) und die Unterauftragsverarbeiter pflegt, wer die Instanz betreibt, auf einem eigenen Bildschirm ihres Bereichs (InstanceMeasuresScreen, GET und PUT instance/measures), mit einem Speichern für alles. Gehalten in zwei Spalten der Einstellungen der Instanz (measures, subprocessors), deren Änderungen wie jede andere im Protokoll der Instanz stehen; eine Anwendung liest sie mit readMeasures für die Dokumente eines Mandanten, ohne den Namen dessen, der sie geändert hat. Die Handwerkersoftware bekommt die Spalten mit der Migration 0079_instance_measures; ihren Bildschirm bindet sie erst mit einer Tafel. Warum: die Haustechnik erzeugt die Maßnahmen eines Betreibers als Anlage 1 zum Vertrag zur Auftragsverarbeitung, und was beim Betrieb der Instanz sichergestellt ist, weiß nur, wer sie betreibt.

• Ein Foto zu einem Punkt auch aus der Galerie (für die Rundgänge der Haustechnik): PhotoTaker hat neben „Foto aufnehmen“, das die Kamera sofort öffnet, einen zweiten Knopf „Aus der Galerie“ ohne capture. Mit multiple hält ein Punkt mehrere Fotos: ein weiteres kommt dazu statt das vorige zu ersetzen, und aus der Galerie lassen sich mehrere auf einmal wählen. Warum: mit capture öffnete das Telefon nur die Kamera, ein Foto, das schon gemacht war, ließ sich nicht hinzufügen. Auf dem Telefon stehen die beiden Knöpfe untereinander, weil nebeneinander jede Beschriftung in zwei Zeilen umbrach; wo beide Platz haben, wie im Büro, stehen sie nebeneinander. Mit compact (für opengewerk-haustechnik#451) sind es zwei kurze Knöpfe „Foto“ und „Galerie“ nebeneinander unter den Fotos, für einen Punkt unter vielen in einer Liste, wo zwei Knöpfe über die ganze Breite an jedem Punkt die Liste doppelt so lang machten. Mit accept (für opengewerk-haustechnik#458) bieten Kamera und Galerie nur die genannten Dateiarten an, weil eine Seite ohne Anmeldung nur JPEG, PNG und WebP annimmt und ein anderes Bild aus der Galerie erst beim Senden abgelehnt würde.

• Einen Wert im Änderungsprotokoll schwärzen (für opengewerk-haustechnik#355, ADR 0013): wer den Mandanten führt, leert den Wert davor oder danach eines Eintrags mit einem Grund (POST audit/entries/:id/redactions, Tabelle audit_redactions, Migration 0078). Die Kette bleibt ganz: neue Einträge (Fassung 2) rechnen ihren Fingerabdruck über einen Fingerabdruck je Wert, der beim Schwärzen bleibt, und für einen Eintrag von vorher hält die Schwärzung einen Zeugen des ganzen Eintrags fest; kein bestehender Eintrag wird umgeschrieben. Liste und Tabelle zeigen „geschwärzt“ mit Zeitpunkt, Person und Grund, das Protokoll des Büros bietet „Schwärzen“ mit einer Rückfrage an, und die Schwärzung selbst steht im P...

OpenGewerk 0.5.0

Diese Fassung enthält eine Sicherheitskorrektur. Was betroffen war, steht im Abschnitt „Sicherheit“ und im Advisory. Wer OpenGewerk betreibt, aktualisiert bitte bald.

Die fünfte Fassung bringt, was von Phase 2 gebaut ist, das Fundament in eigenen Paketen und die Korrekturen aus einer Prüfung dieses Fundaments, darunter vier Sicherheitskorrekturen für 0.1.0 bis 0.4.0.

Aus Phase 2 kommen Fristen, die von selbst entstehen, mit der Wiedervorlage eines Angebots als erster Art, Push-Nachrichten auf die Geräte, das Änderungsprotokoll im Büro, Passkeys, Tags an Kunden und Objekten, der Zugang zum Objekt, die PV-Struktur mit dem Scanner für Seriennummern, das QR-Etikett je Anlage und Artikel und Lieferanten mit der Preiseinheit des Großhandels. Eine Instanz trägt jetzt mehrere Betriebe, mit einem Wechsel ohne neue Anmeldung und einem eigenen Bereich für ihre Betreiber. Der Import aus DATANORM 4 ist auf dem Server gebaut und hat noch keinen Bildschirm (#297).

Mandantentrennung, Anmeldung, Rechte, Abgleich, Änderungsprotokoll, Fristen, Formulare und der Betrieb liegen jetzt unter packages/platform/ in eigenen Paketen (ADR 0010), damit OpenGewerk Haustechnik auf demselben Code steht und eine Korrektur dort jede Anwendung erreicht. Was eine Rolle darf, steht seitdem in Zeilen des Betriebs und nicht mehr im Code; für Inhaber, Büro und Monteur bleibt es dasselbe.

Die Sicherheitskorrekturen betreffen die Konfliktliste des Abgleichs, ein Gerät, an dem sich nacheinander zwei Personen anmelden, das Hochladen einer Datei und das Passwort des Mailservers, beschrieben unter "Sicherheit" mit ihren Advisories.

Wer 0.4.0 betreibt, aktualisiert mit dem Paket dieser Fassung: die Migrationen 0049 bis 0068 laufen dabei von selbst, docker/setup.sh trägt den Schlüssel für Push in die .env ein, und wer die Instanz eingerichtet hat, ist ihr Betreiber. Auf einem Gerät, das sich mehrere Personen teilen, sendet vorher jede, was dort noch wartet: ein Vorgang von vor dem Update nennt niemanden und geht an die erste Person, die sich danach anmeldet.

Phase 2 ist damit nicht abgeschlossen; was fehlt, steht in ihrem Meilenstein. Wie bei den Fassungen davor fehlen vor dem produktiven Einsatz die fachliche Abnahme der Regelpakete und der Grenzwerte des Prüfprotokolls (#31) und der Praxistest der E-Rechnung (#133).

Hinzugefügt

• Die Fristen-Engine (#283), an der die meisten Issues von Phase 2 hängen: Eine Frist entsteht von selbst aus ihrer Quelle, erinnert zu ihrem Vorlauf und folgt der Quelle, wenn die sich ändert, damit niemand eine Wartung, eine Prüfung oder ein offenes Angebot im Kopf behalten muss. Die erste Art ist die Wiedervorlage eines Angebots, das festgeschrieben ist und auf das noch kein Beleg folgt: nach 14 Tagen bekommt, wer es festgeschrieben hat, die Aufgabe "Angebot … nachfassen", und folgt eine Auftragsbestätigung oder Rechnung, entfällt die Frist. Im Büro stehen unter "Fristen" alle nach Fälligkeit, mit eigenem Vorlauf und eigener Person je Frist; unter "Einstellungen", "Fristen" setzt der Betrieb Intervall, Vorlauf und Person je Art (Rechte deadline.read und deadline.write, Migration 0049). Die Arten sind Daten, damit die Pakete der Gewerke eigene mitbringen. Von ihren vier Aktionen, Aufgabe, E-Mail, Serviceauftrag und Statuswechsel, führt die Engine jede genau einmal aus, in derselben Transaktion wie die Markierung als erinnert, und erinnert ab sechs Uhr morgens, wie bei einer fälligen Aufgabe.
• Push-Nachrichten auf die Geräte der Leute im Betrieb (#284), damit eine fällige Aufgabe oder eine Frist auch dann ankommt, wenn OpenGewerk gerade nicht offen ist. Unter "Konto" im Büro und im Menü der Baustelle schaltet jede Person Push auf ihrem Gerät ein, wählt die Anlässe für alle ihre Geräte und schickt sich eine Probenachricht. Push ist ein zweiter Kanal im Weg der Benachrichtigungen: dieselben Anlässe, dieselbe Entscheidung, wem etwas gesagt wird, und eine Nachricht, die nur sagt, was ansteht, ohne Namen und Anschriften. Verschlüsselt nach RFC 8291 und signiert nach RFC 8292 ohne zusätzliches Paket, mit dem Schlüssel aus VAPID_PRIVATE_KEY, den docker/setup.sh beim nächsten Start selbst anlegt. Ein Abonnement hängt an der Sitzung des Geräts: abgemeldet, auch von einem anderen Gerät aus oder durch ein neues Passwort, bekommt es nichts mehr. Die Adresse des Push-Dienstes muss im Internet liegen. Die Aktion mail der Fristenarten heißt dafür reminder, Erinnerung per E-Mail und Push, wie im Konzept. Migration 0050, neues Recht push.write für alle Rollen.
• Das Änderungsprotokoll im Büro (#285), damit der Inhaber sieht, wer wann was geändert hat, ohne an die Datenbank zu gehen. Unter "Einstellungen", "Änderungsprotokoll" stehen die Änderungen des Betriebs, die neuesten zuerst und 50 je Abruf, mit Person, Gerät und Weg, gefiltert nach Zeitraum, Person und Art des Datensatzes; eine Änderung öffnet sich mit ihren Feldern vorher und nachher, in deutschen Namen und lesbaren Werten statt Spaltennamen und Schlüsseln. An Kunde, Objekt, Anlage, Auftrag und Beleg führt der Knopf "Änderungen" zum Protokoll dieses Datensatzes und seiner Teile, am Kunden also mit den Ansprechpartnern und am Beleg mit den Positionen. "Protokoll prüfen" rechnet die Hashkette nach und sagt in einem Satz, ob sie vollständig und unverändert ist oder ab welchem Eintrag nicht; die Prüfung vergleicht dafür auch den Kopf der Kette, damit am Ende entfernte Einträge auffallen. Neues Recht audit.read, nur für den Inhaber, weil das Protokoll alte Werte zeigt; das Lesen selbst wird nicht protokolliert. Keine Migration.
• Ein Bereich für die Betreiber der Instanz (#188), weil zwei Einstellungen keinem Betrieb gehören: auf einer Instanz mit mehreren Betrieben entschiede sonst jeder Inhaber über alle. Wer die Instanz betreibt, erreicht ihn unter dem Namen über "Instanz verwalten", nur mit zweitem Faktor, und findet dort die Betriebe der Instanz, die Mailserver im eigenen Netz, die ein Betrieb benutzen darf, die Uhrzeit der nächtlichen Sicherung, die Betreiber und ein eigenes Protokoll jeder Änderung. Aus einem Betrieb sieht der Bereich nur Namen, Tag der Anlage, Inhaber und die Zahl der Zugänge. Betreiber ist das Konto der Ersteinrichtung; auf einer Instanz, die schon läuft, findet Migration 0051 dieses Konto im Protokoll des ersten Betriebs, und appoint-operator benennt einen weiteren von der Kommandozeile. Ein Inhaber erreicht den Bereich nicht, nur weil er Inhaber ist.
• Weitere Betriebe auf einer Instanz (#142): Ein Inhaber legt unter "Konto", "Betriebe" einen weiteren für sich an und ist dort sofort Inhaber, mit dem zweiten Faktor, den er schon hat (Recht tenant.create). Für jemand anderen legt ihn ein Betreiber im Bereich der Instanz an, mit einem Einladungslink, der die Person zum Inhaber macht, oder auf der Kommandozeile mit add-tenant. Ein neuer Betrieb startet leer wie nach der Ersteinrichtung und ist vom ersten getrennt wie zwei fremde. Für den Namen gilt dieselbe Regel wie bei der Ersteinrichtung und unter "Briefkopf".
• Der Wechsel des Betriebs ohne neue Anmeldung (#242), in der Kopfleiste, im Menü am Telefon und unter "Konto", sobald eine Person mehr als einen Betrieb hat. Was im Postausgang des ersten Betriebs liegt, geht vor dem Wechsel hinaus oder bleibt in dessen Ablage, und die Arbeit im ersten Betrieb endet in dessen Protokoll. Jede Anfrage einer Seite nennt seitdem den Betrieb, in dem sie arbeitet: Ein zweiter Tab, der nach einem Wechsel noch im alten Betrieb steht, schickt seinen Postausgang nicht in den neuen, sondern lädt neu.
• Passkeys sind zurück (#167, #248), damit sich jemand ohne Passwort anmeldet, mit Fingerabdruck, Gesicht oder PIN am Gerät, auf der Baustelle ohne das Telefon aus der Jacke. Unter "Konto" stehen die Passkeys des Kontos mit Name, Tag der Registrierung und letzter Benutzung; jeder lässt sich umbenennen und nach einer Rückfrage löschen, und das Passwort bleibt dabei. Hinzugefügt wird ein Passkey nur nach erneuter Bestätigung mit dem Passwort und, wo eingerichtet, dem Code aus der App, nicht allein mit einer bestehenden Sitzung; die Bestätigung gilt zehn Minuten und einen Passkey. Angelegt und angemeldet wird nur mit Bestätigung am Gerät, und eine solche Anmeldung zählt als zweiter Faktor, auch für den Inhaber und im Bereich der Instanz. Hinzufügen, Umbenennen und Löschen stehen im Änderungsprotokoll jedes Betriebs, in dem die Person arbeitet, eine Anmeldung mit Passkey an der Anmeldung im Betrieb, und ein neuer Passkey schickt eine E-Mail an das Konto. Die Anmeldung zeigt unter "oder" den Knopf "Mit Passkey anmelden". Seit dem 23.09.2026 waren Passkeys abgeschaltet (GHSA-jghx-6wmh-mpcj), weil jede Sitzung ohne Bestätigung einen registrieren konnte, eine Anmeldung damit keinen zweiten Faktor verlangte und niemand seine Passkeys sah. Migration 0052 löscht deshalb jeden Passkey, der noch aus dieser Zeit stammt: er wurde nie bestätigt, stand in keinem Protokoll und würde sonst wieder anmelden. Das Passwort meldet weiter an, und ein Passkey lässt sich neu hinzufügen.
• Tags an Kunden und Objekten (#314), damit der Betrieb seine Kunden nach dem ordnet, was er selbst unterscheidet, etwa Gewerk, Region oder Vertrag, und die Kundenliste danach filtert. Ein Tag entsteht unter "Einstellungen", "Tags" oder im Formular eines Kunden oder Objekts, wo ein Feld einen vorhandenen Tag findet oder einen neuen anlegt; unter "Einstellungen" wird er umbenannt und nach einer Rückfrage gelöscht, und dann verschwindet er von jedem Kunden und Objekt. Ein Name steht je Betrieb einmal, gleich in welcher Schreibung. Die Kundenliste zeigt die Tags neben dem Namen, findet einen Kunden auch über sie und filtert nach einem Tag zusammen mit den Chips; neben den Arten stehen die Chips Bestandskunde und Neukunde, die aus den Aufträgen folgen: Bestandskunde ist, wer einen abgeschlossenen Auftrag hat. Die Akte eines Kunden sagt das neben der Art; beides zeigt nur ein Ge...

OpenGewerk 0.4.0

Die vierte Fassung bringt die harmonisierte Mitteilung zur gesetzlichen Gewährleistung, die seit dem 27.09.2026 zu jedem Angebot an einen Verbraucher über eine Lieferung von Waren gehört. Dazu rechnet der Verzugszins taggenau nach der Länge des Kalenderjahres, die Regelpakete nennen ihre Fundstellen genauer, und die Abbilder erscheinen zusätzlich auf Docker Hub.

Wer 0.3.0 betreibt, aktualisiert mit dem Paket dieser Fassung; Migration 0048 läuft dabei von selbst. Wie bei den Fassungen davor fehlen vor dem produktiven Einsatz die fachliche Abnahme der Regelpakete und der Grenzwerte des Prüfprotokolls (#31) und der Praxistest der E-Rechnung (#133).

Hinzugefügt

• Die Abbilder jeder Fassung erscheinen zusätzlich auf Docker Hub, als opengewerk/opengewerk und opengewerk/backup (#281), damit OpenGewerk dort gefunden wird, wo viele zuerst nach Software suchen. Docker Hub ist ein Spiegel von ghcr.io und kein zweiter Bau: Der neue Workflow "Docker Hub" kopiert Abbilder und Signaturen mit crane, prüft danach mit cosign verify gegen dieselbe Identität des Release-Workflows und pflegt die Seiten dort aus .github/dockerhub/. Der Workflow "Release" ruft ihn nach jeder Fassung auf, von Hand holt er eine ältere nach; ohne die Secrets DOCKERHUB_USERNAME und DOCKERHUB_TOKEN tut er nichts. cosign copy taugt dafür nicht, es schreibt in cosign 3.1.3 das Abbild unter den Signatur-Tag statt des Signatur-Index. Nur auf Docker Hub zeigt latest auf die neueste Fassung; das Paket holt weiter aus ghcr.io, weil Docker Hub anonyme Pulls begrenzt.
• Die harmonisierte Mitteilung zur gesetzlichen Gewährleistung nach Anhang I der Durchführungsverordnung (EU) 2025/1960 geht mit jedem Angebot an einen Verbraucher über eine Lieferung von Waren hinaus (#431), Pflicht seit dem 27.09.2026 nach Art. 246 Abs. 1 Nr. 5 und Art. 246a § 1 Abs. 1 Satz 1 Nr. 11 EGBGB. Sie ist eine mitgelieferte Belehrung, aber keine Worte, sondern die Seite der Kommission: unverändert und als letzte Seite im PDF, ohne Briefkopf und Fußzeile, weil die Verordnung keine Änderung und keinen Zusatz erlaubt und mindestens A4 verlangt. Die Vorlage lässt dafür eine leere letzte Seite, die nach dem Rendern mit pdf-lib gegen die amtliche getauscht wird; so zählt die Fußzeile der übrigen Seiten sie mit. Die Datei liegt mit Quelle, Nutzungsbedingungen und Prüfsumme unter packages/server/assets/legal, und der Server druckt sie nur, wenn die Prüfsumme stimmt. Pflicht ist sie, wenn am Beleg "Lieferung von Waren mit Montage" gewählt ist und das Angebot ab dem 27.09.2026 datiert; einem Kostenvoranschlag wird sie nicht vorgeschlagen. Ihren Wortlaut ändert niemand, auch nicht über die API, und unter "Einstellungen", "Belehrungen" zeigt die Karte die Seite als Bild. Eingefroren wird sie mit ihrem Namen in Fassung 12 von DocumentContent, Migration 0048 ergänzt den Schlüssel guarantee_notice.

Geändert

• Der Verzugszins zählt jeden Tag gegen die Länge seines Kalenderjahres, 366 Tage im Schaltjahr und sonst 365 (act/act), statt jedes Jahr mit 365 Tagen (#31). Entschieden von Moritz am 26.09.2026 nach einer Gegenprüfung der Rechtsquellen: so rechnen die üblichen Verfahren für Zinsen nach § 288 BGB, und ein volles Kalenderjahr trägt damit genau den Jahreszins. Mit 365 Tagen kam ein Schaltjahr auf einen Tageszins mehr, beim heutigen Satz 2,88 Euro auf 10.000 Euro. Ein Zeitraum über den Jahreswechsel wird dort geteilt, jeder Teil gegen sein Jahr. daysInYear ist dafür eine Funktion des Jahres geworden. Gebraucht wird der Zins erst mit dem Mahnwesen in Phase 3 (#328), bis dahin rechnet damit nur die Prüfung der Regeln.
• Fundstellen nach derselben Gegenprüfung, ohne einen Wert zu ändern (#31). Die Notiz am Grenzwert der Schleifenimpedanz nennt den informativen Anhang D der DIN VDE 0100-600:2017-06 mit seinen zwei Dritteln, als Beleg aus zweiter Hand, und dass offen ist, nach welchem Wert das Prüfprotokoll urteilt. Das Paket invoice und der Satz für § 19 UStG nennen Abschnitt 14.7a UStAE aus dem BMF-Schreiben vom 18.03.2025, das auch eine umgangssprachliche Angabe genügen lässt. Das Paket working-time nennt den Referentenentwurf zum Arbeitszeitgesetz, der die Aufzeichnung am Tag der Arbeit verlangen würde; beschlossen ist er nicht. Kein eingetragener Wert weicht von seiner Fundstelle ab.
• Die Feature-Gliederung (v2.22) nimmt die vorvertraglichen Informationen an Verbraucher nach Art. 246 Abs. 1 und Art. 246a § 1 Abs. 1 EGBGB in Phase 1 auf (#431). Seit dem 27.09.2026 verlangen sie für Waren die harmonisierte Mitteilung zur Gewährleistung nach der Durchführungsverordnung (EU) 2025/1960; gebaut mit #431, siehe unter "Hinzugefügt".
• Die Feature-Gliederung (v2.23) legt fest, wie die Mitteilung zur Gewährleistung gedruckt wird, als letzte Seite im PDF und nur bei "Lieferung von Waren mit Montage", und ordnet die Kennzeichnung einer Haltbarkeitsgarantie des Herstellers nach Anhang II der Phase 2 zu (#433), weil sie je Ware gilt und an den Artikelstamm gehört. Die übrigen neuen Angaben legt der Betrieb als eigene Belehrung an, wenn der Hersteller sie liefert; so entschieden von Moritz am 26.09.2026.
• Die README zur Mitteilung zur Gewährleistung unter packages/server/assets/legal nennt die Grundlage für das Schild mit den Sternen der EU: nach der Vereinbarung zwischen EU und Europarat über die Verwendung des Emblems durch Dritte braucht es keine Erlaubnis, solange keine Verbindung zur EU vorgetäuscht wird. Eine Anfrage an die Kommission ist deshalb nicht gestellt worden, entschieden von Moritz am 27.09.2026.

Installieren und aktualisieren

Das Paket opengewerk-0.4.0.tar.gz enthält den Ordner opengewerk/docker. Zum Installieren entpacken, mit tar --no-same-owner -xzf opengewerk-0.4.0.tar.gz, und im Ordner opengewerk sh docker/start.sh aufrufen. Für ein Update das neue Paket genauso an dieselbe Stelle entpacken, die .env bleibt, und derselbe Befehl. Gebaut wird dabei nichts, geholt werden die Abbilder dieser Fassung, für x86_64 und ARM64:

• ghcr.io/opengewerk/opengewerk:0.4.0 (sha256:cb3db27abea0d858da05cb4bf4d06e76561776abcd227477f45f61242d50a856)
• ghcr.io/opengewerk/backup:0.4.0 (sha256:1d4e9702acfa9156be9b27497c37297f159b771b8d731a99f33cf863936e81b5)

Dieselben Abbilder liegen mit denselben Digests und Signaturen auch auf Docker Hub, als opengewerk/opengewerk:0.4.0 und opengewerk/backup:0.4.0. Das Paket holt sie trotzdem aus ghcr.io, denn Docker Hub begrenzt anonyme Pulls.

Gebraucht werden Docker und Docker Compose ab 2.22. Beide Abbilder sind ohne Schlüssel über Sigstore signiert. Prüfen:

cosign verify ghcr.io/opengewerk/opengewerk:0.4.0 \
  --certificate-identity https://github.com/opengewerk/opengewerk/.github/workflows/release.yml@refs/tags/v0.4.0 \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

OpenGewerk 0.3.0

Die dritte Fassung, klein und aus der ersten Einrichtung einer echten Instanz mit 0.2.0 entstanden. Der Name des Betriebs lässt sich jetzt unter "Einstellungen", "Briefkopf" ändern, und die Signatur unter jeder E-Mail trägt, was ein eingetragener Betrieb auf Geschäftsbriefen angeben muss.

Wer 0.2.0 betreibt, aktualisiert mit dem Paket dieser Fassung; Migration 0047 läuft dabei von selbst. Wie bei den Fassungen davor fehlen vor dem produktiven Einsatz die fachliche Abnahme der Regelpakete und der Grenzwerte des Prüfprotokolls (#31) und der Praxistest der E-Rechnung (#133).

Hinzugefügt

• Der Name des Betriebs lässt sich ändern, unter "Einstellungen", "Briefkopf" in der Karte "Betrieb", neben dem Namen auf den Belegen (#276). Bisher schrieb ihn nur die Ersteinrichtung, und ein falscher Name ließ sich nur in der Datenbank korrigieren; auf msk.opengewerk.de stand so ein Name in der Kopfleiste, den niemand getippt hatte. Ändern darf ihn, wer den Briefkopf ändern darf (settings.write). Er wird mit dem Briefkopf in derselben Transaktion gespeichert, und das Audit-Log hält fest, wer ihn geändert hat. Kopfleiste und "Betrieb wählen" zeigen danach den neuen Namen, ebenso ein Beleg, dessen Briefkopf keinen eigenen Namen trägt; ein festgeschriebener behält seinen. Die Anwendungsrolle darf dafür seit Migration 0047 an der Zeile ihres Betriebs in tenants genau name und updated_at ändern. Anlegen, Löschen und die Kennung bleiben gesperrt, wie seit 0007.

Geändert

• Das Feld "Betrieb" der Ersteinrichtung bietet sich Browsern und Passwortmanagern nicht mehr als Firma zum Ausfüllen an (autocomplete="off" statt organization, #276), denn am wahrscheinlichsten kam der fremde Name auf msk.opengewerk.de genau so hinein. Ersteinrichtung und Einstellungen prüfen den Namen mit derselben Regel (businessNameProblem in domain): nicht leer und höchstens 120 Zeichen, weil er in der Kopfleiste steht. Der vollständige Name für die Belege hat sein eigenes Feld.

Behoben

• Die Signatur unter jeder E-Mail trägt mit {briefkopf} jetzt auch, was der Briefkopf unter "Handelsregister und Vertretung" hält, und die USt-IdNr., wie die Fußzeile jedes Belegs (#278). Eine E-Mail an einen Kunden ist ein Geschäftsbrief, und ein eingetragener Betrieb nennt darauf je nach Rechtsform Registergericht, Registernummer und seine Geschäftsführer oder seinen Vorstand (§ 37a HGB, § 35a GmbHG und die Vorschriften der übrigen Rechtsformen); bisher ging jede Nachricht ohne diese Angaben hinaus. Sie stehen unter einer Leerzeile nach den Kontaktdaten, Steuernummer und Bankverbindung bleiben den Belegen vorbehalten. Eine Signatur ohne {briefkopf} trägt sie nicht, und als Sitz gilt der Ort der Anschrift, beides entschieden von Moritz am 26.09.2026. Die Vorschau unter "E-Mail-Einstellungen" zeigt die Angaben ebenso, und die Feature-Gliederung nennt die Pflichtangaben auf Geschäftsbriefen seit v2.21.

Installieren und aktualisieren

Das Paket opengewerk-0.3.0.tar.gz enthält den Ordner opengewerk/docker. Zum Installieren entpacken, mit tar --no-same-owner -xzf opengewerk-0.3.0.tar.gz, und im Ordner opengewerk sh docker/start.sh aufrufen. Für ein Update das neue Paket genauso an dieselbe Stelle entpacken, die .env bleibt, und derselbe Befehl. Gebaut wird dabei nichts, geholt werden die Abbilder dieser Fassung, für x86_64 und ARM64:

• ghcr.io/opengewerk/opengewerk:0.3.0 (sha256:4c890924a51d129b21fb024514c37e62710c8a54b8f29e3b0aa7b6cc9eec429e)
• ghcr.io/opengewerk/backup:0.3.0 (sha256:81504825b5446ffdacce479b28a5f91e01cf152d374fcc1f88a8b37bc8a662f9)

Gebraucht werden Docker und Docker Compose ab 2.22. Beide Abbilder sind ohne Schlüssel über Sigstore signiert. Prüfen:

cosign verify ghcr.io/opengewerk/opengewerk:0.3.0 \
  --certificate-identity https://github.com/opengewerk/opengewerk/.github/workflows/release.yml@refs/tags/v0.3.0 \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com