An Tag 3 bin ich, aufgrund der Erfahrung der Vortage, extra früh aufgebrochen, um noch einen Platz in Methodisch Inkorrekt zu bekommen. Leider musste ich bei meiner Ankunft feststellen, dass sich die Schlange schon durch die halbe Messehalle gestaut hatte und das mehr als eine Stunde vor dem Vortrag. Also habe ich erstmal beschlossen noch ein wenig herum zu schlendern. Dabei habe ich unter anderem die Menge an verschiedenen 3D Druckern und Lasergravurmaschinen bewundert. Vor allem die Lasergravur war sehr faszinierend. Man konnte auf mitgebrachte Gegenstände verschiedene Motive aufbringen. Als allerdings die Frage: “Braucht man da nicht eine Schutzbrille?”, mit einem Schulterzucken und einem: “Gute Frage, darüber habe ich noch nicht nachgedacht”, beantwortet wurde, stellte sich im Publikum ein gewisser Respekt gegenüber diesem Gerät ein. Nachdem ich noch ein wenig mit den Leuten geredet hatte, beschloss ich mein Glück beim Vortrag Methodisch Inkorrekt nochmal zu versuchen. In der Zwischenzeit hatte sich die Schlange fast vollständig aufgelöst, und es war noch ein Platz für mich frei.
Natürlich war ich sehr gespannt auf die Experimente, die dann auch in gewohnt lustiger Form präsentiert wurden. Zuerst gab es aber eine Verzögerung und mir ist klar geworden, warum noch ein Platz frei war: Der Vortrag war so früh angesetzt, dass viele der Besucher noch in den Straßenbahnen fest saßen. Und auf diese wurde natürlich in guter kollegialer Hacker Manier gewartet. (Und damit zeigt sich mal wieder, dass alle Events vor 12 Uhr mit Russisch Roulette vergleichbar sind, da wir halt Nachtwesen sind.) Nach der Ansage hatte ich auch kurze Zeit Angst um den Webserver der Leipziger Verkehrsbetriebe, da Rache ja bekanntlich kalt serviert wird und süß schmeckt.
Nach etwas Warten ging dann auch der Vortag los. Die erste Frage: “Wer ist denn schon wach?”, wurde in Anbetracht dessen, dass es gerade einmal 11:30 Uhr war, von der Mehrheit des Publikums negativ beantwortet. Anscheinend haben viele, die vor der Bahn da waren, einfach durchgemacht. Es ging dann langsam inhaltlich mit dem Vortag los. Begrüßt wurden wir von einem Video mit einer Neu-Vertonung von “Zurück in die Zukunft”, das hat schon mal einige aufgeweckt. Es ging dann direkt weiter mit einigen Themen vom IG Nobelpreis. Themen waren Forschungsergebnisse, die einen zuerst zum Lachen und danach zum Nachdenken bringen. Für das erste praktische Experiment wurde etwas Blut benötigt, was sich als schwieriger herausstellte als erwartet. Trotz funktionierendem Equipment konnte kaum Blut abgezapft werden. Selbst ein Sanitäter, der zur Hilfe kam, konnte nicht viel bewirken. Es wurde mit den kläglichen Tröpfchen Blut und etwas Wasserstoffperoxid versucht den gewünschten Effekt zu demonstrieren. Als nächstes haben die Vortragenden einen Ausblick auf die aktuelle Schnarchforschung gegeben und erklärten, was das Didgeridoo spielen damit zu tun hat. Da wir schon beim Thema waren, wurden dann noch verschiedenen Schnarch-Stopper aus China ausprobiert, was sehr lustig aussah. Es blieb lustig, mit dem Versuch die Frage zu beantworten: “Sind Katzen Flüssigkeiten?”. Den krönenden Abschluss bildete ein Heiratsantrag auf der Bühne, begleitet von einem tosenden Applaus.
Als Nächstes kam einer der Vorträge, auf den ich mich ganz besonders gefreut habe. Fefe hat mit dem Titel “Antipatterns und Missverständnisse in der Softwareentwicklung”
schon einen Nerv getroffen. Während des Vortrages hat er auch nicht
enttäuscht: In bekannter Manier brachte er alle Punkte lustig und
informativ rüber. Angefangen hat er mit einem Ausflug in das Universum
der Versionsverwaltung und was man darin lieber nicht machen sollte. Das
sind z. B. Dinge wie irgendwelche großen Binaries einchecken,
versionierte Ordner ablegen oder große Patchsets, die ewig vor sich hin
gammeln bevor sie integriert werden. Besser sollte man Patches sehr
klein halten und ständig in deinen Master Branch integrieren außerdem
sollte man in der Versionskontrolle auch mal etwas löschen und ersetzen,
genau dafür ist sie ja schließlich da!
Weiter ging es mit Buildsystemen. Vor allem im agilen Umfeld sind
stabile und deterministische Builds sehr wichtig und bilden die
Grundlage für das Arbeiten. Dabei sollte man bei Abhängigkeiten keine
Versionen hart codieren, sondern immer die aktuellste Version nehmen.
Dadurch fällt sehr schnell auf, wenn eine Abhängigkeit aktualisiert wird
und Probleme verursacht. An diesem Punkt ging es dann über zu Docker, aber ganz ohne Bashing! Denn Docker
ist an sich ein nützliches Tool, wenn man es richtig einsetzt und nicht
einfach nur alle Nachteile mitnimmt. Die Grundidee ist, dass man in
seinem GIT alle Versionen des Codes hat, der Buildserver daraus
dann alle Artefakte bauen und diese in Images ohne weitere
Abhängigkeiten bereitstellen kann. Hieran schloss sich nahtlos das Thema
Testing an, mit besonderem Augenmerk auf Unit-Tests, diese sollten vor
allem mit dem Ziel geschrieben werden, dass bei Änderungen gerüft werden
kann, ob man etwas kaputt gemacht hat. Sie sollen also die Angst
nehmen, an Legacy Code zu arbeiten. Dabei sollten auch negative Tests, die die Fehlerbehandlung prüfen, angedacht werden.
Das nächste Thema behandelte Gegebenheiten moderner Arbeitsplätze,
also das Großraumbüro. Das ist für Entwickler eine absolut schreckliche
Idee. Man wird mit Kommunikation überschüttet, obwohl man eigentlich
Ruhe braucht und sich konzentrieren muss. Auch der aktuelle Slack Trend
hat den gleichen Effekt, ständig blinkt irgendwas und lenkt einen von
der eigentlichen Aufgabe ab. Interessant war die Betrachtung zu
Meetings. Diese sollten am besten komplett gestrichen werden und lieber
auf 1-zu-1 Meetings umgestellt werden. Das fußt hauptsächlich auf der
Beobachtung, dass in einem größeren Meeting selten alle Teilnehmer
mitmachen. Meist sind es 2-3 Kollegen, die aktiv sind, sich äußern und
an einem Thema arbeiten, der Rest hört zu, oder wartet darauf, dass sein
Thema an der Reihe ist. Daran anknüpfend ging es zur Kultur. Die viel
beredete Fehlerkultur stand dabei im Mittelpunkt. Zusammen mit
sinnvollem Feedback sollte es Fehler-Findern möglichst einfach gemacht
werden von Fehlern zu berichten, damit sie motiviert bleiben und das
Gefundene tatsächlich melden. Der wichtige Punkt dabei ist, dass der
Verursacher, nicht der Finder, den Fehler fixen muss. Nur so lernt er
etwas dabei und wird den gleichen Fehler – hoffentlich – nicht nochmal
machen. Wenn Bugfixing in eine andere Abteilung (oder an den Betrieb)
ausgelagert wird, ist das die denkbar schlechteste Lösung.
Zum Abschluss gab es noch ein paar gute Tipps für Entwickler selbst.
Lasst euch keine Architektur vom Management vorgeben! Das bringt keinen
Mehrwert im Projekt, entweder ist die vorgegebene Entscheidung sowieso
schon offensichtlich, oder ihr schränkt euch unnötig ein. Außerdem ist
Lernen im Projekt immer negativ und wir alle müssen uns die Zeit
einfordern, um etwas zu lernen, während der Arbeitszeit! Der Druck kommt
dabei von uns selbst, wir sollten uns nicht vom Management zu
Überstunden nötigen lassen. Wenn ein Projekt falsch geplant ist, dann
muss es auch mal einen Verzug geben. Abgeschlossen hat er mit dem
schönen Satz “Wer wartet, bis der Boss einem Zeit gibt, wartet ewig”.
Alles in allem war es ein mit Informationen vollgepackter Talk, den man
sicherlich mehrfach schauen kann.
Nach diesen ganzen Informationen wollte ich mir etwas zu Cryptocurrencies und Smart Contracts ansehen. Da kam mir der Vortrag von Zooko, einem der Mitbegründer von Zcash,
gerade recht. Es sprach über die Historie und Entwicklung des gesamten
Themas. Prinzipiell sind diese aktuellen Hype Technologien eigentlich
nur die Anwendung von sehr lange bekannten Konzepten wie Signaturen,
Hashes und Zero-Knowledge Proofs. Bitcoin war dabei ein
wichtiger Meilenstein, weil man damit bewiesen hat, dass diese Art von
Technologie funktionieren kann. Und wofür haben wir es bisher genutzt? –
Für Glücksspiel und Spekulation.
Der eigentliche Zweck, die Verwendung als Zahlungsmittel, verschwindet absolut unter den anderen Aktivitäten wie z.B. ICOs und dem Horden von Coins (“HODL“) . Dennoch wurden durch die Blockchain
viele neue Möglichkeiten eröffnet. Aber es gibt auch noch viele offene
Probleme, wie z. B. die Skalierung und die Sicherheit in der Blockchain.
Trotz diesen Probleme hat sich, neben Bitcoin, vor allem Etherium
als Platzhirsch etabliert. Das liegt sicherlich an der
Entwicklerfreundlichkeit und an den Smart Contracts, welche einen hohen
Netzwerkeffekt erzeugen. Abschließend bleibt aber noch immer die Frage
im Raum: Haben wir da etwas Sinnvolles erschaffen oder ist alles nur
Hype?
Weitergehen
sollte es mit der Vorstellung “Inside AFD”, aber leider war sie sehr
schnell voll besetzt. Und leider gibt es davon auch keine Aufzeichnung.
Stattdessen habe ich mich dann in “Resilienced Kryptoraphie”
gesetzt und gehofft, dass ich es zumindest ein wenig verstehe. Und ich
wurde positiv überrascht: Der Vortragende hat es geschafft relativ tief
ins Thema einzutauchen, aber dennoch in großen Teilen verständlich zu
bleiben. Der Vortrag war mit konkreten Empfehlungen vor allem praktisch
ausgerichtet. Schön war schon die Eröffnung, in der darauf hingewiesen
wurde, dass Security by Namedropping nicht funktioniert. So etwas wie:
“wir sind sicher durch AES”, ist höchstens ein Marketingslogan und keine
technische Beobachtung. Es folgten konkrete Implementierungen und
Algorithmen. Das Hauptaugenmerk lag dabei auf Implementierungs- und
Nutzungsfehlern. Anfangs dachte ich, es geht um die altbekannten
Unterschiede zwischen EBC und CBC Modi, aber es wurde doch noch um einiges interessanter. Der Vortragende hat Angriffe auf den Counter Modus vorgestellt, die auch den GCM
Modus betreffen. Eine Variante, von der ich immer dachte, sie sei
sicher. Aber leider lag ich damit weit daneben. Es gibt hier sehr viele
subtile und unerwartete Möglichkeiten, wie etwas schiefgehen kann.
Grundsätzlich hängt der Erfolg bei der Verschlüsselung immer daran, dass
eine anfangs gewählte zufällige Zahl (Nonce) niemals wieder verwendet
werden darf. Die Lösung dafür bieten sogenannte Authenticated Encryption
Schemes. Wenn man neue Systeme konzipiert, sollte man darauf achten,
auch diese zu unterstützen. Grundsätzlich sollte man, wenn man in
irgendeiner Form Kryptografie implementiert, immer mit
Kryptografieforschern reden. Die Lehrbuch Versionen von so gut wie allen
Algorithmen sind nicht gegen Angriffe gehärtet und müssen erweitert
werden, damit sie in der “realen Welt” sicher funktionieren.
Das war dann auch die Überleitung zum Blockchain bzw. Bitcoin
Thema des Vortrages. Denn, obwohl Bitcoin sehr gut konzeptioniert ist,
enthält es aus kryptografischer Sicht einige Mängel. So hätte z. B. der
Proof-of-Work Algorithmus durch die Änderung nur eines Parameters so
gestaltet werden können, dass das Ganze ASIC und GPU Mining unrentabel wäre und einzig CPU Mining
betrieben werden könnte. Das hätte die aktuelle massive Umweltsauerei
durch den hohen Stromverbrauch vermieden! In dem Zusammenhang kam auch
ein Einwurf, dass Proof-of-Work eigentlich nicht optimal ist, schöner
wäre ein Proof-of-useful-Work. Damit würde man zumindest ein Problem
lösen und nicht einfach nur Energie verschwenden. Zum Abschluss kam dann
noch ein Appell:
„Gute Kryptografie muss immer offen liegen, sowohl die Spezifikation, als auch die Implementierung muss unabhängig nachvollziehbar sein! Dabei muss es nicht immer gleich eine komplette Open-Source Lizenz sein, offen liegender Quelltext der erforschbar ist, reicht aus.“
Als Nächstes habe ich mich der Frage “Are all BSDs created equal?” gewidmet. Der Vortrag hat das Argument aufgegriffen, dass BSD grundsätzlich besser und sicherer als Linux ist. Obwohl Argument in diesem Zusammenhang etwas milde ausgedrückt ist, es ist an vielen Stellen schon ein echter Flamewar oder Religionskrieg. Dabei liegt, wenn man sich die reinen Zahlen (CVEs, Advisories) ansieht, BSD wirklich erkennbar vor Linux, was die Sicherheit angeht. Aber der Vergleich hinkt ein wenig, da Linux eine viel höhere Verbreitung und einen ganzen Zoo von Treibern und Kernelerweiterungen hat. Also musste zuerst die Frage geklärt werden, wie man diese beiden Kontrahenten denn objektiv vergleichen kann. Der Vortragende hat sich dabei für ein Code Audit entschieden und die Kernels dann nach ihrer Codequalität, Fehleranzahl und Art der Fehler bewertet. Diese wurden teilweise im Vortrag präsentiert, wer sich für Kernel Interna interessiert, sollte sich das unbedingt ansehen. Als generelles Fazit kann man sagen, alle haben Bugs, und alle haben ähnliche Bugs, es gibt keinen signifikaten Unterschied zwischen den Systemen an sich. Interessant war aber, wie die einzelnen Distributionen reagiert haben. Die OpenBSD Entwickler haben sehr gut und schnell auf die eingereichten Bugreports reagiert. Ähnlich sah es bei NetBSD aus, die mehrere Fixes sogar über Nacht implementiert hatten. Eher schlecht sah es bei FreeBSD aus. Abschließend konnte man vor allem, den auf Sicherheit bedachten, OpenBSD eine sehr gute Codequalität bescheinigen, die im Vergleich hervorstechend war.
Den Abschluss des Tages wollte ich wieder etwas lockerer gestalten und habe mich in den Vortrag vom Zentrum für politische Schönheit gesetzt. Der Titel: “Tiger, Drucker und ein Mahnmal“,
war schon mal interessant. Und es ging auch schon sehr geladen los.
Zuerst mit etwas AFD und generellem Rechten-Bashing. Dann zu Aktionen
für und mit Flüchtlingen. Die Details kann man gerne im Vortrag
anschauen, grundlegend ging es den Organisatoren darum, Aufmerksamkeit
für das Massensterben auf Fluchtwegen zu erzeugen. Das Ganze war
augenöffnend und erschreckend zugleich.
Weiter ging es mit einer Flugblattaktion in der Türkei, diese fand ich
vor allem von der technischen Seite interessant. Es wurde eine Person,
zusammen mit einem Drucker in die Türkei geschickt und der Drucker dann
in einem Hotelfenster aufgebaut, um dann zeitgesteuert die Flugblätter
zu drucken. Der große abschließende Block des Vortrages drehte sich um
Bernd Höcke und das “Mahnmal der Schande”, welches in seinem Vorgarten
nachgebaut wurde. Obwohl die Geschichte sehr interessant war, habe ich
mich doch zwischenzeitlich gefragt, ob das nicht eventuell etwas über
die Stränge schlägt. Aber das hier zu beantworten, würde wohl zu
politisch werden.
So ging ein langer 3. Tag zu Ende und ich habe mir dann eine ruhige Ecke gesucht, in der ich mit ein paar Kollegen und Freunden noch etwas getrunken und ein wenig diskutiert habe. Danach bin ich zufrieden wieder nach Hause gegangen und habe mich schon auf den nächsten und leider auch letzten Tag gefreut.
Neugierig geworden? Noch mehr Konferenz-Erlebnisse gibt es hier:
Mit über 15 Jahren Erfahrung als System Engineer und System Architekt bin ich die “Allzweckwaffe” im Kampf gegen Bugs und Performanceprobleme. Den Rest meiner Arbeitszeit verwende ich zur Verbesserung unseres Monitoringsystems und des Netzwerks in unseren Rechenzentren.