Telemetrie-Daten helfen dem Entwickler einer Software, diese zu verbessern. Die Erhebung von Telemetrie-Daten in Firefox war bereits optional. Ab Firefox 72 lässt Mozilla Nutzer von Firefox mit der Deaktivierung von Telemetrie auch die bereits erhobenen Daten löschen.

Mit dem 1. Januar 2020 ist in Kalifornien das neue Datenschutz-Gesetz, California Consumer Privacy Act (CCPA), effektiv in Kraft getreten. Durch CCPA werden die Rechte der Menschen in Kalifornien gestärkt, was den Umgang mit deren Daten durch Unternehmen ab einer bestimmten Größe betrifft. Dies schließt auch ein, dass Nutzer nicht nur ein Recht darauf haben, zu erfahren, welche persönlichen Informationen gespeichert werden, sondern auch, diese löschen zu lassen.

In diesem Zusammenhang hat Mozilla nun angekündigt, Verbesserungen im Umgang mit den in Firefox erhobenen Telemetrie-Daten ab Firefox 72 auszuliefern – nicht nur für Nutzer in Kalifornien, sondern überall auf der Welt.

Die Telemetrie-Daten von Firefox beinhalten keine Informationen über besuchte Websites oder durchgeführte Suchen, sondern sind überwiegend technische Informationen. Beispiele sind neben Angaben zum System die Anzahl geöffneter Tabs oder die Dauer von Sitzungen. Die Telemetrie-Daten helfen dabei, Firefox für die Mehrheit der Nutzer zu optimieren und Probleme festzustellen. In privaten Fenstern werden keine Telemetrie-Daten erhoben und auch ein Abschalten der Telemetrie-Funktion ist in Firefox schon immer möglich gewesen.

Zwar fallen die von Mozilla erhobenen Telemetrie-Daten nicht unter persönliche Informationen und sind damit durch CCPA nicht betroffen und auch speichert Mozilla die erhobenen Daten grundsätzlich nur zeitlich begrenzt und nicht für immer. Dennoch sieht es Mozilla als den richtigen Schritt, dem Grundgedanken des CCPA zu folgen und dem Nutzer das Recht auf Löschung der Daten weiterzugeben.

So wird mit dem Deaktivieren der Telemetrie-Funktion ab Firefox 72 nicht länger nur die Telemetrie-Funktion abgeschaltet. Gleichzeitig wird damit zukünftig eine Anfrage an Mozilla gesendet, die erhobenen Daten des anfragenden Nutzers zu löschen. Dieser Anfrage möchte Mozilla innerhalb von 30 Tagen nachkommen.

Firefox 72 wird am 7. Januar 2020 erscheinen.

Der Beitrag Mozilla lässt Firefox-Nutzer bereits erhobene Telemetrie-Daten löschen erschien zuerst auf soeren-hentzschel.at.

Urlaubszeit ist bei mir Bastelzeit. Daher bin ich gerade dabei mal wieder VSCode zu testen, obwohl ich mir vorab schon sicher bin, dass ich bei Sublime Text bleiben werde. Naja egal, darum geht es gerade nicht.

Damit ich relativ bequem Artikel veröffentlichen kann, habe ich mir unter Sublime Text diverse Snippets angelegt. Bei einem geht es darum, dass ich Text markiere und per Shortcut der HTML-Code hinzugefügt wird mit dem ich Text als Code hervorhebe. Somit wird zum Beispiel aus “10 PRINT “hallo welt” folgendes.

<pre class="line-numbers language-bash" style="white-space:pre-wrap;">
<code class="language-bash">10 PRINT "hallo welt"</code>
</pre>

Unter VSCode habe ich mir folgendes Snippet angelegt.

"wrap_highlight": {
		"prefix": "wrap_highlight",
		"body": [
			"<pre class="line-numbers language-bash" style="white-space:pre-wrap;">",
			"<code class="language-bash">$TM_SELECTED_TEXT</code>",
			"</pre>"
		],
		"description": "Highlight Code"
	},

Sieht eigentlich ganz gut aus, macht aber nicht was es soll. Denn als Ausgabe erhält man folgendes.

<pre class=
 style=
<code class=
>10 PRINT "hallo welt"</code>
</pre>

Die Lösung ist in dem Fall allerdings recht einfach. Die Ursache ist die fehlende Maskierung (auch escapen genannt) der Anführungszeichen innerhalb des Bereichs “body”.

"wrap_highlight": {
		"prefix": "wrap_highlight",
		"body": [
			"<pre class=\"line-numbers language-bash\" style=\"white-space:pre-wrap;\">",
			"<code class=\"language-bash\">$TM_SELECTED_TEXT</code>",
			"</pre>"
		],
		"description": "Highlight Code"
	},

Ändert man das Snippet wie oben angegeben macht es auch das was es soll.

In meinem Netzwerk tut schon länger eine Pi-hole-Installation ihren Dienst. Bis vor wenigen Wochen noch auf einem eigenen Raspberry Pi, läuft dieser nun auf einer kleinen virtuellen Maschine auf meinem Synology NAS.

Pi-hole lässt sich bekannterweise sehr angenehm über das eigene Webinterface steuern. Was an mir allerdings komplett vorbeigegangen ist, ist die Möglichkeit, dass sich Pi-hole auch per Shortcuts App unter iOS bedienen lässt. Somit kann man z.B. per Share Sheet auch auf kurzem Wege Websiten white- oder blacklisten.

Alex vom iPhoneBlog hat darüber geschrieben und auch gleich zwei Varianten verlinkt.

Aufgrund eines Fehlers macht der erste Shortcut zur Zeit noch Probleme, ein Update soll allerdings zeitnah kommen.

Für mich funktioniert allerdings auch der zweite Shortcut ohne Probleme. Dieser nutzt, anders als der erste Shortcut nicht die API von Pi-hole sondern läuft per SSH. Hier jedoch einmal der gut gemeinte Hinweis. iOS selbst, warnt beim hinzufügen eines Shortcuts aus unbekannten Quellen. Nehmt euch diese Warnung zu Herzen und prüft den Shortcut auf Unregelmäßigkeiten bevor ihr eure SSH-Daten im Punkt "Run script over SSH" hinterlegt.

Es ist Jahresende und somit wieder Zeit, auf das vergangene Jahr zurückzuschauen. In diesem Jahr habe ich in meinem Blog weitaus weniger experimentiert. In meinen 32 Blogartikeln (diesen nicht eingerechnet) habe ich mich ausschließlich mit technischen Themen auseinandergesetzt. Auf der anderen Seite habe ich andere Projekte ausgebaut, darunter mein Wiki, den Videokanal oder LatestVersionOf.com.

In diesem Sinne bedanke ich mich bei allen, die meinen Blog, meine Videos oder mein Wiki lesen, anschauen, kommentieren oder teilen.

Normalerweise folgt im Jahresrückblick an dieser Stelle eine Statistik zum Blog – nur ist diese schwierig zu erstellen, da ich in diesem Jahr aufgrund von u.a. dem „Cookie-Urteil“ die Analytics so eingedämmt habe, dass keine realitätsnahen Zahlen herauskommen, sondern nur ein grobes Bild sichtbar wird. Zudem beachte ich schon seit (soweit ich mich erinnern kann) Anbeginn der Messungen die DNT-Flags, von da aus ist es bei einem fachnahen und datenschutzbewussten Publikum sowieso schwer, Zahlen zu ermitteln. In den Analytics komme ich jedenfalls auf 37.000 Pageviews dieses Jahr. Welchen Faktor ihr jetzt hierauf multipliziert, bleibt euch überlassen. Zum Vergleich: ein wc -l auf eine von HEAD-Requests und Bot-User Agents bereinigten Logdatei kommt an einem normalen Tag auf etwa 3.000 Requests, was hochgerechnet sich im Jahr auf 1 Mio. Hits summiert.

Gefühlt am beliebtesten sind und bleiben jedoch die Artikel über Let's Encrypt und ISO-Dateien. Tipps & Tricks sowie How-Tos haben weiterhin Hochkonjunktur. Muss ich mir für nächsten Jahr merken.

Heute am 31. Dezember 2019 endet nicht nur das Jahr, sondern auch eine Dekade. Die 2010er sind geprägt von vielen Ereignissen. Der verlinkte Wikipedia-Artikel gibt euch einen groben Überblick, was so alles passiert ist. Aus meiner Sicht gab es in der Technologiewelt keine so einschneidenden Innovationen, wie sie die 1990er und 2000er hervorgebracht haben. Eher wurden bestehende Technologien verbessert, professionalisiert und sind vor allen Dingen in der Gesellschaft angekommen. Bestes Beispiel YouTube: war es 2009 noch das „Clipportal“ unter dem Motto „Broadcast yourself“, so wurde es heute zur regulierten (siehe Content ID, etc.) Medienplattform. Längst haben sich Netzwerke unter Kanälen (Stichwort MCN) gebildet und selbst die öffentlich-rechtlichen haben die Content-Netzwerke entdeckt. Dieser Prozess hat natürlich auch Vorteile: so führt die Suche nullstellen berechnen qudratische funktion zu einem nie vorher dagewesenen Angebot von Lernvideos. Und gerade die „Größen“ in einem Genre ermöglichen durch ihren Wiedererkennungswert samt Marke ein gewohntes Umfeld. Die Zeit des Aufbruchs und des Inkubators für eine neue Idee ist allerdings damit auch zu Ende – in diesem Bereich.

In der IT-Welt sind auch viele Änderungen passiert. Die bestehende Virtualisierungstechnik wurde genommen, auf Container angepasst und mit einem Ökosystem garniert: Docker (2013) war erschaffen. Wenig später dann die Professionalisierung: Kubernetes (2014). Ähnlich mit Provisionierung: hier kommt niemand, der effektiv orchestrieren will, um Ansible (2012), Salt (2011) oder Puppet (2005) herum.

