Im Zuge der Vorstellung der Entwicklungstools von Atlassian hatten wir uns bereits mit Crucible beschäftigt. Im Artikel meines Kollegen David wurden dabei vor allem die Features von Crucible beleuchtet. Hier soll es nun darum gehen, welche Erfahrung wir bei unserer täglichen Arbeit mit dem Code-Review Tool von Atlassian gemacht haben.
Vor einigen Wochen kam in der Atlassian-Abteilung bei Communardo, aus nahe liegenden Gründen 
, die Idee auf, Atlassian Stash auszuprobieren. Erste Eindrücke zum Tool hat mein Kollege Niels schon vor einiger Zeit gepostet. Dieser Beitrag bezog sich vor allem auf das Tool und seine Features und lässt damit einen wesentlichen Aspekt aus: Man fängt halt nicht einfach mal an Stash zu nutzen. Vor allem, wenn man wie wir bis dato ausschließlich mit zentraler Versionsverwaltung gearbeitet hat, der Zweck von Stash aber darin besteht Verwaltung und Arbeit mit Git, einem System zur dezentralen Versionsverwaltung (DVCS), zu erleichtern.
In diesem Beitrag soll es also darum gehen, welchen Einfluss die Verwendung von Stash auf unsere Arbeit hatte.
Zusätzlich zum Hinweis über eine Sicherheitslücke in FishEye und Crucible hat Atlassian heute einen Hinweis zu einer Sicherheitslücke in GreenHopper veröffentlicht. Dabei handelt es sich um eine Anfälligkeit gegen Cross-Site-Scripting. Atlassian stuft die Sicherheitslücke als “High” ein, was dem zweithöchsten Schweregrad in der von Atlassian definierten Abstufung entspricht. Im konkreten Fall kann ein Angreifer eigenes JavaScript auf einer GreenHopper-Seite einbetten.
Atlassian empfiehlt ein Upgrade auf die aktuellste GreenHopper-Version, mindestens aber auf Version 5.9.8, in der das Problem behoben ist. Einen Patch für ältere Versionen gibt es nicht.
Weitere Details zur Sicherheitslücke können im Artikel von Atlassian gefunden werden.
Am vergangenen Donnerstag hat Atlassian einen Hinweis zu einer Sicherheitslücke veröffentlicht. Sie wird durch die Art und Weise, auf die XML-Parser eines Drittanbieters verwendet werden, verursacht. Atlassian stuft die Sicherheitslücke als “Critical” ein, was dem höchstmöglichen Schweregrad in der von Atlassian definierten Abstufung entspricht. Im konkreten Fall bedeutet dies, dass ein Angreifer auf Grund dieser Sicherheitslücke, auch ohne am System angemeldet zu sein,
- einen Denial of Service (DoS) Angriff gegen das System ausführen kann
- alle Dateien auf dem Server auslesen kann, auf die der Nutzer Zugriff hat, unter dem Confluence ausgeführt wird
Um die Gefahr etwas einzudämmen, können kurzfristig die von Atlassian unter “Risk Mitigation” vorgeschlagenen Maßnahmen angewendet werden. Allerdings besteht laut Atlassian der einzig wirksame Schutz in einem Upgrade auf mindestens Confluence 3.5.16 (oder die jeweils aktuellsten Minor-Releases der neueren Confluence-Versionen). Für ältere Confluence-Versionen muss also auf ein entsprechendes Major-Release aktualisiert werden.
Weitere Details zur Sicherheitslücke können im Artikel von Atlassian gefunden werden.
Ich hatte das Glück einer von zwei Vertretern Communardos beim diesjährigen Atlassian Summit zu sein, der weltweiten Konferenz von Atlassian für Partner und Kunden. Hier alles wiederzugeben was ich dort erlebt habe würde den Rahmen dieses Posts sprengen. Daher werde ich mich im Folgenden auf die spannendsten Neuerungen beschränken.