Paketmanager: erst denken, dann tippen

Paketverwaltungen oder -manager sind längst nicht mehr nur Bestandteil von Betriebssystemen, sondern finden sich seit längerem auch im Zusammenhang mit Entwicklungsumgebungen bzw. Programmier- und Scriptsprachen wieder. Beispiele sind Composer für PHP, NuGet für .NET oder npm für JavaScript.

Die Hauptaufgabe der Paketverwaltungen ist das unkomplizierte Einbinden von Bibliotheken in Softwareprojekte. Angefangen bei der Suche in einem zentralen Register nach benötigten Bibliotheken oder Funktionen, sorgt der Paketmanager auch meist für die richtige Integration der einzelnen Bestandteile in das bestehende Projekt. Zudem lädt ein Paketmanager automatisch andere Pakete nach, auf denen das gewünschte Paket aufbaut.
Es gibt nicht wenige Pakete die ein Dutzend oder mehr Abhängigkeiten – sog. Dependencies – zu andern Paketquellen haben.

Ein weiterer Vorteil der Paketmanager ist die einfache Aktualisierung von verwendeten Paketen und deren Dependencies. Statt die verschiedenen Quellen der einzelnen Projekte nach Updates und Patches zu durchsuchen, erledigt die Paketverwaltung diesen Job zentral.

Insbesondere in großen Bibliotheken und Frameworks sind die Abhängigkeiten zu anderen Projekten teilweise unübersichtlich. Daraus ergeben sich Probleme und Gefahren, die sich jede_r Entwickelr_in oder Projektleiter_in bewusst machen sollte.

Ungesehener Code

Neben den vielen Abstraktionsebenen durch verschiedene Frameworks in modernen Softwareprojekten bringen die Dependencies weiteren Quellcode mit sich, der, streng genommen, von den Projektbeteiligten vor der Integration auditiert werden müsste. Das gleiche gilt für alle Updates dieser Pakete.

In den meisten Fällen handelt es sich bei den Paketquellen um Open-Source Projekte, so dass auf einen Codereview-Prozess der Community gehofft werden kann. Letztendlich ist jedoch jeder selbst für den ausgeführten Code in seinen Projekten verantwortlich.

Abhängigkeit

Ein weiters Problem wird bereits durch das Wort Dependencies selbst benannt: Was passiert bspw. wenn grundlegende Paketquellen von jetzt auf gleich verschwinden?

So geschehen im März 2016, als das Paket left-pad von seinem Entwickler aus der Paketverwaltung npm für JavaScript gelöscht wurde. Tausende Projekte und Frameworks, darunter Node.js und Babel, ließen sich nach einem Update der Paketquellen nicht mehr nutzen.
Der Grund für die Depublizierung war eine namenrechtliche Auseinandersetzung zu einer anderen Paketquelle (kik) des Entwicklers und dem Unternehmen hinter dem gleichnamigen IM.

Typosquatting

Neben den infrastrukturellen Risiken der Paketverwaltungen bietet deren Funktionsweise jedoch auch Schwachstellen für aktive Angriffe.
Ein gezieltes Szenario, der zumeist mit einem CLI zu bedienenden Paketmanager, wäre mit der sog. Typosquatting Methode denkbar.

Typosquatting (zu engl.: squat = besetztes Haus, dt. Lehnübertragung: Tippfehlerdomain) ist eine Form von Cybersquatting, die darauf beruht, dass eine Person einen Uniform Resource Identifier (URI, also die Adresse der Website) in einem Webbrowser versehentlich falsch eintippt und dann auf eine alternative Seite geführt wird, die dem Typosquatter gehört.

Nikolai Philipp Tschacher hat sich in seiner Bachelor Thesis mit genau diesem Thema auseinandergesetzt und untersucht, wie erfolgreich ein Übertragung des Typosquatting Angriffs auf populäre Paketmanager ist.