So könnte man stundenlang verschiedenste Themen aufzählen. Aber um sich die Veränderung besser vor Augen zu führen, habe ich mal in der Wayback Machine einige bekannte Seiten wie tagesschau.de, google.com, youtube.com, bundestag.de, de.wikipedia.org, apple.com, microsoft.com, kernel.org oder sourceforge.net (und seinen kleinen Rivalen github.com) herausgesucht. Feel old yet?

Was steht nun also für das neue Jahrzehnt an? Gesellschaftliche Veränderungen und Probleme spiegeln sich nun auch in der Technik wieder - mehr als je zuvor. Ressourcenorientierung tritt nach 15 Jahren wieder in den Vordergrund, um größere Technologiesprünge zu ermöglichen. Ich sag's euch, C wird wieder an Bedeutung gewinnen! ;)

Genug big picture. Mein Angebot versuche ich im anstehenden Jahr ein wenig weiter auszubauen und zusammenzuführen, so sind viele How-To-Artikel schon dieses Jahr ins Wiki ausgelagert worden, da sie dort viel schneller gefunden werden können und sich thematisch statt chronologisch sortieren lassen.

Wir werden schon sehen, was das neue Jahr(zehnt) bringt, aber für heute wünsche ich euch einen guten Rutsch!

Abschließend möchte ich euch heute noch den Vortrag BahnMining - Pünktlichkeit ist eine Zier (YT) von David Kriesel ans Herz legen, der neben einem interessanten Einblick in die Welt der Data Science auch mit einem Rückblick auf die Dekade samt Wunsch für das neue Jahrzehnt schließt.

PS: heute Nacht läuft der Python 2-Support aus. PPS: denkt an eure Footer!

New Tab Override ist eine Erweiterung zum Ersetzen der Seite, welche beim Öffnen eines neuen Tabs in Firefox erscheint. Die beliebte Erweiterung ist nun in Version 14.4 erschienen.

Was ist New Tab Override?

Die Erweiterung New Tab Override erlaubt das Überschreiben der Seite, welche beim Öffnen eines neuen Tabs in Firefox erscheint. Dies kann eine beliebige Website, immer automatisch die aktuelle Startseite, eine lokale Datei, eine Hintergrundfarbe oder die neusten Nachrichten von diesem Blog sein.

New Tab Override war das erste Add-on, welches das Überschreiben des neuen Tabs ermöglichte, und ist damit das Original. Die Erweiterung mit knapp 100.000 Nutzern wurde im Dezember 2016 auf dem offiziellen Mozilla-Blog vorgestellt, schon mehrfach im Add-on Manager von Firefox beworben und gehört seit diesem Jahr außerdem zu Mozillas handverlesener Auswahl empfohlener Erweiterungen.

Download New Tab Override für Firefox

Die Neuerungen von New Tab Override 14.4

New Tab Override 14.4 ist das letzte Wartungs-Update der Erweiterung im Jahr 2019.

Ab dieser Version steht die Erweiterung auch in Russisch und damit nun insgesamt zwölf Sprachen zur Verfügung.

Mit dem Update wird nicht länger die Berechtigung zum Lesen der Cookies benötigt. Es handelt sich bei dieser Berechtigung um ein Überbleibsel eines Code-Pfades, der seit New Tab Override 14.3 nicht länger genutzt wird, womit es auch nicht länger notwendig ist, diese Berechtigung zu erfordern.

Basierend auf Feedback von Mozilla wurde die Kurzbeschreibung der Erweiterung sowie die ausführliche Beschreibung auf addons.mozilla.org überarbeitet.

Das in der Erweiterung angezeigte Copyright-Jahr wurde von 2019 auf 2020 geändert und ein veralteter Methoden-Aufruf gegen den empfohlenen Ersatz ausgetauscht. Außerdem wurde Mozillas Tool web-ext zum Kompilieren der Erweiterung von Version 3.1.0 auf Version 4.0.0 aktualisiert.

Der Beitrag New Tab Override 14.4 veröffentlicht erschien zuerst auf soeren-hentzschel.at.

Beim Privacy-Handbuch hat man sich die Arbeit gemacht und in zwei Artikel Matrix/Riot und Jabber/XMPP hinsichtlich der Sicherheitskonzepte überprüft. Beim Jabber/XMPP wird als Maßstab ausdrücklich Signal und Threema angelegt, bei Matrix/Riot zumindest unterschwellig. Beides lohnt sich zu lesen.

Bei beiden werden strukturelle Schwächen im Sicherheitskonzept ausgemacht. Das ermöglicht nicht nur Man-in-the-middle-Angriffe, sondern es gibt auch Datenschutz-Probleme wie unverschlüsselte Kontaktlisten, Gruppenmitgliedschaften etc. pp. auf den Servern. Ein Punkt, den man bei WhatsApp so gerne kritisiert. Im Fall von Jabber kritisieren sie beim Privacy-Handbuch auch die zusammen gestückelte Verschlüsselung (ich hatte hier schonmal darüber geschrieben: Dezentralisierte Dienste - Zu spät, zu kompliziert, zu fragmentiert).

Eine strukturelle Schwäche liegt einfach im föderalen Ansatz beider Protokolle. Dieser verhindert nicht nur systembedingt einige Sicherheitsmaßnahmen, sondern setzt z. B. bei Matrix/Riot auch Vertrauen in alle anderen Server-Betreiber voraus.

Beide Artikel sind auch deshalb lesenswert, weil in Teilen der Datenschutz-Szene und Open Source Community beide Protokolle als vermeintlich sichere Alternativen zu den klassischen Messengern hoch geschrieben werden. Hier fällt eine nicht Fakten-basierte Vermengung von Open Source-Begeisterung mit einem Faible für dezentrale Ansätze und Sicherheits-Illusionen zusammen. Dies kann man leider sehr oft beobachten, wenn Open Source und Eigenbetrieb pauschal mit Sicherheit gleich gesetzt werden (siehe auch: Kommentar: Der fatale Glaube an Open Source).

Ganz ähnlich ist das mit Telegram, dessen Popularität sich eigentlich nur aus der Halbwahrheit es sei Open Source speist und der Möglichkeit Clients für jede noch so kleine Nischenplattform zu entwickeln. Kurioserweise führte beides zu der weit verbreiteten Annahme Telegram sei in irgendeiner Form sicherer als die proprietären Alternativen (siehe: Kommentar: Telegram ist unsicher - welch Überraschung).

Die strukturellen Probleme bedeuten nicht, dass Matrix/Riot oder XMPP keine Grundlage für sinnvolle Entwicklungen seien können. So testet die Bundeswehr momentan Matrix und die französische Regierung machte dies bereits erfolgreich vor. Beide werden allerdings kaum den föderalen Ansatz unterstützen. Privatanwender sollten weiterhin auf Signal (wenn Open Source) oder Threema zurückgreifen (siehe auch: Sichere Messenger - Verschlüsselung und Metadaten). Beides ist nach aktueller Erkenntnislage sicherer als Matrix und XMPP.

Bilder:
Einleitungs- und Beitragsbild von geralt via pixabay

Passend zum Jahresende hat Debian die Abstimmungsergebnisse zur systemd-Befragung bekannt gegeben. Das Jahr 2019 endet damit für Linux insgesamt erfreulich, weil einmal mehr eine lautstarke Minderheit in die Schranken gewiesen wurde, die in Foren und Kommentarspalten im übertragenen Sinne "Wir sind das Volk" ruft.

Die Abstimmung war - wie bei Debian üblich - sehr kompliziert. Das Ergebnis ist aber dennoch eindeutig: Debian bleibt bei systemd, andere Init-Systeme sind erlaubt aber die Maintainer sind nur zur Unterstützung von systemd verpflichtet und können dieses voll ausreizen. Anders gesagt: Wer andere Init-Systeme will soll bitte die Arbeitskraft und -zeit investieren. Das Ergebnis fällt noch eindeutiger aus, wenn man berücksichtigt, dass der zweite Platz an die radikale Variante nur systemd zu unterstützen ging.

Im November hatte das openSUSE Projekt in einer thematisch anders gelagerten Abstimmung ebenfalls eine lautstarke Minderheit in die Schranken verwiesen, die eine von FSF-Idealen geleitete Umbenennung anstrebte. Eine Minderheit, die in einer vorangegangenen Diskussion nicht in die Schranken gewiesen werden konnte.

Vor ein paar Wochen hatte ich mir zudem die Mühe gemacht mal die Desktopnutzung in Zahlen darzustellen (siehe: Entwicklungen am Linux Desktop in Zahlen). Mit dem Ergebnis, dass eine große Mehrheit immer noch das so geschmähte GNOME nutzt und nicht den so oft angepriesenen minimalistischen Alternativen nachrennt.

Die eindeutigen Abstimmungsergebnisse und Zahlen zeigen - so unterschiedlich die Inhalte waren - dass eine lautstark pöbelnde Minderheit (siehe: Kommentar: Verschwörungen, Ressentiments, Reaktionärer Konservativsmus) sich in den Diskussionskanälen aufbläst und radikale Entscheidungen einfordert bzw. Veränderungen ablehnt, in Abstimmungen aber meilenweit von Mehrheitsfähigkeit entfernt ist. Etwas abgelehnt an den Aufruf von David Kriesel zu mehr Zahlen und weniger Aufregung. Das ist eine schöne Nachricht zum Jahresabschluss und gibt Hoffnung für den Linux Desktop.

Bilder:
Einleitungs- und Beitragsbild von qimono via pixabay

Letzter Selbsttest:

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed: read failure       90%     58160         1050014
# 2  Extended offline    Completed without error       00%     55855         -

