Das Neueste wird nicht immer das Beste sein

Seit über einem Jahrzehnt hat sich die Erkenntnis durchgesetzt, das Computersysteme aktuell gehalten werden sollten. Wer regelmäßig Updates einspielt verringert das Risiko auf seinem Computer Sicherheitslücken zu haben, die Missbraucht werden könnten. Immer in der Hoffnung das Hersteller von Software stets in ihren Updates auch Sicherheitsmängel beheben. Microsoft hat beispielsweise seit der Einführung von Windows 10 seinen Nutzern ein Update-Zwang auferlegt. Grundsätzlich war die Idee durchaus begründet. Denn ungepatchte Betriebssysteme ermöglichen Hackern leichten Zugriff. Also hat sich vor sehr langer Zeit der Gedanke: ‚Latest is greatest‘ durchgesetzt.

Windowsnutzer habe hier wenig Freiräume. Aber auch auf mobilen Geräten wie Smartphones und Tabletts sind in der Werkseinstellung die automatischen Updates aktiviert. Wer auf GitHub ein Open Source Projekt hostet bekommt regelmäßige E-Mails um für verwendete Bibliotheken neue Versionen einzusetzen. Also auf den ersten Blick durchaus eine gute Sache. Wenn man sich mit der Thematik etwas tiefer auseinandersetzt kommt man sehr schnell zu dem Schluß das latest nicht wirklich immer das beste ist.

Das bekannteste Beispiel hierfür ist Windows 10 und die durch Microsoft erzwungenen Update Zyklen. Das Systeme regelmäßig auf Sicherheitsprobleme untersucht werden und verfügbare Aktualisierungen eingespielt werden müssen ist unumstritten. Das die Pflege von Rechnersysteme auch Zeit in Anspruch nimmt ist ebenfalls Einsichtig. Problematisch ist es aber wenn durch den Hersteller eingespielte Aktualisierungen einerseits das gesamte System lahmlegen und so eine Neuinstallation notwendig wird, weil das Update nicht ausreichend getestet wurde. Aber auch im Rahmen von Sicherheitsaktualisierungen ungefragt Funktionsänderungen bei den Nutzer einzubringen halte ich für unzumutbar. Speziell bei Windows kommt noch hinzu, das hier einiges an Zusatzprogrammen installiert ist, die durch mangelnde Weiterentwicklung schnell zu einem Sicherheitsrisiko werden können. Das bedeutet bei aller Konsequenz erzwungene Windowsupdates machen ein Computer nicht sicher, da hier die zusätzlich installierte Software nicht auf Schwachstellen untersucht wird.

Wenn wir einen Blick auf Android Systeme werfen, gestaltet sich die Situation weitaus besser. Aber auch hier gibt es genügend Kritikpunkte. Zwar werden die Applikationen regelmäßig aktualisiert, so das tatsächlich die Sicherheit markant verbessert wird. Aber auch bei Android bedeutet jedes Update in aller Regel auch funktionale Veränderungen. Ein einfaches Beispiel ist der sehr beliebte Dienst Google StreetMaps. Mit jeden Update wird die Kartennutzung für mich gefühlt unübersichtlicher, da eine Menge für mich unerwünschter Zusatzinformationen eingeblendet werden, die den bereits begrenzten Bildschirm erheblich verkleinern.

Als Nutzer ist es mir glücklicherweise noch nicht passiert, dass Applikationsupdates unter Android das gesamte Telefon lahmgelegt haben. Was also auch beweist das es durchaus möglich ist Aktualisierungen ausgiebig zu testen, bevor diese an die Nutzer ausgerollt werden. Was aber nicht heißt das jedes Update unproblematisch war. Probleme die hier regelmäßig beobachtet werden können sind Dinge wie ein übermäßig erhöhter Batterieverbrauch.

Reine Android Systemupdates wiederum sorgen regelmäßig dafür das die Hardware nach knapp zwei Jahren so langsam wird, das man sich oft dazu entscheidet ein neues Smartphone zu kaufen. Obwohl das alte Telefon noch in gutem Zustand ist und durchaus viel Länger genutzt werden könnte. So ist mir bei vielen erfahrenen Nutzern aufgefallen, das diese nach circa einem Jahr ihre Android Updates ausschalten, bevor das Telefon durch den Hersteller in die Obsoleszenz geschickt wird.