Dabei hat er nach einer Möglichkeit gesucht, bereits während der Installation eines Pakets, Code auf dem jeweiligen System ausführen zu können. Seine Betrachtung beschränkte sich auf die Paketmanager PyPi für Python, npm für JavaScript und rubygems.org für Ruby.

Der ausgeführte Code lieferte Informationen über das jeweilige System und die zur Installation des Pakets verwendeten Benutzerrechte an einen Webserver der Universität Hamburg zurück.

Das Ergebnis nach 214 erstellten und veröffentlichten Pakete mit ähnlichen Namen von populären Paketquellen ist erstaunlich bis beunruhigend.

Insgesamt kamen 45.334 HTTP Requests von 17.289 eindeutigen Hosts zusammen. Das bedeutet, dass der in den Paketen eingeschleuste Code auf über 17.000 Systemen innerhalb des etwa zwei monatigen Versuchs ausgeführt wurde.
Davon wurden 43,6% der Installationen mit Administrationsrechten ausgeführt. Ein Großteil der Hosts wurde mit Linux betrieben (8.614), gefolgt von Windows (6174) und OS X (4.758).

Gesunder Menschenverstand

Paketmanager bieten einen hohen Komfort für Softwareentickler_innen und die Nutzung von bestehenden Bibliotheken bedeutet für das einzelne Projekt meist einen nicht unerheblichen Zeitgewinn. Außerdem ist die Devise, dass Rad nicht ständig neu erfinden zu wollen, nicht grundsätzlich verwerflich.

Es sollte jedoch die Frage erlaubt sein, welchen Mehrwert eine Bibliothek wie bspw. das genannte left-pad Paket, das im wesentlichen eine Zeichenkette mit Leerzeichen auf eine bestimmte Länge auffüllt, im Verhältnis zu den angeführten Risikofaktoren bietet.

Dependencies erhöhen ohne Zweifel die Komplexität von Softwareprojekten. Grundsätzlich empfiehlt es sich natürlich, die Abhängigkeiten in Applikationen so gering wie möglich zu halten.
Zudem schadet ein regelmäßiger Blick in den eingebundenen Code sicher nicht. Informationen über die Community hinter den jeweiligen Paketquellen und deren Aktivität lassen sich bei Open-Source Projekten relativ einfach finden.

Im Zweifel ist der gesunde Menschenverstand auch in dieser Angelegenheit der beste Ratgeber.

caniuse.com

Wer in Sachen Webentwicklung oder -design unterwegs ist, wird häufig vor die Frage gestellt, von welchem Browser dieser CSS Selektor oder jenes HTML5 Element denn nun unter welchen Bedingungen unterstützt wird.

Die Antwort auf diese Fragen liefert caniuse.com; und zwar in einer Ausführlichkeit, die nichts zu wünschen übrig lässt. Neben der Auflistung aller gängigen Desktop- und Mobile-Browser in sämtlichen Versionen und deren Kompatibilität zu der ausgewählten Frontend-Webtechnologie, finden sich auf der Seite viele weiterführende Links und Informationen. Dort werden bspw. alle bekannten Bugs und Einschränkungen der jeweiligen Funktion gesammelt und beschrieben. Zudem wird der Status zur Umsetzungen in den einzelnen Browsern vermerkt.

Die Daten werden hauptsächlich durch die Webentwickler Community zusammengetragen. Außerdem hat Alexis Deveria, der Betreiber von caniuse.com, eine Testseite erstellt, mit welcher sich die verschiedenen Funktionen im eigenen Browser testen lassen.

Die Seite ist insgesamt gut strukturiert, responsive und dank des umfangreichen Einsatzes von JavaScript sehr flott. Zur Nützlichkeit der Seite muss ich wohl keine weiteren Worte verlieren. Wer den Macher unterstützen möchte, kann dies via Flattr tun oder sich am Zusammentragen der Informationen im entsprechenden GitHub Repository beteiligen.

HTTP jetzt auch einfach mit S