​wie gewünscht haben wir die defekte Festplatte mit der S/N: xxxxx für Sie ausgetauscht.
Leider haben wir momentan keine 3 TB Enterprise HDDs mehr im Lager,
daher haben Sie von uns eine 4 TB Enterprise HDD bekommen.

Als ich nach wenigen Minuten nach dem Einbau der Platte die Partitionierung durchführte und gerade dem Raid wieder die neuen Partionen hinzufügen wollte, stand der Server.

Es half nur ein manueller Hardware Reset, der bei Hetzner nach wenigen Minuten durchgeführt wurde.

Ursache war

wie gewünscht haben wir Ihren Server überprüft, es schien wohl ein Problem mit der neuen HDD 
im Zusammenspiel mit der alten BIOS-Version auf dem Server zu bestehen.

Wir haben die BIOS-Version auf die aktuellste von uns geprüfte und freigegebene Version 
aktualisiert und den Server ins installierte System starten lassen.

Tja so ist das eben. Naja, Downtime unter 30 Minuten, das Raid synct natürlich noch...

Heute wurde der Server von Stretch auf Buster angehoben.

Caveats:

Bei Dovecot hat sich eine Sache in der dovecot.conf Syntax geändert.

Gut beschrieben ist es hier: https://b4d.sablun.org/blog/2019-02-25-dovecot_2.3_upgrade_on_debian/

Weil ich ispconfig benutze, wurde das auch gleich upgegradet auf 3.1.15p2.

Dabei festgestellt, dass ich noch die diversen php7.3 pakete nachinstallieren musste.

Ich habe auch confluence laufen, also Java und tomcat gedöns. Deshalb ist postgres installiert, welches ein 

postgres reindexdb --all

benötigt. (Man wird aber darauf hingewiesen)

Mal sehen, was es noch für Probleme gibt ...

Ändert Subject auf „[Tag] Altes-Subject“ und fügt einen Reply-To „moo@moo.com“ hinzu.

Die alten Headerfelder werden vorher entfernt.

Nur ein Snippet.

remove_headers { X = 0 } sollte alle Header entfernen, nicht nur den ersten. Beim Subject und Reply-To eher unnötig.

rspamd_config:register_symbol({
  name = 'SUBJECT_REWRITE_ADD_HEADER',
  type = 'postfilter',
  callback = function(task)
    local util = require("rspamd_util")
    local rspamd_logger = require "rspamd_logger"
    local mailcow_domain = task:get_symbol("RCPT_MAILCOW_DOMAIN")
    if mailcow_domain then
      local tag = "Tag"
      rspamd_logger.infox("add fancy list header")
      local sbj = task:get_header('Subject')
      new_sbj = '=?UTF-8?B?' .. tostring(util.encode_base64('[' .. tag .. '] ' .. sbj)) .. '?='
      task:set_milter_reply({
        remove_headers = {
          ['Subject'] = 1,
          ['Reply-To'] = 1,
        },
        add_headers = {
          ['Subject'] = new_sbj,
          ['Reply-To'] = 'moo@moo.com'
        }
      })
    end
  end,
  priority = 11
})

Hilfreiche URLs und Links

1. Die Liste der Vorträge als Zeitleiste https://fahrplan.events.ccc.de/congress/2019/Fahrplan/timeline.html
2. Lighning Talks https://events.ccc.de/congress/2019/wiki/index.php/Static:Lightning_Talks#Schedule
3. 36c3 Wiki https://events.ccc.de/congress/2019/wiki/index.php/Main_Page
4. Übersicht der Live Streams https://streaming.media.ccc.de/36c3/
5. Relive Streams (zum Zeitversetzten Anschauen) https://streaming.media.ccc.de/36c3/relive
6. Releases - die fertig geschnittenen und veröffentlichten Talks https://media.ccc.de/c/36c3
7. Releases auf Youtube (Playlist) https://www.youtube.com/playlist?list=PL_IxoDz1Nq2YqJxtjfil-D6rvkwoR1qve
8. 36C3 Videos auch als Torrent bei https://archive.org/search.php?query=subject%3A%2236c3%22
9. Livestream von Chaos West https://live.chaoswest.tv/

Empfehlenswerte Talks
Solange die entgültige Stream URL nicht bekannt ist, steht hier nur “Stream URL” und man findet die Streams bei den realive Streams.

1. Opening Ceremony [Beschreibung] - https://media.ccc.de/v/36c3-11223-opening_ceremony
2. The Internet of rubbish things and bodies [Beschreibung] - https://media.ccc.de/v/36c3-11236-the_internet_of_rubbish_things_and_bodies
   Presentation of the movie “2050″ by Lupashko Alexandra
3. What the World can learn from Hongkong [Beschreibung] - https://media.ccc.de/v/36c3-10933-what_the_world_can_learn_from_hongkong
4. Vom Ich zum Wir - Gesellschaftlicher Wandel in den Reden im Bundestag - https://media.ccc.de/v/36c3-10993-vom_ich_zum_wir
5. Der dezentrale Jahresrückblick des CCC - https://media.ccc.de/v/36c3-11225-der_dezentrale_jahresruckblick_des_ccc
6. Jahresrückblick des Peng! Kollektivs - Hacking the Media: Geflüchtete schmuggeln, Nazis torten, Pässe fälschen. Warum wir zivilen Ungehorsam und Subversion mehr brauchen denn je https://media.ccc.de/v/36c3-10541-hacking_the_media_gefluchtete_schmuggeln_nazis_torten_passe_falschen
7. Das nützlich-unbedenklich Spektrum. Können wir Software bauen, die nützlich /und/ unbedenklich ist? https://media.ccc.de/v/36c3-10608-das_nutzlich-unbedenklich_spektrum
8. [36C3] The ecosystem is moving - Moxie Marlinspike (wurde aus der Mediathek und Youtube gelöscht. Moxie wollte nicht, dass der Talk aufgenommen wird. Hier sind auch noch interessante Hintergründe zu dem Thema https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom/ ) https://peertube.co.uk/videos/watch/12be5396-2a25-4ec8-a92a-674b1cb6b270
9. WRINT Politikunterricht - Die Lernzielkontrolle - https://media.ccc.de/v/36c3-113-wrint-politikunterricht-die-lernzielkontrolle
10. Mehr als ein Hobby? Deutschsprachige Podcaster*innen im Fokus psychologischer Forschung. - https://media.ccc.de/v/36c3-108-mehr-als-ein-hobby-deutschsprachige-podcaster-innen-im-fokus-psychologischer-forschung-
11. Let’s play Infokrieg - Wie die radikale Rechte (ihre) Politik gamifiziert https://media.ccc.de/v/36c3-10639-let_s_play_infokrieg
12. Das Mauern muss weg - Best of Informationsfreiheit - https://media.ccc.de/v/36c3-10496-das_mauern_muss_weg
13. Hackers & makers changing music technology - https://media.ccc.de/v/36c3-10548-hackers_makers_changing_music_technology
14. DOT. The LED Cube - https://media.ccc.de/v/36c3-oio-191-dot-the-led-cube
15. “Hacker hin oder her": Die elektronische Patientenakte kommt! - https://media.ccc.de/v/36c3-10595-hacker_hin_oder_her_die_elektronische_patientenakte_kommt
16. Was tun bevor es brennt - wie gründe ich eigentlich einen Betriebsrat? - https://media.ccc.de/v/36c3-10600-was_tun_bevor_es_brennt_-_wie_grunde_ich_eigentlich_einen_betriebsrat

Tools

1. 36c3 Fahrplan (Android) gPlay - Fdroid
2. Chaos Flix - Vorträge auf dein Android Streamen https://github.com/NiciDieNase/chaosflix

…wird während des Kongresses stetig erweitert …

Vor gut einer Woche ist Rust 1.40 erschienen. Im heutigen Artikel gehe ich kurz auf die Hauptänderung ein.

Überblick

Das gesamte Changelog ist in der RELEASES.md einzusehen. Highlights sind das #[non_exhaustive] Attribut sowie weitere Verbesserungen für andere Makros und Attribute wie z.B. dem neuen todo!() oder Makros in extern-Blöcken.

Das non-exhaustive Attribut

Wie oben schon geschrieben, ist das "Highlight" des Releases die Einführung des non-exhaustive-Attributes, um Aufwärtskompatibilität sicherzustellen. Es erzwingt, dass immer ein sonst/else/default-Fall definiert werden muss, um die Fallunterscheidung auszuschöpfen. Und da das so kompliziert klingt, hier ein Beispiel:

enum DebianVersion {
    Debian9,
    Debian10
}

fn main() {
    let deb_version = DebianVersion::Debian9;

    match deb_version {
        DebianVersion::Debian9 | DebianVersion::Debian10 => {
            println!("Debian is used!");
        }
    }
}

Dieses kleine Programm besteht aus zwei wichtigen Komponenten, die für unser Beispiel wichtig sind: einem enum, das eine Reihe von Debian-Versionen definiert und einem match-Blöck, das Pattern Matching durchführt und mit einem switch-Blöck aus C vergleichbar ist. Eine Eigenschaft ist, dass ein solches Pattern Matching exhaustive sein muss: alle möglichen Fälle eines enums müssen abgedeckt sein. Das ist ein Feature, das mir an Rust besonders Spaß macht, da man im Vorhinein alle Fälle durchdenken muss.

Schwierigkeiten entstehen aber, wenn das Enum möglicherweise gar nicht in der eigenen Verantwortung liegt und durch ein Crate, eine Library, bereitgestellt wird. Wird nämlich dann ein neues EnumItem (z.B. Debian11) hinzugefügt, bricht der match-Blöck, da dieser dann nicht mehr alle Fälle abdeckt. Auf der Implementierungsseite kann man dies i.d.R. durch den _-Fall umgehen, der für alle anderen Fälle steht. (vgl. default aus C) Sieht dann umgesetzt so aus:

#[non-exhaustive]
enum DebianVersion {
    Debian9,
    Debian10
}

