Switch language to english
Znuny Professional Services

Der ((OTRS)) Community Edition Fork mit Langzeit-Support (LTS)

Insights - 6 | 12 | 17 | 10

Knapp 4 Monate betreuen wir jetzt schon unseren Fork.
Und wir sind sehr stolz auf das Erreichte.

Die im Titel genannten Zahlen beschreiben die Aktivitäten
des letzten Monats(!), also nur seit dem letzten Release - 6.0.33.

  • 6 Mitwirkende
  • 12 neue Sterne auf GitHub
  • 17 gemergte Pull-Requests
  • 10 aktive Issues

Die Zahl der aktiven Nutzer im Forum und auch die Beiträge
steigen stetig. Nachdem es über Jahre nicht möglich war, aktiv an diesem
Öko-System teilzunehmen, kehrt das Leben in die Community zurück.

Knapp 4 Monate betreuen wir jetzt schon unseren Fork.
Und wir sind sehr stolz auf das Erreichte.

Die im Titel genannten Zahlen beschreiben die Aktivitäten
des letzten Monats(!), also nur seit dem letzten Release - 6.0.33.

  • 6 Mitwirkende
  • 12 neue Sterne auf GitHub
  • 17 gemergte Pull-Requests
  • 10 aktive Issues

Die Zahl der aktiven Nutzer im Forum und auch die Beiträge
steigen stetig. Nachdem es über Jahre nicht möglich war, aktiv an diesem
Öko-System teilzunehmen, kehrt das Leben in die Community zurück.

Wir danken Euch und geben unser Bestes, dass es so bleibt. Macht weiter so.

XSS-Fix in 6.0.34 / Security-Fixes im Allgemeinen

Wie bereits mehrfach geschrieben, arbeiten wir uns momentan
durch den bestehenden Code. Wir gehen dabei eher nach Bereichen vor und
sehen uns nicht alles im Ganzen an.
Um ehrlich zu sein, ist es auch zu viel Code um sich alles direkt anzusehen.

Momentan sind wir auf der Suche nach Security-Auditoren, die in der Lage
sind, Perl-Code und die zugehörigen Abhängigkeiten so zu verstehen,
dass es über ein "Standard"-Audit hinausgeht.
Sobald wir hier einen verlässlichen Partner gefunden haben, werden
wir ein externes und unabhängiges Audit beauftragen.

In der Zwischenzeit bekommen wir Hilfe von einzelnen Security-Analysten,
durch Hinweise von anderen Projekten oder durch eigene Recherchen.

Diese eigenen Recherchen entstehen oft aus Bug-Meldungen, welche wir
uns dann bei der Ursachen-Analyse im Detail ansehen.

In der aktuellen Version 6.0.34 beheben wir eine XSS-Lücke, welche dort seit
längerer Zeit existiert und soweit wir das sagen können, so auch in der OTRS-7-Code-Basis besteht.

Diese Lücke wurde durch eine Fehlermeldung einer Hochschule entdeckt, welche
nichts mit XSS oder Security zu tun hat. Es war nur eine Meldung, dass für bestimmte E-Mails ein Fehler im Apache-Error-Log auftaucht.
Unsere Ursachenanalyse und unsere eigenen Erfahrungen in diesem Bereich
haben uns schnell zu einer möglichen XSS-Lücke geführt.
Zwei Stunden später hatten wir ein vollständiges Proof-Of-Concept, um

  • Kundendaten auszulesen
  • E-Mails zu versenden
  • sofern ein Admin Account genutzt worden ist, auch Nutzer anzulegen bzw. Einstellungen zu manipulieren

Diese spezielle Lücke braucht an dieser Stelle keinerlei Nutzerinteraktion.
Man kann es sogar so gut machen, dass nicht mal das relevante Ticket erscheint.
Die reine Betrachtung der Queue, in der sich das Ticket befindet, reicht aus.

Viele Nutzer sehen XSS nicht als "echte" Lücke. Daher wollen wir hier deutlich machen: XSS ist ernst zu nehmen.

Wir werden tatsächlich gefragt, warum wir so oft Security-Fixes veröffentlichen.
Nein, die Software ist nicht schlecht. Nein, die Programmierer sind es auch nicht.
Aber Technologien ändern sich, Vektoren für Angriffe ändern sich und Fehler passieren.
Durch unsere regelmäßigen Updates tragen wir diesen Fakten Rechnung.

Update aus dem Maschinenraum

In den letzten Wochen hat unser Team, dabei speziell Denny Korsukéwitz und Roy Kaldung, die CI-Umgebung auf GitHub aktiviert und konfiguriert.

Seit Ende März läuft jetzt ein Großteil der Unit-Tests und unsere Code-Policy auf GitHub.
Dadurch können wir Änderungen am Code direkt bewerten. Externe Mitwirkende bekommen so ebenfalls direkt Feedback zu ihren Pull-Requests.

Offen bleibt momentan noch ein Teil der Selenium-Tests, an welchen wir weiterhin arbeiten.

Wir haben außerdem die Synchronisation unseres internen GitLab zum externen GitHub umgestellt.
Vor der Umstellung hatten wir einen internen GitLab-Branch, welcher nicht direkt auf GitHub synchronisiert worden ist. Diese Variante resultierte aus dem Zeitdruck, den wir zur Übernahme des Forks hatten. Das brachte uns aber im Verlauf der Zeit mehr und mehr Nachteile. So passten z. B. Commit-IDs nicht mehr und der Code musste mehrfach synchronisiert werden.

Daraufhin haben wir unser Setup umgestellt und können nun alles synchron halten und trotzdem sauber mergen und releasen.

Der Branch rel-6_0-dev auf GitHub ist immer synchron mit unserem Branch rel-6_0-dev in GitLab. Ist ein Release-Zyklus zu Ende, wird dieser Branch mit rel-6_0 gemergt und auf GitHub gepusht.
Da jetzt jeder mit dem Branch rel-6_0-dev bzw. mit einer Kopie davon arbeitet, macht es uns die Arbeit wesentlich einfacher.

Git Branch Workflow

Wie geht es weiter

Im Moment aktualisieren wir mit einer Agentur unsere Projekt-Webseite. Die aktuelle Version funktioniert, war aber nur als Notlösung gedacht.
Die neue Webseite wird nach aktuellem Stand Anfang Mai online gehen.
Dort wird dann auch unsere Roadmap für die Feature-Version enthalten sein und eine Erklärung, wie wir uns die Versionen in Zukunft vorstellen bzw. was die Versionen unterscheidet.

Euer Znuny Team