Für den gemeinen Datenreisenden gibt es wohl kaum eine Maßnahme, die dessen Privatsphäre müheloser stärkt, als beim Abrufen von Webinhalten dem Protokollbezeichner HTTP ein kleines S zur Seite zu stellen.

Mit der Verwendung des Protokolls HTTPS ist nämlich sichergestellt, dass Daten abhörsicher zwischen dem Webserver und dem Endgerät des Nutzers übertragen werden.

Was für den Verbraucher so einfach funktioniert, bedeutete für den Inhalteanbieter jedoch bislang einen gewissen Aufwand und/oder war mit Kosten verbunden.
HTTPS basiert auf SSL bzw. TLS und ist damit den asymmetrischen Kryptosystemen zuzuordnen. Damit eine Webseite also via HTTPS erreichbar ist, muss ein kryptographisches Schlüsselpaar – im Idealfall von dessen Urheber – generiert und auf dem betreffenden Webserver konfiguriert bzw. hinterlegt werden.

Passkontrolle

Das Erzeugen und Hinterlegen von kryptographischen Schlüsseln ist uneingeschränkt jeder Person oder Maschine mit entsprechenden Kenntnissen bzw. Anweisungen, Berechtigungen und Werkzeugen möglichen. Um diesem Problem, also die Frage nach Authentizität und Integrität des öffentlichen Schlüssels, zu begegnen, wurde das Konzept der CA s entwickelt. Bestimmte zentrale Stellen sollen durch eine digitale Signierung des öffentlichen Schlüssels mit Hilfe ihrer Root-Zertifikate durchführen. Diese Dienstleistungen erbringen CAs in der Regel auf Nachweis der Identität des Schlüsselinhabers und gegen Geld. Die öffentlichen Schlüssel der CAs wiederum werden als Bestandteil der meisten Webbrowser von den Herstellern verwaltet und mit ausgeliefert.

Webseiten, deren öffentlicher Schlüssel für eine HTTPS Verbindung nicht von einer offiziellen CA signiert wurde, rufen normalerweise im Browser des Besuchers eine Warnmeldung hervor. Dies bedeutet nicht, dass die Verbindung weniger gut verschlüsselt ist, jedoch ist die Authentizität und Integrität des Schlüssels nicht bestätigt. Auf den durchschnittlichen Facetuber wirkt ein solcher Warnhinweis oft abschreckend und stört die User Experience.

Über die Effektivität und die daraus folgende Frage nach der Sinnhaftigkeit von CAs kann und sollte an anderer Stelle diskutiert werden.

Game changer

Grundsätzlich sollte es jedem Datenanbieter und jedem Datenkonsumenten daran gelegen sein, möglichst viel der verursachten Datenströme im WWW gegen einfaches Mitlesen zu schützen. Es soll Akteure abseits der genannten Interessengruppen geben, die da anderer Ansicht sind. Diese möchte ich an dieser Stelle jedoch bewusst vernachlässigen.

Das Projekt Let’s Encrypt der ISRG hat sich eine möglichst starke Verbreitung von HTTPS zum Ziel gesetzt. Zum einen wollen die Beteiligten das Erstellen von kryptographischen Schlüsseln und das entsprechende Konfigurieren der Webservers vereinfachen. Zum anderen soll Let’s Encrypt auch als offiziell anerkannte CA fungieren und die generierten öffentlichen Schlüssel signieren. Die dafür notwendigen Werkzeuge sollen open source sein und der gesamte Prozess von der Entwicklung der Software bis hin zur Signierung der Schlüssel transparent gestaltet und auditiert werden.

Los geht’s

Seit Oktober 2015 ist Let’s Encrypt eine offizielle CA und durch die Signierung des eigenen Root-Zertifikats (sog. Cross-Sign) durch die bereits anerkannte CA IdenTrust SSL als »vertrauenswürdig« eingestuft.
IdenTrust SSL ist den Browsern bereits bekannt, so dass alle von Let’s Encrypt signierten Schlüssel auch akzeptiert werden.
Darauf hin wurden die ersten Schlüssel mit den auf GitHub hinterlegten Tools für ausgewählte Webseiten generiert und signiert. Seit 03.12.2015 läuft nun die öffentliche Beta-Phase. Das für Dezember 2015 angekündigte Ergebnis eines unabhängigen Audits steht allerdings noch aus.