fn main() {
    let deb_version = DebianVersion::Debian9;

    match deb_version {
        DebianVersion::Debian9 | DebianVersion::Debian10 => {
            println!("Debian is used!");
        }
        _ => {
            println!("Another Debian version is used!");
        }
    }
}

Fällt euch was auf? Ich habe nicht nur den else/default-Fall abgdeckt, sondern auch zusätzlich das neue Attribut bereits im Quellcode untergebracht. Denn während die Implementierung jederzeit den else/default-Fall abdecken kann (oder eben auch nicht), wird das neue Attribut (jetzt noch nicht, aber bald) diesen Fall erzwingen.

Firefox erlaubt bereits seit vielen Jahren das Vergrößern oder Verkleinern von Websites. Wer allerdings eine Standard-Zoomstufe für alle Websites festlegen wollte, war bislang auf eine Erweiterung angewiesen. Ab Firefox 73 ist dies ein Standard-Feature von Firefox.

Das Zoom-Feature von Firefox erlaubt die Vergrößerung oder Verkleinerung ganzer Websites oder nur des Textes von Websites. Die eingestellte Zoom-Stufe merkt sich Firefox auch sitzungsübergreifend – allerdings nur für die Website, für welche der Zoom aktiviert worden ist.

Wer die Vergrößerung oder Verkleinerung standardmäßig für alle Websites vornehmen wollte, brauchte hierfür bisher eine Erweiterung wie NoSquint Plus oder Default Zoom.

Ab Firefox 73 ist hierfür nicht länger eine Erweiterung notwendig. Mozilla hat eine neue Option für die Standard-Zoomstufe in die Firefox-Einstellungen integriert. Dabei sind Werte zwischen 30 und 300 Prozent möglich. Auch ob alles oder nur der Text verkleinert oder vergrößert werden soll, lässt sich einstellen.

Natürlich ist es auch mit dieser neuen Option weiterhin möglich, für einzelne Websites eine abweichende Zoom-Einstellung auszuwählen.

Firefox 73 erscheint nach aktueller Planung am 11. Februar 2020.

Der Beitrag Firefox 73 bekommt Einstellung für Standard-Zoom erschien zuerst auf soeren-hentzschel.at.

Oft huschen durch meinen Twitter-Feed ganz interessante Beiträge mit Tipps & Tricks (oder nennt man das nicht schon neumodisch "lifehacks"? – egal). Ein Tipp, den ich euch nicht vorenthalten kann, betrifft diesmal LibreOffice Writer.

Sollen in einem Dokument Absätze verschoben werden, ist das gerne lästige Arbeit. Markieren, Ctrl + X, Ctrl + V. Aber LibreOffice kann das auch einfacher: Ctrl + Alt + arrow up/arrow down. Das Feature kenne ich schon von IntelliJ (hier ist die Kombination Ctrl + Shift + arrow up/arrow down) und möchte es ehrlich gesagt nicht mehr missen.

Einfach mal ausprobieren!

Update (19.12.2019, 14:35 Uhr): wie ich gerade in den Kommentaren höre, liegt auf der gleichen Tastenkombination je nach Desktop Environment eine höherpriorisierte Tastenkombination vom System (GNOME Arbeitsflächen, etc.). (Das fiel mir anfangs nicht auf, da ich auf meinem System viele Tastenkombinationen umgestellt habe.) Hier ist es natürlich sinnvoller, die LibreOffice Tastenkombination (die ich ehrlich gesagt auch nicht an der Stelle so mag, die von IntelliJ gefällt mir da besser) zu ändern. Das geht unter Extras → Anpassen → Tab "Tastatur". Die konkrete Umstellung zeigen folgende Screenshots:

Tastenkombination in der oberen Liste auswählen, um mit einem Klick auf "Löschen" das Keybinding zu entfernen. Dann in der unteren Suche "Nach oben verschieben" resp. "Nach unten verschieben" suchen und auswählen, dann oben die gewünschte Tastenkombination auswählen und auf "Ändern" klicken. Ist etwas umständlich und erinnert an GUIs aus den 2000ern, funktioniert im Endeffekt aber. :)

CentOS ist seit Ende Oktober 2019 nicht mehr in der Lage, Updates für CentOS 8 zur Verfügung zu stellen (siehe CentOS 8: Sechs Wochen ohne Updates). Von CentOS 8.1 ist keine Spur, auf der Statusseite ist kein Fortschritt zu erkennen.

Fast noch befremdlicher: Es scheint niemanden zu stören. Google-Suchen nach centos 8 updates missing oder centos 8 no updates liefern kaum relevante Ergebnisse. Weder auf den CentOS-Mailing-Listen noch im CentOS-Forum ist das mehrwöchige Ausbleiben von Updates ein Thema. Ist CentOS 8 ganz einfach noch nicht bei den Anwendern angekommen? Oder ist es tot und nur ich habe es nicht bemerkt?

Kostenlose Alternativen zu RHEL 8 gibt es nicht viele. Scientific Linux wird nur noch für Version 7 gepflegt, eine Version 8 wird es nicht geben. Damit bleibt eigentlich nur Oracle. Die Firma bietet ihren Red-Hat-Klon unter dem Namen »Oracle Linux« sowohl kostenlos als auch kommerziell an. Zahlende Kunden erhalten Support und Zugang zu Kernel-Live-Patches.

Oracle Linux

Oracle Linux ist zwar kostenlos verfügbar, Oracle macht den Download der Installationsdateien aber nicht besonders leicht: Zuerst müssen Sie sich einen (kostenlosen) Oracle-Account einrichten. Nach dem Login können Sie auf der Oracle Software Delivery Cloud anmelden. Dort suchen Sie nach Oracle Linux und geben die Version 8.1 in eine Art Einkaufswagen. (Keine Angst, Sie müssen beim Check-Out nichts bezahlen.)

Im Checkout bestätigen Sie die Auswahl, wobei Sie sich von der Größe von fast 20 GByte nicht beeindrucken lassen. Sie müssen nun die Oracle Standard Terms and Restrictions, die durchaus irritierend von einer 30-tägigen Testzeit sprechen. Laut Oracle Blog ist die Nutzung von Oracle Linux nämlich ohne Restriktionen kostenlos und keineswegs auf einen Testzeitraum limitiert. Im nächsten Schritt können Sie endlich angeben, dass Sie nur das ISO-Image herunterladen wollen. Wäre das nicht einfacher gegangen?

Update: In der Tat geht es einfacher, man nehme einen Mirror, z.B. https://mirror.netcologne.de/oracle-linux/OL8/u1/x86_64/. Danke an alle, die die Kommentarfunktion nutzen!

Ist die Download-Hürde einmal genommen, verläuft die Installation exakt gleich wie bei CentOS 8 (und einfacher als beim Original, weil keine Red-Hat-Subskriptionsdaten angegeben werden müssen).

Anders als CentOS hat Oracle den Produktionsprozess im Griff. Oracle Linux 8.1 wurde nur 10 Tage nach RHEL 8.1 freigegeben. Auch die Update-Versorgung klappt vorbildlich: Das am 18.12.2019 von Red Hat veröffentlichte systemd-Update war keine 24 Stunden später bereits in Oracle Linux verfügbar.

Bei meinem eher kurzen Test traten weder Auffälligkeiten noch Probleme auf. Das Einrichten der EPEL-Paketquelle gelang auf Anhieb mit dem folgenden Kommando:

yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm

Versionsnummern

Basis             Desktop             Programmierung   Server
---------------   ------------------  --------------   --------------
Kernel     4.18   Gnome        3.28   bash       4.4   Apache     2.4
glibc      2.28   Firefox ESR    68   gcc        8.3   CUPS       2.2
X-Server   1.20   Gimp          2.8   Java      8/11   MariaDB   10.3
Wayland    1.15   LibreOffice   6.0   PHP        7.2   MySQL      8.0
Mesa       19.1   Thunderbird    68   Python 2.7/3.6   OpenSSH    8.0
systemd     239                                        qemu/KVM  2.12
NetworkMan 1.20                                        Postfix    3.3
GRUB       2.02                                        Samba     4.10

Was gegen Oracle spricht

Oracle ist im Datenbank-Sektor die weltweit führende Firma, das bestreite ich nicht. Im Open-Source-Segment glänzt Oracle nicht so strahlend. Diverse durch Aufkäufe zugeführte Open-Source-Projekte haben ihren Popularitäts-Zenit überschritten, zum Teil sind Forks populärer als das Orignal.

• Java: Geänderte Lizenzbedingungen und halbjährliche Updates erschweren den Einsatz im Unterricht und in nicht-kommerziellen Projekten. Java EE ist in der Krise, Java am Desktop (JavaFX) mausetot. Google setzt für die App-Entwicklung mittlerweile voll auf Kotlin. Als erste Programmiersprache gewinnt Python an Popularität.

• OpenOffice hat jede Bedeutung verloren, die Alternative heißt LibreOffice.

• MySQL: Unstimmigkeiten beim Zugang auf Sicherheits-Updates haben den Linux-Distributoren jahrelang das Leben schwer gemacht und MariaDB enorm zu Popularität verholfen.

Die wohl wichtigste positive Ausnahme ist VirtualBox: Das Virtualisierungssystem ist trotz der Oracle-Übernahme auf allen Plattformen (Windows, macOS und Linux) populärer denn je, wird aktiv und sehr regelmäßig weiterentwickelt und ist auch im Open-Source-Umfeld beliebt.

