Donnerstag, 24. Mai 2012


Artikel

Juli 2011 | Artikel

Kommentar: Auto-Updates in Software-Projekten

(Link zum Artikel: http://www.entwickler.de/php//003937)

Wenn Updates den Mehraufwand in ungeahnte Höhen schnellen lassen

Text: Tom Wießeckel
  • Teilen
  • kommentieren
  • empfehlen
  • Bookmark and Share
Auto-Updates à la Chrome für Open-Source-Web-Projekte? Matt Mullenweg put the "U" in WordPress und ich frage mich, ob nicht nur diese Community auf die Barrikaden steigen wird.

Tom Wiesseckel
Tom Wiesseckel
PHP Magazin

Ich habe – wie bestimmt die meisten von uns – alle aktuellen Browser auf dem Rechner. Von den meisten weiß ich sehr genau, welche Version gerade auf der Platte schlummert – nur beim Chrome kann ich mir nicht so wirklich sicher sein, wenn ich die entsprechende Option aktiviert habe. Geschmeidig fährt Googles Surf-Maschine ein Update nach dem anderen und eigentlich muss ich mich um nichts weiter kümmern. So weit, so gut. Ich bin zwar kein großer Freund von dieser Entwicklung, aber im Falle des Browsers mit dem bunten Logo wird es schon keine all zu großen Probleme geben. Die schlafende Schönheit steckt im Detail; immerhin bin ich so immer auf dem aktuellsten Stand der Technik.

Jetzt allerdings ist etwas passiert, was bestimmt nicht nur mich nachdenklich stimmt. Ich denke, wir sollten einmal über dieses Konzept reden, das Matt Mullenweg, der Kopf hinter WordPress, da angedacht hat. Denn was passiert, wenn sich die Idee der automatischen Updates so weiterentwickelt, dass sie für Entwickler "gefährlich" werden könnte?

Matt put the "U" in WordPress

Auf einem WordCamp in Montreal letztes Wochenende wurde Matt Mullenweg zu Version 3.3 des Blogsystems befragt. Genaue Pläne gäbe es zwar noch nicht, aber die Pläne sähen vor, sich auf das "U" in WordPress zu konzentrieren; auf den Uploader und die Updates. Letzteres bedeute eine Art der Updates, wie sie von Chrome bekannt sind: Gibt es eine neue Version, wird das System die geänderten Dateien automatisch herunterladen und so die Installation stets auf dem aktuellsten Stand halten.

Ein Nutzer muss sich also nicht mehr darum kümmern, dass er stets auf dem aktuellsten Stand ist. Keine verpassten Sicherheitsupdates mehr – was gerade bei großen Open-Source-Projekten schnell ein Problem werden kann – immer die neuesten Features. Klingt doch gut; vor allem aus Anwendersicht.

gäbe es da nicht ein kleines Problem: In WordPress 3.2 wurde ein neues JSON-Handling eingeführt. Und das hat zu Problemen geführt: A fair number of servers and distributions are, by default, missing the JSON extension for PHP. The number is actually a bit surprising, and is enough that we need to go forth with restoring these, so Andrew Nacin im Ticket. Ein Anwender, der keinen technischen Background besitzt und wenig Affinität für solche Dinge an den Tag legt, ist ab diesem Punkt hoffnungslos verloren.

Mehraufwand für Entwickler

Gehen wir noch einen Schritt weiter und betrachten verschiedene Frameworks wie Beispielsweise Symfony. Vor einiger Zeit berichteten wir bereits über die Kostenfalle Symfony2 – Anfangs war ich noch der Meinung, dass der Grundgedanke vielleicht etwas zu engstirnig wäre, die rege Diskussion hat aber dann doch für interessante Einblicke gesorgt: Viele Projekte sind von einer speziellen Version des Frameworks abhängig; automatisch eingespielte Updates könnten Entwickler an den Rand des Wahnsinns treiben.

Würden die Updates ungefragt eingespielt werden, müssten Entwickler stets alle Neuigkeiten im Blick haben und jedes Preview-Release mitgehen um sicherstellen zu können, dass die Anwendung im Nachhinein noch so läuft, wie man es erwartet. Das würde bedeuten, dass man im schlimmsten Falle – nämlich dann, wenn mehrere Projekte an einem Framework hängen – bei jedem Update immens viel Zeit verlieren würde, um alles gegen die neue Version zu testen. Ein Aufwand, der sich wirklich nicht mehr lohnen kann.

Und was wird aus den Anwendern? Auf dieser Seite potenziert sich das Problem, denn ein Endanwender von beispielsweise WordPress ist im schlimmsten Fall von deutlich mehr als einem Entwickler abhängig. Man stelle sich vor, ein Nutzer der zahlreiche Plug-ins installiert hat, bekommt ein automatisches Update serviert – und danach funktioniert die Hälfte nicht, da nicht jeder Plug-in-Entwickler sicherstellen konnte, dass die Erweiterungen nach dem Update noch lauffähig sind …

Steht hier Nutzen gegen Aufwand, nifty Feature gegen Realität? Ich halte automatische Updates in Software-Projekten ohne Nachfrage und Vorwarnung prinzipiell für "gefährlich".

Wie seht ihr das? Welche Art von Updates ist sinnvoll, ab wann wird es zu viel des Guten? Ich bin gespannt auf eure Meinungen.

Kommentare

Gravatar Ralf 13.07.2011
um 22:37 Uhr
Da muss man in Zukunft wahrscheinlich zwischen Update und Update unterscheiden. Wenn vor einem Update die Funktion X() immer y zurück gab und nach dem Update plötzlich z, dann stimmt etwas mit der Software nicht. Sprich: Ein (automatisches) Update darf die Schnittstellen nicht beeinflussen.
Das erfordert allerdings auch, dass sich die Entwickler an diese Schnittstellen halten. Gerade bei WordPress haben viele Plugin-Entwickler mal fröhlich auf den Codex gepfiffen und mit "bösen" Hacks gearbeitet. Dies sind die ersten Plugins die nach einem Update den Dienst verweigern. Ich habe Plugins die seit WP2.1 korrekt arbeiten. Allerdings sind das auch eher einfache Plugins.

Eine pauschale Aussage gut oder schlecht dürfte schwer zu treffen sein. Bei Sicherheitsupdates bzw. Patches würde ich es begrüßen. Vor allem dann, wenn es die Möglichkeit gäbe genauso einfach ein Downgrade durchzuführen.
Eine Funktion für ein Downgrade auf eine ältere Version halte ich in diesen Zusammenhang deswegen für ebenso wichtig wie die Möglichkeit sich zwischen automatische und manuelle Updates zu entscheiden.
#zitieren
Gravatar (tw) 14.07.2011
um 19:23 Uhr
Eine pauschale Aussage ist wirklich nicht möglich. Natürlich sind Security-Patches wichtig; aber auch die können unter Umständen einiges an die Wand fahren ...
Bei automatischen Updates muss man einfach zu viel berücksichtigen: Vom einfachen Test am Anfang bis hin zu Deployment - die Kette ist riesig! Und bei jeder Installation, in jeder Umgebung anders. Das abzufangen ist eine enorme Aufgabe...
#zitieren
Gravatar ventrix 18.07.2011
um 02:04 Uhr
Es gab doch vor kurzem ein wunderbares Beispiel gegen solche Verhalten: flashGet.
Ein Download-Manager, der auch gerne mal auto-updates ohne Nachfrage einspielt.
Die Folge: vor einigen Monaten (auch mal vor knapp 3 Jahren) wurde flashGet gehackt und ein mit maleware und trojanern bestücktes auto-update durchgeführt.

Crackern würden also solche feature sicher oft in die Hände spielen, besonders, wenn man selbst Module/Addons bei free cms auto updated. Das wäre für mich ein unhaltbares Risiko im live-Einsatz. Egal in welchem Tätigkeitsbereich.
#zitieren
Gravatar Ralf 18.07.2011
um 02:51 Uhr
@ventrix:
Andersrum kann es aber auch von Vorteil sein. Es gab ja schon öfters Fälle in denen eine Software gehackt und verseucht wurde. Der beste Zeitpunkt für so eine Attacke ist natürlich ein groß angekündigtes Update. Die Hacker suchen nach Lücken im Update-Server und warten bis das Update da ist. Dann schleusen sie ihre verseuchte Version ein und können davon ausgehen das noch relativ viele Leute die verseuchte Version runterladen.
In solchen Fällen könnte ein automatisches Update eine saubere Version hinter her schieben und somit das Schlimmste verhindern.

Das schnelle Patchen von Sicherheitslücken ist ja das vorrangige Ziel der automatischen Updates. Vor allem bei Websoftware die ja manchmal lange Zeit unbeaufsichtigt bleibt wäre es ein Vorteil in Punkto Sicherheit.
#zitieren
Gravatar Kai 17.10.2011
um 09:27 Uhr
Solange ein automatisches Update eine ausschaltbare Option ist, bin ich dem generell nicht abgeneigt. Wenn man eine höhere Anzahl von Wordpressinstallationen betreut, und sich als Entwickler auch sicher ist, dass da nicht viel schief gehen kann (weil man auch auf exessiven Plugineinsatz verzichtet hat), dann wäre das durchaus eine Erleichterung, die ich im Fall von Wordpress befürworte. #zitieren