Wie bekommt man ein Update-Muffel nun dazu seine Systeme trotzdem aktuell und damit auch sicher zu halten? Mein Ansatz als Entwickler und Konfiguration Manager ist hier recht einfach. Ich unterscheide zwischen Feature Update und Security Patch. Wenn man im Release Prozess dem Semantic Versioning folgt und für SCM Systeme wie Git ein Branch by Release Modell nutzt, lässt sich eine solche Unterscheidung durchaus leicht umsetzen.

Aber auch der Fragestellung eine versionierbaren Konfigurationseinstellung für Softwareanwendungen habe ich mich gewidmet. Hierzu gibt es im Projekt TP-CORE auf GitHub eine Referenzimplementierung die in dem zweiteiligen Artikel Treasue Chest ausführlich beschrieben wird. Denn es muss uns schon klar sein, dass wenn wir bei einem Update die gesamte vom Nutzer vorgenommene Konfiguration auf Werkseinstellung zurück setzen, wie es recht oft bei Windows 10 der Fall ist, können ganz eigene Sicherheitslücken entstehen.

Das bringt uns auch zu dem Punkt Programmierung und wie GitHub Entwickler durch E-Mails dazu motiviert neue Versionen der verwendeten Bibliotheken in ihre Applikationen einzubinden. Denn wenn es sich bei einem solchen Update um eine umfangreiche API Änderung handelt ist das Problem der hohe Migrationsaufwand für die Entwickler. Hier hat sich für mich eine ebenfalls recht einfache Strategie bewährt. Anstatt mich von den Benachrichtigungen über Aktualisierungen von GitHub beeindrucken zu lassen, prüfe ich regelmäßig über OWASP ob meine Bibliotheken bekannte Risiken enthalten. Denn wird durch OWASP ein Problem erkannt, spielt es keine Rolle wie Aufwendig eine Aktualisierung werden kann. Das Update und ein damit verbunden Migration muss zeitnahe umgesetzt werden. Dies gilt dann auch für alle noch in Produktion befindlichen Releases.

Um von Beginn an der Update Hölle zu entrinnen gilt allerdings eine Faustegel: Installiere beziehungsweise nutze nur das was du wirklich benötigst. Je weniger Programme unter Windows installiert sind und je weniger Apps auf dem Smartphone vorhanden sind, um so weniger Sicherheitsrisiken entstehen. Das gilt auch für Programmbibliotheken. Weniger ist aus Sicht der Security mehr. Abgesehen davon bekommen wird durch den Verzicht unnötiger Programme noch eine Performance Vermessung frei Haus.

Sicher ist für viele privaten Anwender die Frage der Systemaktualisierung kaum relevant. Lediglich Neue unerwünschte Funktionen in vorhanden Programmen, Leistungsverschlechterungen oder hin und wieder zerschossene Betriebssysteme verursache mehr oder weniger starken Unmut. Im kommerziellen Umfeld können recht schnell erhebliche Kosten entstehen, die sich auch auf die gerade umzusetzenden Projekte negativ auswirken können. Unternehmen und Persone die Software entwickeln können die Nutzerzufriedenheit erheblich verbessern, wenn sie bei Ihren Release Veröffentlichungen zwischen Security Patches und Feature Updates unterscheiden. Und ein Feature Update sollte dann entsprechend auch allen bekannten Security Aktualisierungen enthalten.

Latest won’t always be greatest

For more than a decade, it has been widely accepted that computer systems should be kept up to date. Those who regularly install updates reduce the risk of having security gaps on their computer that could be misused. Always in the hope that manufacturers of software always fix in their updates also security flaws. Microsoft, for example, has imposed an update requirement on its users since the introduction of Windows 10. Basically, the idea was well-founded. Because unpatched operating systems allow hackers easy access. So the thought: ‘Latest is greatest’ prevailed a very long time ago.