Fazit: Alles in allem gelingt es mir nicht, Oracle als Open-Source-Vorzeigeunternehmen wahrzunehmen. Und entsprechend schwer fällt es mir, bei der Installation eines neuen Servers (wo ich mich in der Regel auf viele Jahre festlege) gerade auf Oracle zu setzen. Wenn Red-Hat-Kompatibilität kein Muss ist, erscheint mir Ubuntu LTS oder Debian trotz deutlich kürzerer Wartungszeiten die sicherere Alternative zu sein. Was CentOS betrifft, heißt es wohl: Abwarten und Tee trinken. Vielleicht sind die aktuellen Probleme nur vorübergehend und das Projekt gewinnt wieder an Fahrt. (CentOS 7 ist von den Update-Problemen übrigens nicht betroffen.)

Quellen

• Oracle Linux
• Download (Mirror-Liste)
• Oracle Blog: Announcing Oracle Linux 8.0
• Oracle Blog: Announcing Oracle Linux 8.1
• Oracle Linux 8.1 Release Notes
• Oracle Application Streams Life Cycle
• EPEL
• Oracle Linux Preisliste

DNS over HTTPS, kurz: DoH, soll die Sicherheit und Privatsphäre der Nutzer verbessern. Nach Cloudflare hat Mozilla NextDNS als weiteren Partner gewonnen.

Was ist DNS over HTTPS?

Wikipedia beschreibt DNS over HTTPS mit den folgenden Worten:

DNS over HTTPS (DoH) ist ein Protokoll zur Durchführung einer DNS-Auflösung über das HTTPS-Protokoll. Das Ziel ist es, die Privatsphäre und Sicherheit der Benutzer zu erhöhen, indem das Abhören und Manipulieren von DNS-Daten durch Man-in-the-Middle-Angriffe verhindert wird. Neben der Verbesserung der Sicherheit sind weitere Ziele von DNS über HTTPS, die Leistung zu verbessern und DNS-basierte Zensurmaßnahmen zu verhindern. DNS over HTTPS wurde am 19. Oktober 2018 als RFC 8484 standardisiert.

Wikipedia

DNS over HTTPS in Firefox

Bereits 2017 begann Mozilla die Arbeiten an DNS over HTTPS. Vor wenigen Wochen hat Mozilla schließlich die offizielle Ausrollung für erste Firefox-Nutzer in den USA begonnen.

Mozilla setzt dabei standardmäßig auf 1.1.1.1 von Cloudflare als DNS-Resolver. Der Nutzer kann in den Firefox-Einstellungen aber auch jeden anderen DNS-Anbieter eintragen oder das Feature komplett deaktivieren.

Cloudflare soll nicht Mozillas einziger Partner bleiben. Im Rahmen seines Trusted Recursive Resolvers-Programms (TRR) sucht Mozilla nach weiteren vertrauenswürdigen Partnern. Dafür müssen strenge Vorgaben erfüllt werden. Beispielsweise dürfen Daten nicht länger als 24 Stunden aufbewahrt werden und die Weitergabe an Dritte ist untersagt. Ebenso ist eine öffentliche Datenschutzerklärung verpflichtend, welche beschreibt, welche Daten anfallen und wie mit diesen umgegangen wird. Sofern vom Gesetzgeber nicht anders verlangt ist auch die Modifizierung oder Blockierung des DNS strengstens untersagt – außer natürlich, der Nutzer willigt explizit in eine Filterung ein, wie es zum Beispiel bei einer Kindersicherung der Fall ist.

Wie Mozilla heute angekündigt hat, hat man nach Cloudflare nun auch NextDNS als Partner für DoH in Firefox gewinnen können. NextDNS ist ein noch sehr junger DNS-Anbieter, der erst im Mai dieses Jahres vom Dailymotion-Gründer sowie einem langjährigen Dailymotion-Mitarbeiter gegründet worden ist.

Der Beitrag NextDNS ist neuer Partner für DNS over HTTPS in Firefox erschien zuerst auf soeren-hentzschel.at.

Für den Einsatz von Linux im Server- und Desktopbereich gibt es nur wenige belastbare Zahlen. Die meisten Anwender lehnen Tracking ab und nur wenige Distributionen erheben überhaupt Anwenderzahlen. Dementsprechend halten sich viele Mythen und jeder kann aus seiner persönlichen Wahrnehmung heraus Ansichten postulieren.

Vor einigen Jahren habe ich mich in zwei Artikel bereits damit befasst:

• Mythen I: Desktopumgebungen
• Mythen II: Entwicklung bei den Desktopumgebungen

Die Zahlen beruhten und beruhen auf Debian und Ubuntu, weil lediglich diese beiden Distributionen überhaupt systematisch die Nutzung der Pakete und anderer Systeminformationen erheben. Beide auf freiwilliger Basis, was Verzerrungen und erhebliche Abweichungen von der Realität nicht ausschließt, aber wir haben keine anderen Zahlen.

Mich hat kürzlich interessiert wie sich das Thema in den vergangenen Jahren entwickelt hat. 

Debian

Die Erhebung ist bei Debian relativ einfach, weil alle Desktopumgebungen bis auf KDE Plasma ein zentrales Session-Paket haben, das für die Funktionsfähigkeit installiert sein muss.

Zu sehen ist, dass GNOME immer noch unangefochtener Spitzenreiter ist. Vermutlich wirken sich hier die Default-Settings bei der Installation aus. Allerdings mit Verlusten, wohingegen alle anderen Desktopumgebungen leicht dazu gewinnen. Insbesondere KDE Plasma scheint sich langsam aus dem Tal der Tränen, in das es nach den Umbrüchen der Versionen 4 und 5 gestürzt ist, heraus zu kämpfen.

Als kleine Ergänzung übrigens ein Vergleich mit dem zentralen libc6 Paket.

Ich war überrascht wie viele messbare Debian-Installation einen Desktop installiert haben. Schließlich galt und gilt Debian primär als Serverbetriebssystem.

Insgesamt sind die Zahlen sehr gering, was umso mehr überrascht, da Debian in der Installationsroutine explizit um die Teilnahme an Popcon bittet.

Ubuntu

Bei Ubuntu erfolgte die Zählung über die zentralen -desktop Pakete. Seit 18.04 erhebt Canonical daneben noch weitere Zahlen, die aber nicht der Allgemeinheit zur Verfügung stehen. Das ist besonders bedauerlich, weil laut deren Erhebung zumindest die Nutzer des Haupt-Derivats Ubuntu zu 66% der Erhebung zustimmen. Die Datenmenge dürfte daher um ein vielfaches größer sein.

Die absurd geringen Zahlen bei MATE und Budgie lassen mich hier aber einen Denk- oder Messfehler vermuten. Allerdings bitten Canonical auch nicht aktiv um die Teilnahme an Popcon, sondern der Anwender muss dies in den Software-Properties dezidiert aktivieren. Ein Vergleich mit den "Desktop Metrics" ist leider nicht möglich, weil die von Canonical publizierten Grafiken lediglich Prozentwerte beinhalten (ein Schelm, wer böses dabei denkt...)

Auffällig ist wie gering die Zahlen im Vergleich zu 2015 angestiegen sind. Die Ursachen mögen in der gewachsenen Popularität anderer Distribution liegen, aber der Linux Markt scheint insgesamt ziemlich gesättigt zu sein. Die große Migrationswelle mit dem Supportende von Windows 7, die von manchen herbei geredet wird, sehe ich nicht kommen.

Das sind natürlich keine repräsentativen Zahlen. Selbst bei Ubuntu mit über 2 Mio. erfassten Installationen dürfte nur einen Bruchteil in Popcon erfassen. 2015 kursierte mal die Zahl von 20 Millionen Installationen, allerdings blies man 2012 auch schon in dieses Horn.

Grundsätzlich plädiere ich bei dem ganzen Thema für mehr Zahlen. Diese müssen natürlich ethisch erhoben werden und die Einwilligung sollte bestenfalls transparent über ein Opt-in erfolgen, ansonsten wenigstens über ein prominentes Opt-out (siehe: Kommentar: Gut umgesetztes Tracking belohnen). Denn lediglich Zahlen können Linux von der unsäglichen Forkerei und den vielen Miniprojekten retten, die das Ökosystem insgesamt schwächen. Manchem Entwickler oder Maintainer sollten die geringen Nutzungszahlen einfach mal vor Augen geführt werden.

Bilder:
Einleitungs- und Beitragsbild von rawpixel via pixabay

Die PSD2 Richtlinie hat den Markt für Banking Apps dieses Jahr gehörig umgekrempelt. Ob die neue Richtlinie einen Fortschritt oder Rückschritt darstellt hängt von nationalen Betrachtungsweisen ab. Die Anpassungen zeigen aber einige Problembereiche auf - insbesondere bei freier Software.

Die PSD2 Richtlinie schlug im September diesen Jahres wie eine Bombe ein. Ähnlich wie bei der DSGVO hatten die verantwortlichen Stellen ihre Anpassungen auf den letzten Drücker umgesetzt und so ruckelte es bei vielen gehörig. Die Zwei-Faktor-Authentifizierung im E-Commerce setzten die verantwortlichen Stellen sogar ganz aus, weil die Anpassungen noch nicht weit genug fortgeschritten waren. Die meisten Bankkunden haben die neue Richtlinie in sofern abbekommen, als das sie nun andauernd eine TAN eingeben müssen. Nutzer von Banking-Apps mussten zudem Updates machen und so manche Bank sah die Gelegenheit gekommen sich von HBCI zu verabschieden (siehe auch: Onlinebanking - HBCI/FinTS einfordern).

Dabei sollte man jetzt aber nicht PSD2 pauschal verurteilen. Natürlich hat die Richtlinie ihre Schwächen und dank Lobbyarbeit profitieren vor allem neuartige FinTechs und weniger die Verbraucher. Die Richtlinie verbesserte aber die allgemeine Sicherheit schon deutlich, weil Banken nun gezwungen waren unsichere Alt-Systeme abzustellen. Ich sage nur TAN-Liste. Ich empfehle dazu immer noch Folge 157 von Lage der Nation. Wir Deutschen hatten aber mit HBCI eine sehr komfortable Ausgangslage und konnten fast nur verlieren.