Einschränkungen

Bislang lassen sich keine Wildcard-Zertifikate erstellen. Jede Subdomain muss daher noch explizit im Zertifikat unter Subject Alternative Names vermerkt werden.
Das Zertifikat ist zur Zeit 90 Tage lang gültig. Angedacht ist hier eine Reduzierung der Gültigkeit auf 30 Tage. Eine Erneuerung mit Hilfe der in Python geschriebenen Tools ist jedoch ohne Weiteres und unkompliziert möglich. Durch die geringe Gültigkeit verspricht man sich einen einfacheren Umgang mit unberechtigt erstellten und signierten Zertifikaten.
Damit der gesamte Prozess möglichst automatisiert ablaufen kann, hat sich Let’s Encrypt ein Protokoll namens ACME ausgedacht. Dieses liegt der IETF bereits als Internet Draft vor.

In eigener Sache

Da mein Webhoster Uberspace die Anforderungen von Let’s Encrypt bereits erfüllt, habe ich für diese Seite bereits Schlüssel und Zertifikat erstellt und eingebunden. Auch alle Assets werden nun via HTTPS ausgeliefert.

Ohne in den Erstellungsprozess eingegriffen zu haben, bringt die Konfiguration des Webservers im SSL Server Test von QUALYS SSL LABS das zweitbeste Ergebnis A.
Hauptsächlich die auf Seiten des Browsers erforderliche Unterstützung von SNI wird bemängelt. Die Shared Hosting Umgebung meiner Webseite macht diese TLS Erweiterung jedoch erforderlich.
Außerdem erreicht das Ergebnis in Sachen Schlüssellänge nicht die volle Punktzahl.

Die Handhabung des Tools ist, auch dank der Vorkonfiguration des Webhosters, erstaunlich einfach und die gesamte Umstellung hat nur wenige Minuten Zeit in Anspruch genommen. Doch wie immer gilt: Automatisierung und mehr verschlüsselter Datenverkehr ist gut, Kontrolle und Verstehen ist besser.

tl;dr

Mehr Verschlüsselung ist mehr gut. Das gilt vor allem für Datenströme die, wie es häufig im WWW der Fall ist, öffentlich einsehbar sind. Um als Webseitenbetreiber dem Nutzer eine gesicherte Verbindung mittels HTTPS anbieten zu können, musste bisher Zeit und Geld investiert werden.

Let’s Encrypt bringt seit 2015 Bewegung in das Verschlüsselungs-Spiel, in dem das Projekt zum Einen ein einfach zu bedienendes Tool zur Erzeugung der notwendigen kryptographischen Schlüssel und das Konfigurieren des Webservers bereit stellt. Und zum Anderen, in der Rolle als autorisierte CA, die Vertrauenswürdigkeit des öffentlichen Schlüssels bekräftigt.

Eine kleine Webseite, wie diese es ist, lässt sich so in wenigen Minuten für den verschlüsselten Aufruf vorbereiten.

Agile Development. Jetzt wirklich.

Wer mit Begriffen wie Agile Development, Lean oder Scrum etwas anfangen kann, weiß auch, dass diese im Bereich der Softwareentwicklung inzwischen reichlich überstrapaziert sind. Hinter jedem der Buzzwords verbirgt sich das Versprechen, Softwareprojekte erfolgreich realisieren zu können; vereint in dem Anspruch hoch flexibel und dennoch strukturiert zu sein.

Overhead