Windows users had little leeway here. But even on mobile devices like smartphones and tablets, automatic updates are activated in the factory settings. If you host an open source project on GitHub, you will receive regular emails about new versions for the libraries used. So at first glance, this is a good thing. However, if you delve a bit deeper into the topic, you will quickly come to the conclusion that latest is not always the best.

The best-known example of this is Windows 10 and the update cycles enforced by Microsoft. It is undisputed that systems must be regularly checked for security problems and available updates must be installed. That the maintenance of computer systems also takes time is also understandable. However, it is problematic when updates installed by the manufacturer paralyze the entire system and a new installation becomes necessary because the update was not sufficiently tested. But also in the context of security updates unasked function changes to the user to bring in I consider unreasonable. Especially with Windows, there are a lot of additional programs installed, which can quickly become a security risk due to lack of further development. That means with all consequence forced Windows updates do not make a computer safe, since here the additionally installed software is not examined for weak points.

If we take a look at Android systems, the situation is much better. However, there are enough points of criticism here as well. The applications are updated regularly, so the security is actually improved significantly. But also with Android, every update usually means functional changes. A simple example is the very popular Google StreetMaps service. With every update, the map usage becomes more confusing for me, as a lot of unwanted additional information is displayed, which considerably reduces the already limited screen.

As a user, it has fortunately not yet happened to me that application updates on Android have paralyzed the entire phone. Which also proves that it is quite possible to test updates extensively before rolling them out to users. However, this does not mean that every update was unproblematic. Problems that can be observed here regularly are things like an excessively increased battery consumption.

Pure Android system updates, on the other hand, regularly cause the hardware to become so slow after almost two years that you often decide to buy a new smartphone. Although the old phone is still in good condition and could be used much longer. I have noticed that many experienced users turn off their Android updates after about a year, before the phone is sent into obsolescence by the manufacturer.

How do you get an update muffler to keep his systems up to date and secure? My approach as a developer and configuration manager is quite simple. I distinguish between feature update and security patch. If you follow the semantic versioning in the release process and use a branch by release model for SCM systems like Git, such a distinction can be easily implemented.

But I also dedicated myself to the question of a versionable configuration setting for software applications. For this, there is a reference implementation in the project TP-CORE on GitHub, which is described in detail in the two-part article Treasue Chest. After all, it must be clear to us that if we reset the entire configuration made by the user to factory settings during an update, as is quite often the case with Windows 10, quite unique security vulnerabilities can arise.

This also brings us to the point of programming and how GitHub motivates developers through emails to include new versions of the libraries used in their applications. Because if such an update is a major API change, the problem is the high migration effort for the developers. This is where an also fairly simple strategy has worked for me. Instead of being impressed by the notifications about updates from GitHub, I regularly check via OWASP whether my libraries contain known risks. Because if a problem is detected by OWASP, it doesn’t matter how costly an update can be. The update and the associated migration must be implemented promptly. This also applies to all releases that are still in production

However, one rule of thumb applies to avoid update hell from the start: Only install or use what you really need. The fewer programs are installed under Windows and the fewer apps there are on the smartphone, the fewer security risks there are. This also applies to program libraries. Less is more from a security perspective. Apart from that, we get a free performance measurement by dispensing with unnecessary programs.

Certainly, for many private users the question of system updates is hardly relevant. Only new unwanted functions in existing programs, performance degradations or now and then shot operating systems cause more or less strong displeasure. In the commercial surrounding field quite fast substantial costs can develop, which can affect also the straight implementing projects negatively. Companies and people who develop software can improve user satisfaction considerably if they differentiate between security patches and feature updates in their release publications. And a feature update should then also contain all known security updates.

Grazer Linux Tage 2019

April 27, 2019 All day

Challenges to create your own Open Source Project

Den eigenen Source-Code auf GitHub zu veröffentlichen ist ein erster Schritt zum eigene Open-Source-Projekt. Aber bei weitem nicht der einzige.

  • das kleine Lizenz 1×1
  • Promotion on GitHub
  • Veröffentlichungen auf Maven Central
  • Continuous Integration in the Cloud – Travis CI
  • Public Code Coverage with Coveralls

Neben diesen Themen werden viele kleine Aspekte, die sich im Rahmen eines Projektes ergeben, angeschnitten. In Zusammenarbeit mit: KreativgeistAT