Unabhängig von der politischen Bewertung illustriert die Geschichte wieder mal zwei Probleme im Linux-Sektor. Die Paketverwaltung ist Murks für Endanwenderprogramme und Open Source Programme bekommen künftig ein Problem.

Zuerst zum ersten Punkt. Die veränderten Richtlinien erforderten eine Reihe von Programmupdates bei zentralen Banking-Apps wie KMyMoney oder GnuCash, sowie zu Grunde liegenden Bibliotheken wie aqbanking. Während die meisten kommerziellen Softwareprojekte bereits im Frühjahr mit den notwendigen Aktualisierungen anfingen kamen diese Projekte erst sehr spät mit Updates daher. Allerdings schafften sie es wenigstens im September, wodurch sich die Probleme für den Endanwender in Grenzen halten würden. Es sei denn natürlich dieser Anwender setzt auf eine andere Distribution als Arch Linux - so wie rein zufällig immer noch die meisten Linux-Anwender. Während Debian wenigstens nach einigen Wochen Backports bereitstellte, stehen Ubuntu LTS Nutzer und die aller abhängigen Derivate immer noch im Regen. Dort können sie sich dann z. B. mit den Anwendern von openSUSE Leap unterhalten.

Mit Snaps oder Flatpaks wäre das nicht passiert (siehe: Snaps oder Flatpaks - Es gibt kein zurück). Dem Anwender ist es egal, ob aqbanking und KMyMoney unterschiedliche Projekte sind. Der Anwender installiert meist auch nicht KMyMoney und GnuCash zeitgleich und hat dann alles doppelt. Ich betreue ein paar PCs mit KMyMoney (weil das ein gutes Programm für Banking ist) und die Anwender haben ausreichende Linux-Kenntnisse. Ich muss dort sehr selten eingreifen, auch weil sie eingesetzten Distributionen stabil sind und daher nur alle paar Jahre umfangreiche Pflege benötigen. Aber ich kann denen kaum empfehlen selber Pakete zu bauen, Programme zu kompilieren und Konten auf der Kommandozeile einzurichten.

Unabhängig davon steht es um die Open Source Programme insgesamt nicht gut. Banken erschweren zunehmend den Zugriff via HBCI und nutzen PSD2 als Vorwand. Das ist zwar eine standardisierte Schnittstelle, aber um die nutzen zu können braucht man eine professionelle Infrastruktur, eine Zertifizierung bei der BaFin und muss jährlich erhebliche Summen in die Hand nehmen. Der Entwickler der sehr populären macOS App MoneyMoney hat auf Rückfrage mal die Kosten in Ansätzen offen gelegt. Er beabsichtigt die notwendigen Einnahmen durch ein Abonnement für diejenigen Kunden einzunehmen, die auf PSD2 für ihre Bank angewiesen sind. Doch was machen die Entwickler von Open Source Programmen? Immerhin hat Open Source immer noch kein solides Finanzierungsmodell und es fehlt auch an der notwendigen Organisationsstruktur um so etwas überhaupt anbieten zu können. Ich sehe da leider schwarz für die Zukunft. Zum Glück gibt es wenigstens in diesem Bereich auch ein paar kommerzielle Produkte für Linux.

Ich persönlich habe die ganze Entwicklung tatsächlich zum Anlass genommen mein primäres Konto zu einer Bank umzuziehen, die uneingeschränkt HBCI unterstützt. Hoffentlich noch sehr lange!

Bilder:

Einleitungs- und Beitragsbild von stevepb via pixabay

Die Überschrift sagt eigentlich schon alles: Ich habe seit sechs Wochen keine Updates mehr für meine CentOS-8-Systeme erhalten. (Ich beziehe mich dabei auf die zwei wichtigsten Paketquellen, Base und AppStream, jeweils für die Architektur x86_64.) Sicherheitstechnisch ist das sub-optimal, gelinde formuliert.

Update 23.12.2019: CR-Paketquelle aktivieren (siehe unten)

Update 15.1.2020: CentOS 8.1 (in der CentOS-Nomenklatur »CentOS 8.1 [1911]«) ist fertig. Wer CentOS 8 installiert hat, bekommt nun endlich — nach 10 Wochen — wieder Updates.

Konkret bedeutet das für einige ausgewählte Pakete (Stand 13.12.2019, jeweils nach yum update):

Paket              in RHEL 8           in CentOS 8
---------          ------------------  --------------
firefox            68.3.0              68.2.0
httpd              2.4.37-16           2.4.37-12
kernel             4.18.0-147          4.18.0-80
NetworkManager     1.20.0              1.14.0
openssh-server     8.0p1               7.8p1 
php                7.2.11-4            7.2.11-1

Red Hat hat seit dem 30.10.2019 diverse kritische Sicherheitslücken gestopft (Quelle). Betroffen sind unter anderem Firefox und PHP. CentOS-8-Anwender stehen diesbezüglich im Regen.

Ursache des Problems ist wohl die Umstellung auf CentOS 8.1, deren Ende nicht absehbar ist (Quelle). Red Hat hat ja Anfang November Version 8.1 vorgestellt, CentOS konnte diesen Versionssprung bisher nicht nachvollziehen.

Angesichts dieser Verzögerungen stellt sich aber die Frage, ob man CentOS noch als kostenlose RHEL-Alternative empfehlen kann. Im jetzigen Zustand offenbar nicht — es geht einfach nicht an, dass wichtige Sicherheits-Updates wochenlang ausbleiben.

Continuous-Release-Paketquelle (Update 23.12.2019 + 27.12.2019)

CentOS sieht eine Continuous-Release-Paketquelle (kurz CR) vor. Diese soll speziell in der Übergangszeit zwischen Minor Releases weniger gut getestete Pakete enthalten und so einerseits eine frühzeitige Testmöglichkeit bieten, andererseits aber auch einen Weg, kritische Updates ohne die Wartezeit auf das nächste Release zu erhalten. Hier ist die offizielle Beschreibung des CR-Repositories.

Die Datei /etc/yum.repos.d/CentOS-CR.repo enthält darüberhinaus den folgenden Hinweis, den ich hier wörtlich zitiere:

# CentOS-CR.repo
#
# The Continuous Release ( CR )  repository contains rpms that are due in the next
# release for a specific CentOS Version ( eg. next release in CentOS-8 ); these rpms
# are far less tested, with no integration checking or update path testing having
# taken place. They are still built from the upstream sources, but might not map
# to an exact upstream distro release.
#
# These packages are made available soon after they are built, for people willing
# to test their environments, provide feedback on content for the next release, and
# for people looking for early-access to next release content.
#
# The CR repo is shipped in a disabled state by default; its important that users
# understand the implications of turning this on.
#
# NOTE: We do not use a mirrorlist for the CR repos, to ensure content is available
#       to everyone as soon as possible, and not need to wait for the external
#       mirror network to seed first. However, many local mirrors will carry CR repos
#       and if desired you can use one of these local mirrors by editing the baseurl
#       line in the repo config below.

Die Aktivierung der Paketquelle ist simpel:

yum-config-manager --enable cr

In der Folge berücksichtigt yum update auch die CR-Paketquelle.

Der praktische Nutzen war zum Zeitpunkt meines ersten Tests (23.12.2019) allerdings vernachlässigbar. Die CR-Paketquelle für CentOS 8 war leer :-(

Bei einem zweiten Test am 27.12. sah die Sache schon ein wenig besser aus, allerdings trat nun ein Konflikt bei den glibc-Paketen auf.

Angesichts des explizit experimentellen Charakters der CR-Quelle ist das grundsätzlich OK. Mit der Option --nobest war es immerhin möglich, einen Großteil der Updates durchzuführen. Meine CentOS-Testinstallation ist damit wieder halbwegs am aktuellen Stand.

Am Grundproblem ändert aber auch die CR-Quelle nichts: CentOS 8 hat mittlerweile seit 8 Wochen (Stand 27.12.) keine offiziellen Updates und ist im aktuellen Zustand für den Produktionseinsatz ungeeignet. Und dieses Urteil lässt sich frühestens revidieren, wenn das Update auf Version 8.2 irgendwann im Sommer oder Herbst 2020 besser verläuft.

Quellen

• Base-Pakete, geordnet nach letzter Änderung: http://mirror.centos.org/centos/8/BaseOS/x86_64/os/Packages/?C=M;O=D
• AppStream-Pakete, geordnet nach letzter Änderung: http://mirror.centos.org/centos/8/AppStream/x86_64/os/Packages/?C=M;O=D
• https://wiki.centos.org/About/Building_8.x
• https://access.redhat.com/security/security-updates/#/
• https://www.redhat.com/en/blog/whats-new-rhel-81-kernel-patching-more-insights-and-right-time
• https://wiki.centos.org/AdditionalResources/Repositories/CR
• https://lists.centos.org/pipermail/centos/2019-December/thread.html

15.1.2020. Ein kleiner Hoffnungsschimmer, dass in Zukunft alles wieder gut ist :-)

• https://blog.centos.org/2020/01/update-state-of-centos-linux-8-and-centos-stream

Ubuntu Pro ist ein neues Angebot von Canonical und Amazon. Dabei handelt es sich um eine für die Amazon-Cloud (genaugenommen für Amazon EC2) optimierte Variante von Ubuntu LTS. Es gibt drei wesentliche Unterschiede zwischen Ubuntu LTS und Ubuntu Pro:

• Ubuntu Pro steht aktuell ausschließlich für Amazon EC2 zur Verfügung. Es kann also nicht auf einen eigenen Rechner oder in einem anderen Cloud-System installiert werden.
• Das Kernel-Live-Patching ist standardmäßig inkludiert.
• Der Wartungszeitraum beträgt statt fünf Jahren beachtliche zehn Jahre (Version 18.04, 20.04 etc.) bzw. immerhin noch acht Jahre für ältere LTS-Versionen.