Literatur zu den Themen gibt es wie Sand am Meer. Ein Buch dicker als das Andere. Aber genau da liegt für mich das Problem. Konzepte wie Scrum lassen sich nicht beiläufig in 10 Minuten erklären. Dabei ist es für ein Managementkonzept wichtig, dass Regeln so einfach wie möglich von allen Beteiligten zu verstehen sind und angewendet werden können.
Zudem spielt das Management in Scrum und Co. eine viel zu zentrale und gewichtige Rolle. Flexibel sind die Modelle, insbesondere in kleinen oder schnell wachsenden Teams, nur bedingt.

Kultur statt Management

Richtig anfreunden konnte ich mich mit den Big Playern der Softwareentwicklungsmethoden nie. Deshalb war ich überrascht, als ich zufällig über ein mir bis dato unbekanntes Konzept gestolpert bin wurde. In der 174 Folge des Geekweek Podcasts berichtet Mustafa K. Isik von der Spotify engeneering culture.

Auf dem Spotify Labs Blog findet sich ein liebevoll gestaltetes, zweiteiliges Video, in dem die Geschichte von und das Konzept hinter der Spotify engeneering culture erklärt wird.

Zugegeben

Das ganze Konstrukt ist sehr stark auf die Bedürfnisse und Gegebenheiten des Unternehmens Spotify zugeschnitten. Insbesondere die Organisation der kleinen Teams, Squads genannt, orientiert sich im Wesentlichen an den spezifischen Endprodukten.
Nichts desto trotz gefällt mir der Ansatz und die Struktur ausgesprochen gut. Vor allem die zweidimensionale Ausrichtung der einzelnen Rollen bzw. Teammitglieder in Squads und Chapter ist eine interessanter Sichtweise, die Fähigkeiten und das Wissen jedes Individuums optimal und auf verschiedenen Ebenen einzubringen. Das Atomarisieren von komplexen Zielen in viele kleine Teilaufgaben vereinfacht den gesamten Prozess und sorgt für mehr Erfolgserlebnisse. Nicht zuletzt das ausdrücklich erwünschte Machen von Fehlern lässt das Konzept innovativ sein. Denn aus Fehlern die früh gemacht, kann schließlich schnell gelernt werden.

tl;dr

Allen, die sich für das Thema Softwareentwicklungsmethoden interessieren und Scrum zu den Ohren raus hängt, sei die Spotify engeneering culture ans Herz gelegt.

motherfuckingwebsite.com

Manchmal ist das Eingestehen von Wahrheiten schmerzhaft. Insbesondere bei solchen mit persönlichem Bezug. Der Webentwickler und -designer Barry Smith schafft es mit seinem HTML-Dokument motherfuckingwebsite.com, gleich ins Mark einer ganzen Berufsgruppe zu treffen.

You probably build websites and think your shit is special. You think your 13 megabyte paralax-ative home page is going to get you some fucking Award banner you can glue to the top corner of your site. You think your 40-pound jQuery file and 83 polyfills give IE7 a boner because it finally has box-shadow. Wrong, motherfucker.

Barry Smith

Die Rede ist von Webdesignern und deren Produkte. Mit erfrischend klaren Worten erinnert der Text an die ursprüngliche Idee hinter dem WWW und führt die Probleme des modernen Webdesigns auf.
Nicht selten drücken schwere JavaScript Bibliotheken die Performance einer ganzen Seite, nur um das Navigationselement seicht animiert einfahren zu lassen. Blockelemente werden mühsam mittels CSS arrangiert und am Ende versteht der Internet Explorer doch wieder alles falsch.

What I'm saying is that all the problems we have with websites are ones we create ourselves.

Barry Smith

Nichts von dem ist ein Konstruktionsfehler der Webseiten, sondern hausgemachte Probleme des Webdesigns.

Auch wenn die erwähnte Webseite als Satire zu verstehen ist, sollte der Text zum Nachdenken anregen. Vielleicht verzichten wir einfach bei der nächsten Webseite/(aber: GUI title: Graphical User Interface) auf die ein oder andere fancy Animation. Zugunsten der Usability und Kompatibilität.