Kosten

Die Kosten für Ubuntu Pro werden direkt von Amazon verrechnet — Sie brauchen also keinen direkten Lizenzvertrag mit Canonical abzuschließen. Eine EC2-Instanz mit Ubuntu Pro ist also etwas teurer als eine EC2-Instanz mit Ubuntu LTS. Der Aufpreis beträgt aktuell maximal 20% der Instanzkosten. (Bei leistungsstarken Instanzen ist der Aufpreis prozentuell geringer.)

Absolut sind die Kosten schwer zu beziffern, was mit dem sehr komplexen Kalkulationsmodell von Amazon EC2 zu tun hat. Das folgende Beispiel illustriert die Größenordnung und gibt einen Vergleich zu RHEL:

• Eine Cloud-Instanz für ein kostenloses Linux (z.B. Ubuntu LTS, Debian, CentOS) vom Typ t3.medium (2 CPU-Cores, 4 GiB RAM) kostet aktuell 0,048 USD pro Stunde (On-Demand Instanz mit Server-Standort in Frankfurt). Pro Monat kostet diese Instanz ohne Software-Aufpreis also ca. 34 USD.
• Wenn Sie die gleiche Instanz mit Ubuntu 18.04 Pro ausführen, steigen die Kosten auf 0,057 USD pro Stunde (ca. 41 USD pro Monat). Damit kostet Ubuntu Pro für diese Instanz ca. 7 USD pro Monat zusätzlich.
• Wenn Sie die gleiche Instanz mit Red Hat Enterprise Linux 8 ausführen, steigen die Kosten auf 0,108 USD pro Stunde (ca. 78 USD pro Monat). Damit betragen die Zusatzkosten für RHEL8 für diese Instanz ca. 44 USD pro Monat.

In allen drei Fällen kommen zu den Instanzkosten noch die Kosten für den Datenträger, für den Netzwerkverkehr sowie evt. für weitere Zusatzleistungen (fixe IP-Adresse, Backups auf Amazon S3 usw.).

Insgesamt erscheint die Preisgestaltung von Ubuntu Pro durchaus moderat. Im Vergleich zu RHEL ist Ubuntu Pro geradezu billig. Andererseits ist der Zusatznutzen im Vergleich zum »normalen« Ubuntu LTS natürlich auch recht gering. Wirklich interessant wird Ubuntu Pro dann, wenn eine sehr lange Laufzeit anvisiert wird.

(Losgelöst vom Software-Aufpreis für Ubuntu Pro oder RHEL erscheinen mir die Kosten für Cloud-Instanzen bei Amazon EC2 enorm hoch. Natürlich ist die Flexibilität des Cloud-Angebots praktisch grenzenlos; aber ein »simpler« Root-Server bietet pro USD/EUR fast die zehnfache Leistung.)

Quellen

• https://ubuntu.com/aws/pro
• https://aws.amazon.com/marketplace/search/results?x=0&y=0&searchTerms=ubuntu+pro
• https://aws.amazon.com/de/ec2/pricing
• https://aws.amazon.com/marketplace/pp/B0821T9RL2?qid=1576168043903&sr=0-1&ref_=srh_res_product_title#pdp-pricing

Wird die Größe einer per iSCSI oder Fibre Channel eingebundenen LUN geändert, oder in einer virtualisierten Umgebung die Größe der virtuellen Festplatte (VMDK, VDI, VHD, qcow2, etc.) angepasst, kann man den Linux-Kernel auffordern die entsprechenden Blockgeräte auf Änderungen hin zu prüfen, ohne dafür das Betriebssystem neustarten zu müssen.

Die im folgenden genannten bzw. verlinkten Kommandos wurden unter RHEL 7 mit VMDK-Dateien und iSCSI-Disks getestet. Sie sollten jedoch für Linux im Allgemeinen gelten.

Änderungen an bestehenden Blockgeräten erkennen

Um Änderungen an Blockgeräten zu erkennen, welche dem Kernel bereits bekannt sind, wird folgender Befehl mit root-Rechten ausgeführt:

# echo 1 > /sys/class/block/sdX/device/rescan

Dabei ist sdX durch die Bezeichnung des konkreten Blockgeräts wie z.B. sda oder sdb etc. zu ersetzen. Statt dem genannten Bezeichner kann auch die SCSI-Nummer des entsprechenden Gerätes verwendet werden. Der Befehl lautet dann wie folgt (wobei X:X:X:X durch die jeweilige SCSI-Nummer zu ersetzen ist):

# echo 1 > /sys/class/scsi_device/X:X:X:X/device/block/device/rescan

Update 2019-12-15: Ist das Paket parted installiert, kann man den Kernel auch mit dem Kommando partprobe über die Änderungen informieren:

# partprobe /dev/sdX

Danke an Dirk für diesen Tipp.

Neue Blockgeräte erkennen

Wie neu hinzugefügte Blockgeräte erkannt werden können, habe ich bereits im Artikel Linux: Hotplugged SATA/SAS/SCSI-Festplatten ohne Neustart erkennen beschrieben.

Quellen und weiterführende Hinweise

1. How to rescan disk in Linux after extending vmware disk
2. How to map Linux disk to vmware disk
3. Red Hat Storage Administration Guide: Sec. 37.2. Resizing an iSCSI Logical Unit

Seit Jahren schwöre ich auf die NAS-Systeme von Synology. Hier werkelte für gut 6 Jahre eine DiskStation DS213. Der Name verrät es schon, es handelt sich dabei um eine 2-Bay-Variante. Zum Einsatz kamen hier noch WD Red-Festplatten.

Nun haben sich meine Ansprüche sowohl, was Funktionen als auch Speicherplatz angeht deutlich verändert, weshalb ein neues System her musste. Meine Wahl fiel auf eine DS918+.

Die alte DiskStation wollte ich nun fit für Ebay Kleinanzeigen machen, dazu gehört natürlich auch die alten Festplatten zu säubern. Synology selbst bietet dafür ein entsprechendes Tool namens Secure Erase an, welches sich im DSM im Store Manager versteckt.

Nun trat während die zweite Platte überschrieben wurde jedoch ein Fehler auf. Die Synology DiskStation startete einfach neu, beim anschalten waren beide Festplatten nicht mehr ansprechbar/das ganze System bootete nicht mehr.

Meine ersten Versuche waren, die DiskStation zurückzusetzen. Dazu den Reset-Knopf auf der Rückseite vier Sekunden bis zum ersten Piep-Ton gedrückt halten und anschließend direkt wieder drücken, bis drei weitere Töne kommen. Anschließend sollte sie laut Anleitung nach wenigen Minuten unter find.synology.com wieder erreichbar sein – was auch funktionierte. Nun trat allerdings der nächste Fehler auf „Failed to format the disk 35“. Dies betraf beide Platten. Und auch direkt angeschlossen an einem PC tat sich erst einmal nichts mehr.

In der Computer Verwaltung wurden mir die Festplatten zwar immerhin angezeigt, jedoch schlug die Initialisierung fehl mit der Meldung „Datenfehler (CRC-Prüfung). Spannenderweise konnte ich die SMART-Werte sowie die Festplattengröße jedoch noch problemlos auslesen – was für mich bedeutete, dass die Festplatten an sich noch funktionieren müssten. Zudem war es merkwürdig, dass beide Festplatten exakt das gleiche identische Fehlerbild aufwiesen. Selbst eine Analyse mittels TestDisk brachte keinerlei Erkenntnis.

Die Lösung fand ich nach mehreren Tagen nun endlich im Forum von Synology.

Während des Löschvorgangs wird die Festplatte gesperrt und eine Sicherheitsstufe aktiviert. Dies wird seitens Synology nirgendwo erwähnt! Den einzigen Verweis, den ich bei meinen Recherchen dazu fand lautete wie folgt:

Wenn Secure Erase während der Ausführung unsachgemäß angehalten wird, können Sie Secure Erase direkt auf der Benutzeroberfläche erneut ausführen. Wenn die Festplatten entfernt oder anderweitig verwendet werden, wenn sie noch gesperrt sind, müssen Sie das Kennwort „Synology“ eingeben, um sie zu entsperren.

Synology DSM Dokumentation

Da ich keine weitere Festplatte mehr hatte, habe ich kurzerhand eine virtuelle Linux-Maschine aufgesetzt, die Festplatten einzeln dran gehangen und mittels fdisk -l geprüft, welche Zuordnung diese bekommt, bei mir war dies /dev/sdb. Folgende zwei Befehle setzten die Einstellungen bzw. Festplatten dann zurück:

hdparm --user-master m --security-unlock WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCW /dev/sdb
hdparm --user-master m --security-disable WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCW /dev/sdb

sdb müsst ihr dann je nachdem wie bei euch die Festplatte eingebunden ist einmal anpassen.
Je nach Größe der Festplatte kann gerade der erste Befehl einige Minuten dauern. Nachdem ich beide Kommandos bei den Festplatten durchgeführt hatte, wurden diese endlich wieder erkannt.
Ich kann aus meiner Erfahrung somit nur von der Nutzung der Secure Erase-Funktion abraten und jedem nur ans Herz legen, diese auf keinen Fall zu verwenden. Stattdessen habe ich die Festplatten nun mittels dd gelöscht.

Photo by JC Gellidon on Unsplash

Seit Jahren schwöre ich auf die NAS-Systeme von Synology. Hier werkelte für gut 6 Jahre eine DiskStation DS213. Der Name verrät es schon, es handelt sich dabei um eine 2-Bay-Variante. Zum Einsatz kamen hier noch WD Red-Festplatten.

Nun haben sich meine Ansprüche sowohl, was Funktionen als auch Speicherplatz angeht deutlich verändert, weshalb ein neues System her musste. Meine Wahl fiel auf eine DS918+.

Die alte DiskStation wollte ich nun fit für Ebay Kleinanzeigen machen, dazu gehört natürlich auch die alten Festplatten zu säubern. Synology selbst bietet dafür ein entsprechendes Tool namens Secure Erase an, welches sich im DSM im Store Manager versteckt.

Nun trat während die zweite Platte überschrieben wurde jedoch ein Fehler auf. Die Synology DiskStation startete einfach neu, beim anschalten waren beide Festplatten nicht mehr ansprechbar/das ganze System bootete nicht mehr.

Meine ersten Versuche waren, die DiskStation zurückzusetzen. Dazu den Reset-Knopf auf der Rückseite vier Sekunden bis zum ersten Piep-Ton gedrückt halten und anschließend direkt wieder drücken, bis drei weitere Töne kommen. Anschließend sollte sie laut Anleitung nach wenigen Minuten unter find.synology.com wieder erreichbar sein – was auch funktionierte. Nun trat allerdings der nächste Fehler auf „Failed to format the disk 35“. Dies betraf beide Platten. Und auch direkt angeschlossen an einem PC tat sich erst einmal nichts mehr.

In der Computer Verwaltung wurden mir die Festplatten zwar immerhin angezeigt, jedoch schlug die Initialisierung fehl mit der Meldung „Datenfehler (CRC-Prüfung). Spannenderweise konnte ich die SMART-Werte sowie die Festplattengröße jedoch noch problemlos auslesen – was für mich bedeutete, dass die Festplatten an sich noch funktionieren müssten. Zudem war es merkwürdig, dass beide Festplatten exakt das gleiche identische Fehlerbild aufwiesen. Selbst eine Analyse mittels TestDisk brachte keinerlei Erkenntnis.

Die Lösung fand ich nach mehreren Tagen nun endlich im Forum von Synology.

Während des Löschvorgangs wird die Festplatte gesperrt und eine Sicherheitsstufe aktiviert. Dies wird seitens Synology nirgendwo erwähnt! Den einzigen Verweis, den ich bei meinen Recherchen dazu fand lautete wie folgt:

Wenn Secure Erase während der Ausführung unsachgemäß angehalten wird, können Sie Secure Erase direkt auf der Benutzeroberfläche erneut ausführen. Wenn die Festplatten entfernt oder anderweitig verwendet werden, wenn sie noch gesperrt sind, müssen Sie das Kennwort „Synology“ eingeben, um sie zu entsperren.

Synology DSM Dokumentation

Da ich keine weitere Festplatte mehr hatte, habe ich kurzerhand eine virtuelle Linux-Maschine aufgesetzt, die Festplatten einzeln dran gehangen und mittels fdisk -l geprüft, welche Zuordnung diese bekommt, bei mir war dies /dev/sdb. Folgende zwei Befehle setzten die Einstellungen bzw. Festplatten dann zurück:

hdparm --user-master m --security-unlock WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCW /dev/sdb
hdparm --user-master m --security-disable WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCW /dev/sdb

sdb müsst ihr dann je nachdem wie bei euch die Festplatte eingebunden ist einmal anpassen.
Je nach Größe der Festplatte kann gerade der erste Befehl einige Minuten dauern. Nachdem ich beide Kommandos bei den Festplatten durchgeführt hatte, wurden diese endlich wieder erkannt.
Ich kann aus meiner Erfahrung somit nur von der Nutzung der Secure Erase-Funktion abraten und jedem nur ans Herz legen, diese auf keinen Fall zu verwenden. Stattdessen habe ich die Festplatten nun mittels dd gelöscht.

Photo by JC Gellidon on Unsplash

Der Beitrag Synology Secure Erase macht Festplatten unbenutzbar erschien zuerst auf timscha.io.

Ein kleiner Blick über den Tellerrand: im Laufe des heutigen und morgigen Tages passieren interessante Dinge bei Ethereum. Die Open Source-Software und das gleichnamige Netzwerk Ethereum bilden ein verteiltes System für DApps, die unter die Kategorie der Smart Contracts fallen. DApps kann man sich als „distributed decentraliced cloud computing“ vorstellen. Als Datenstruktur wird eine Blockchain eingesetzt. (Rudimentäre) Anwendungen (Beispielprogramm) werden dort verewigt und können über entsprechende Clients angesprochen werden.

Das Ganze basiert momentan überwiegend auf JavaScript(-ähnlichen Sprachen) und fühlt sich wie die Entwicklertools-Konsole im Webbrowser an. Aber es funktioniert und das sogar erstaunlich gut.

Ressourcen in Form von CPU-Zeit, etc. werden über den eigenen Token Ether verrechnet. Und da haben wir es: bei Ethereum stehen wir zur Hälfte in der Welt der Kryptowährungen – aber eben nur zur Hälfte.

Ethereum unterscheidet sich von Bitcoin nicht nur in den DApps sowie der Struktur. Das Netzwerk ist geprägt von ständigem Wandel, Weiterentwicklung und resultierenden Upgrades. Weit am Horizont steht der Umstieg auf "Ethereum 2.0" an. Dabei geht um die Umstellung von Proof of Work-Verfahren mit den Minern hin zum Proof of Stake-Verfahren mit sog. Validatoren. Da diese Umstellung tiefe Einschnitte in jeglicher Weise für das Netzwerk bedeutet, wird die Migration schrittweise vollzogen.

Hard Fork-Upgrade

Teil der Migration sind Upgrades, die mitunter zu einem Hard Fork führen. Dies ist immer dann der Fall, wenn die Änderungen nicht abwärtskompatibel sind, also mit dem Upgrade Abläufe und Verhaltensweisen erlaubt werden, die vorher verboten waren. Wird ein Upgrade nicht von ausreichend Nutzern adaptiert, kann sich die Blockkette teilen.

Schauen wir uns das in der Grafik einmal an und fangen oberhalb der gestrichelten Linie an, wo Version 1 läuft: Blöcke werden wie üblich der Blockchain angefügt, indem sie auf einen Parent bzw. Elternteil verweisen. Somit lässt sich rekursiv der Weg zum Urblock, dem Genesis-Block, zurückverfolgen. Das Proof of Work-Verfahren sagt weiterhin aus, dass Grundlage für neue Transaktionen die Kette an Blöcken ist („best block chain“), für die der meiste Aufwand in Form von Mining nötig war. So erklären sich auch die doppelten Blöcke mit der gleichen Nummer: sie gelten als „abgelaufen“ (stale), sofern eine andere Kette mehr Nachfolger hat. Soweit so gut – schauen wir uns nun den Bereich unterhalb der gestrichelten Linie an: hier wird Version 2 betrieben. Anfangs bei Block 99 verhält sich das System genau wie Version 1. Es ist allerdings einprogrammiert, dass ab Block 100 die Änderungen scharf gestellt werden. Das hat zur Folge, dass die dann weitergeführte Blockchain nicht mehr mit Version 1 kompatibel ist.

Problematisch ist dies, weil somit double spending, das mehrfache Ausgeben des gleichen Coins, möglich wird: wer bis zum Block 99 einen Coin in seiner Wallet hatte, kann ihn nun auf beiden Chains zwei Mal ausgeben, da die Ketten nicht mehr miteinander kommunizieren können. Werden Coins aus der Version 1-Blockchain (ab Block 100) von einer Exchange sogar noch zum Handel angeboten, ist das Chaos perfekt: dann haben wir einen weiteren Altcoin (alternative coin) mit eigenem Kurs, etc. Da alte Vermögen (die von Block ≤ 99) ebenfalls gültig sind, haben wir quasi neue Token geschaffen – der Rest ist Auslegungssache vom Finanzamt.

Um nicht durch die potentielle Fragmentierung Schaden zu erleiden, sind deshalb die Entwickler von solchen Systemen meist bemüht, eine hohe Adaption von Upgrades zu erreichen. Dazu aber später noch mehr.

Istanbul-Upgrade

Das Upgrade mit dem Codenamen Istanbul wirkt ab Blocknummer 9.069.000 und bringt für Ethereum einige Neuigkeiten mit:

• EIP-152 soll Interoperabilität mit Zcash ermöglichen und verbessern
• EIP-1108 und EIP-2028 machen (Privatsphäre)funktionalitäten erschwinglicher, indem die Kosten für zk-SNAKS (zero knowledge-Instrumenten für bessere Privatsphäre) angepasst und die Gebühr (bei Ethereum sog. gas) von Calldata von 68 gas pro Byte auf 16 gas pro Byte gesenkt werden
• EIP-1884 hebt die Kosten (gas) für bestimmte opcodes an
• EIP-1344 fügt das CHANID opcode hinzu, um die korrekte Blockkette zu tracken
• EIP-2200 ändert das gas metering im Zusammenhang mit dem SSTORE opcode

Übrigens: die erwähnten Opcodes sind wirklich als solche zu verstehen, da Smart Contracts / DApps kompiliert werden und nur das Kompilat mit den eigenen Opcodes samt ABI in der Blockchain gespeichert und schließlich in der Ethereum Virtual Machine (EVM) ausgeführt wird.

Aber irgendwie will das Upgrade diesmal nicht so: auf ethernodes.org/istanbul lässt sich beobachten, wie viele Nodes dieses Upgrade bereits installiert haben (durch ein simples Update des Node-Clients wie geth oder parity). Momentan sind es zum Zeitpunkt des Artikels nur knapp 50 %. Gewünscht wären > 95 %.

Dabei tickt die Uhr: heute Nacht um ca. 01:00 Uhr MEZ soll Block 9069000 erreicht und das Upgrade vollzogen werden. Es bleibt zu schauen, was passiert.

Ethereum Forks sind im Gegensatz zu Bitcoin nicht unüblich: so entstand durch einen erzwungenen Hard Fork durch das Entwicklerteam in Folge des DAO-Hacks Ethereum Classic.