trueten.de

Bekanntlich bin ich der Ansicht, daß alle Spammer an ihren Eiern aufgehängt gehören. Da dieser Wunsch für mich momentan etwas schwierig umzusetzen ist, ich aber trotzdem Interesse an einer weitestgehend Spam bzw. Phishing freien Mailverkehr habe, muss ich wie einst Sisyphos (oder war es Don Quixote?) gegen unerwünschte Mails kämpfen. Da ich nicht der einzige bin, der diesen Wunsch hegt, gibt es eine breite Palette an Tools, die einen dabei unterstützen. Als Domaindiktator setze ich dabei am Mailserver an: "DomainKeys ist ein Identifikationsprotokoll zur Sicherstellung der Authentizität von E-Mail-Absendern, das von Yahoo entwickelt wurde und seit Ende 2013 ein Internet-Standard ist. Es wurde konzipiert, um bei der Eindämmung von unerwünschter E-Mail wie Spam oder Phishing zu helfen."  DKIM-Signaturen machen also Veränderungen an Header und Body einer Mail erkennbar.
Da es einige Stolperfallen bei der Einrichtung gibt, die das korrekte Funktionieren verhindern können, habe ich mir ein kurzes und rudimentäres HowTo verfasst:

Das Szenario: Alle Mails der Doman domainname.de sollen signiert werden. Alle eingehenden Mails sollen verifiziert werden. Wir haben Zugriff auf Nameservereinträge der Domain und ein Postfix Server sowie Amavis und Spamassassin verrichten ihren Dienst auf einem debian System. Den DKIM Dienst soll openDKIM übernehmen, das wir gleich mal in einem Terminal zusammen mit ein paar Tools installieren:

sudo apt install opendkim opendkim-tools

Dann legen wir ein Schlüsselverzeichnis an und generieren den Schlüssel. Wichtig ist die korrekte Rechtevergabe in den Schlüsselverzeichnissen! Zudem sollte der Dienst nicht als root laufen sondern unter dem User opendkim. Dieser darf in keiner anderen Gruppe Mitglied sein, ansonsten quittiert der Dienst den selbigen mit einer Fehlermeldung.

mkdir /etc/opendkim/keys/domainname.de
/usr/bin/opendkim-genkey -D /etc/opendkim/keys/domainname.de/ -d domainname.de -s 2020
chown -R root:opendkim /etc/opendkim/keys/domainname.de
chmod 640 /etc/opendkim/keys/domainname.de/2020.private
chmod 644 /etc/opendkim/keys/domainname.de/2020.txt

Im Anschluss bearbeiten wir die /etc/opendkim.conf:

Domain   domainname.de
Selector 2020                             # Das ist der im vorigen Schritt angegebene Selector. Interessant für diejenigen, die den DKIM Key regelmäßig aktualisieren.
KeyFile  /etc/opendkim/domainname.de/2020.private
Socket   inet:8891@localhost
Canonicalization        relaxed/simple    # Auf Headermodifikationen nicht gleich allergisch reagieren
Mode                    sv                # Mails [s]ignieren und [v]erifizieren

Wir starten den Dienst:  sudo systemctl restart opendkim und regeln, daß der Dienst beim Systemstart gleich gestartet wird:  systemctl enable opendkim. Dann befassen wir uns mit der Integration von openDKIM in Postfix. Dazu editieren wir die /etc/postfix/main.cf:

smtpd_milters = inet:localhost:8891
non_smtpd_milters = $smtpd_milters

Danach muss  Postfix diese Änderung bekannt gegeben werden: sudo systemctl reload postfix.

Das war es im Grunde dann auch schon. Bis auf eine Kleinigkeit: Die Integration des Schlüssels als TXT Record im Nameservereintrag von domainname.de. Diese Einstellung unterscheidet sich von Provider zu Provider, daher an der Stelle auch nur der allgemeine Hinweis:

Record Name	Record Type	Text
mail._domainkey	TXT	v=DKIM1; k=rsa; p=MI.. (Hier Inhalt von /etc/opendkim/keys/domainname.de/2020.txt einfügen, dabei alle >"< entfernen und alle Zeilen nach p= in einen Schlüssel ohne Leerzeichen verbinden.)

Das korrekte Eintragen des Schlüssels kann kompliziert sein, vor allem der Teil nach "p=" darf weder um- noch unterbrochen sein. Ansonsten wird der Schlüssel nicht erkannt!

Testen des Keys:

# opendkim-testkey -d domainname.de -s mail -vvv

opendkim-testkey: using default configfile /etc/opendkim.conf
opendkim-testkey: checking key 'mail._domainkey.domainname.de'
opendkim-testkey: key not secure
opendkim-testkey: key OK

Sofern keine Fehlermeldungen auftreten, kann man sich nun darum kümmern, eingehenden Spam weiter zu filtern. In Amavis ist der DKIM Filter in einigen Debian Derivaten deaktiviert, lässt sich aber einfach aktivieren. Dazu muss in der Konfigurationsdatei /etc/amavis/conf.d/20-debian-defaults folgender Parameter gesetzt werden:

$enable_dkim_verification = 1;

In der Datei /etc/amavis/conf.d/50-user muss für eine erweitere Anzeige der Überprüfungsergebnisse dann als letztes noch folgender Parameter gesetzt werden:

$allowed_added_header_fields{lc('Authentication-Results')} = 1;

Im täglichen Mailverkehr empfiehlt sich darüber hinaus ein Addon für den freien Mailclient Thunderbird zur Kontrolle der empfangenen Mails: Den DKIM Verifier. Dieses Addon überprüft beim Öffnen einer Mail die Gültigkeit der Signatur. Somit kann man sich (halbwegs) sicher sein, daß die Mail vom signierenden Mailserver stammt. Natürlich nutzen auch einzelne Spammer DKIM. "Es ist wichtig zu beachten, dass eine E-Mail durch eine beliebige Domain signiert seinen kann. Eine gültige Signatur alleine ist daher kein Hinweis auf eine vertrauenswürdige E-Mail. Um zu entscheiden ob eine E-Mail vertrauenswürdig ist sollte immer überprüft werden wer der Signierende ist! In einigen Fällen kann die Abwesenheit einer DKIM Signatur nützlich sein um betrügerische E-Mails zu erkennen. Falls bekannt ist, dass eine Domain alle ihre E-Mails mittels DKIM signiert, ist das Nichtvorhandensein einer DKIM Signatur ein starker Hinweis auf eine gefälschte E-Mail." (Aus der Addon Beschreibung)

Quellen:
debianwiki, Steven Jenkins, Michael Kofler, WikiPedia, Philippe Lieser, Patrick Koetter

Alte Admins brauchen manchmal einen Merkzettel.

ssh-copy-id -i /home/username/.ssh/id_rsa.pub username@zielsystem

Vor einiger Zeit hatte ich bei thingiverse ein Teil veröffentlicht, mit dem es möglich ist, in Verbindung mit dem empfehlenswerten "AmoredPI" Gehäuse 2,5" SSD Festplatten mit dem Einplatinenrechner Raspberry PI 3 bzw. 4 zu verbinden und so das übliche Gedrösel mit dem Kabelwirrwar etwas abzumildern.

Indessen war bis vor kurzem der Start des Raspberrys von der SSD auf die 3er Modelle beschränkt. Nun ist seit September dieses Manko Geschichte und es steht dem Betrieb des Rechners via Festplatte nichts entgegen. Fast nichts. Denn leider gibt es keine Garantie, daß jeder SSD / USB3 Festplattenadapter für den Betrieb geeignet ist, zumindest, was das Booten betrifft. Michael Kofler hat in seinem Blog unterschiedliche Adapter getestet, er hatte mit dem von GHB vertriebenen 6GB Adapter die wenigsten Probleme, weshalb ich auch meine Empfehlung auf ebendiese abgebe. Der bisher von mir auf den PIs der 3er Reihe ohne Probleme verwendete Adapter führte bei mir in keinem Fall zu einem fehlerfreien Systemstart oder dauerhaft störungsfreien Betrieb. Wenngleich der Raspberry PI 4 damit verbundene SSDs erkennt und auch problemlos liest bzw. schreibt, ist der Bootvorgang fehlerhaft. Inzwischen läuft hier ein Raspberry PI 4 mit 8 Gigabyte Speicher und einer  Silicon Power SSD 256GB 3D NAND A55 SLC Cache Performance Boost seit mehreren Tagen ohne Probleme, wenngleich Lesevorgänge beinahe doppelt so schnell wie Schreibvorgänge sind, was ich allerdings noch mit anderen SSDs wie der SanDisk SSD PLUS 240GB Sata III gegentesten muss.

Die Installation auf die Platte verläuft problemlos, ich habe zuerst den üblichen Weg mittels einer MicroSD Karte und NOOBS beschritten um sofort die aktuellste Raspbian Version auf der Platte zu haben, es funktioniert natürlich auch der über ein via etcher auf die MicroSD Karte geschriebenes Image. Nach der Aktualisierung des Systems aktiviert man via 'sudo raspi-config' die Boot Option über USB, formatiert die SSD, entpackt darauf NOOBS und bootet dann (hoffentlich) erfolgreich von der SSD. Natürlich muss dazu die MicroSD Karte abgezogen sein. ;-)

Update 14. November 2020: Dieser Adapter von ugreen ist ebenfalls kompatibel und sogar noch etwas günstiger als der oben verlinkte.

INPOL, Polas, LIMO, PHW und nun noch PIAV. Kaum jemand weiß, was sich hinter den Kürzeln verbirgt. Die Veranstaltung gibt einen ersten Einblick in die Welt der Polizeidatenbanken. Neben einer Bestandsaufnahme wollen wir auch vermitteln, dass weder Schockstarre noch Resignation angebracht sind.

08.10.2020, 19:30 Uhr

Datenschutzgruppe der Roten Hilfe HD/Mannheim

Bibliothek am Mailänder Platz, Mailänder Platz 1,70173 Stuttgart

N48.790324 E9.183079 (Karte)

Bitte beachtet die geltenden Regeln der Bibliothek und die Reservierungspflicht

„Es geht nicht um Privatsphäre, sondern es geht darum, eine Technik sozial beherrschbar zu machen.“ Dieses Datenschutzverständnis von Wilhelm Steinmüller (1934–2013), Datenschutzpionier und langjähriges FIfF-Mitglied, möchten wir, eine Gruppe Wissenschaftlerïnnen und Datenschützerïnnen im Forum InformatikerInnen für Frieden und gesellschaftliche Verantwortung (FIfF) e. V., wieder stark machen.

Seit einigen Wochen kreist die Diskussion um die Eindämmung der Corona-Pandemie zunehmend um den Einsatz technischer Hilfsmittel. Es wird geplant, die Pandemie durch den Einsatz von Tracing-Apps für Smartphones einzudämmen. Diese Systeme sollen automatisiert die zwischenmenschlichen Kontakte aller Nutzerïnnen aufzeichnen und es so erlauben, die Infektionsketten des Virus schnell und effizient nachzuvollziehen, um möglicherweise exponierte Personen frühzeitig warnen und isolieren zu können.  

Wir haben es angesichts der geplanten Corona-Tracing-Systeme mit einem gesellschaftlichen Großexperiment zur digitalen Verhaltenserfassung unter staatlicher Aufsicht in Europa zu tun. Die europäische Datenschutzgrundverordnung (DSGVO) verpflichtet die Betreiberïnnen umfangreicher Datenverarbeitungssysteme (zu denen auch ein Corona-Tracing-System zählen würde) zur Anfertigung einer Datenschutz-Folgenabschätzung (DSFA) im Falle eines hohen Risikos für die Grund- und Freiheitsrechte. Hierbei handelt es sich um eine strukturierte Risikoanalyse, die mögliche grundrechtsrelevante Folgen einer Datenverarbeitung im Vorfeld identifiziert und bewertet.

Wirksamkeit und Folgen entsprechender Apps sind noch nicht absehbar und es ist davon auszugehen, dass innerhalb der EU verschiedene Varianten erprobt und evaluiert werden. Die datenschutz- und somit grundrechtsrelevanten Folgen dieses Unterfangens betreffen potenziell nicht nur Einzelpersonen, sondern die Gesellschaft als Ganze. Aus diesem Grunde ist nicht nur die Anfertigung einer DSFA angezeigt, sondern insbesondere auch ihre Veröffentlichung – und eine öffentliche Diskussion. Da bisher keine der beteiligten Stellen eine allgemein zugängliche DSFA präsentiert hat und selbst die vorgelegten privacy impact assessments unvollständig bleiben, legen wir vom FIfF mit diesem Dokument eigeninitiativ eine solche Datenschutz-Folgenabschätzung als konstruktiven Diskussionsbeitrag vor.

Download der DSFA (Creative-Commons-Lizenz: Namensnennung, CC BY 4.0 Int.): Aktuelle Version 1.1 (PDF, 101 S., 426 kB), alte Versionen unter https://www.fiff.de/dsfa-corona

1. Die in den Diskussionen vielfach betonte Freiwilligkeit der App-Nutzung ist eine Illusion. Es ist vorstellbar und wird auch bereits diskutiert, dass die Nutzung der App als Voraussetzung für die individuelle Lockerung der Ausgangsbeschränkungen gelten könnte. Das Vorzeigen der App könnte als Zugangsbarriere zu öffentlichen oder privaten Gebäuden, Räumen oder Veranstaltungen dienen. Denkbar ist, dass Arbeitgeberïnnen solche Praktiken schnell adaptieren, weil sie mittels freiwillig umgesetzter Schutzmaßnahmen schneller ihre Betriebe wieder öffnen dürfen. Dieses Szenario bedeutet eine implizite Nötigung zur Nutzung der App und bedeutet erhebliche Ungleichbehandlung der Nicht-Nutzerïnnen. Weil nicht jede Person ein Smartphone besitzt, wäre hiermit auch eine Diskriminierung ohnehin schon benachteiligter Gruppen verbunden. Kirsten Bock vom FIfF kommentiert: „Die Einwilligung ist nicht das richtige Regelungsinstrument für die Nutzung der Corona App, weil deren Voraussetzungen nicht erfüllt sind. Der Gesetzgeber ist aufgerufen, dass Nutzungsrisiko der App nicht auf die Bürgerïnnen abzuwälzen, sondern selbst die Voraussetzungen für eine freiwillige, sichere und grundrechtsverträgliche Lösung in einem Gesetz vorzugeben und die Bürgerïnnen so vor Grundrechtsverletzungen - auch durch Dritte - wirksam zu schützen.“ Martin Rost vom FIfF ergänzt prägnant „Von einer Einwilligung geht keine Schutzwirkung für Betroffene aus."

2. Ohne Intervenierbarkeit und enge Zweckbindung ist der Grundrechtsschutz gefährdet. So besteht ein hohes Risiko fälschlich registrierter Expositionsereignisse (falsch positiv), die zu unrecht auferlegter Selbst-Isolation oder Quarantäne zur Folge haben (zum Beispiel Kontaktmessung durch die Wand zwischen zwei Wohnungen). Um dem zu begegnen, bedarf es rechtlicher und faktischer Möglichkeiten zur effektiven Einflussnahme, etwa das Zurückrufen falscher Infektionsmeldungen, die Löschung falsch registrierter Kontaktereignisse zu einer infizierten Person und das Anfechten von infolge der Datenverarbeitung auferlegter Beschränkungen. Eine solche Möglichkeit sieht bisher keines der vorgeschlagenen Systeme vor. „Beim Datenschutz geht es genauso wenig um den Schutz von Daten, wie es beim Sonnenschutz um den Schutz der Sonne geht oder beim Katastrophenschutz um den Schutz von Katastrophen.“ spitzt Jörg Pohle vom FIfF zu.

3. Alle bislang erwähnten Verfahren verarbeiten personenbezogene Gesundheitsdaten. Das Verfahren besteht aus der Verarbeitung von Kontaktdaten auf den Smartphones, der Übermittlung dieser Daten auf einen Server nach der Diagnose einer Infektion und letztendlich deren Verteilung an alle anderen Smartphones zur Prüfung auf einen möglichen Kontakt mit Infizierten. Alle Daten auf einem Smartphone sind personenbezogen, nämlich bezogen auf die Nutzerïn des Gerätes. Weil nur diejenigen Personen Daten übertragen, die als infiziert diagnostiziert wurden, sind die übertragenen Daten zugleich Gesundheitsdaten. Somit unterliegen diese dem Schutz der DSGVO.

4. Anonymität der Nutzerïnnen muss in einem Zusammenspiel rechtlicher, technischer und organisatorischer Maßnahmen erzwungen werden. Nur durch einen mehrdimensionalen Ansatz kann der Personenbezug wirksam und irreversibel von den verarbeiteten Daten abgetrennt werden, so dass danach von anonymen Daten gesprochen werden kann. Allen derzeit vorliegenden Vorschlägen fehlt es an einem solchen expliziten Trennungsvorgang. "Wenn man sich hier nur auf technische Maßnahmen oder allein auf politische Beteuerungen verlässt, besteht ein großes Risiko der nachträglichen De-Anonymisierung." so Rainer Mühlhoff vom FIfF. Wir haben in dieser DSFA rechtliche, technische und organisatorische Anforderungen formuliert, deren Umsetzung in der Praxis eine wirksame und irreversible Trennung sicherstellen kann – nur unter diesen Voraussetzungen dürften die infektionsanzeigenden Daten ohne Personenbezug (iDoP) an alle Apps verbreitet werden.

Wesentliche Voraussetzung für Transparenz bezüglich der Umsetzung aller Datenschutz-Grundsätze nicht nur für Datenschutzaufsichtsbehörden, sondern gerade auch für die Betroffenen und die (Zivil-)Gesellschaft insgesamt ist die quelloffene Entwicklung von Server und Apps nebst allen ihren Komponenten beispielsweise als freie Software. Nur so kann es gelingen, Vertrauen auch bei jenen zu erzeugen, die nicht alle informationstechnischen Details verstehen. Ergriffene Maßnahmen müssen immer aktiv prüfbar gemacht und sauber dokumentiert werden.

Datenschutzanalysen betrachten die gesamte Verarbeitung von Daten, nicht nur die dabei eingesetzten Apps. „Die Grenzen der App sind nicht die Grenzen der Verarbeitung.“ erläutert Christian Ricardo Kühne vom FIfF. In der öffentlichen Diskussion und in den betrachteten App-Projekten wird Datenschutz nach wie vor auf den Schutz der Privatsphäre, also Geheimhaltung gegenüber Betreiberïnnen und Dritten, und auf Aspekte der IT-Sicherheit wie Verschlüsselung reduziert. Mit dieser Verengung der Sichtweise kommen die erheblichen, gesellschaftlich wie politisch fundamentalen Risiken, die wir in dieser Folgeabschätzung aufzeigen, nicht nur nicht in den Blick – sie werden zum Teil sogar verschleiert. „Aus dem Blickwinkel des Datenschutzes gehen die wesentlichen Risiken nicht von Hackerïnnen oder anderen Benutzerïnnen aus, sondern von den Betreiberïnnen des Datenverarbeitungssystems selbst.“ kommentiert abschließend Rainer Rehak, Vorstandsmitglied des FIfF.

Das Forum InformatikerInnen für Frieden und gesellschaftliche Verantwortung (FIfF) e. V. ist ein deutschlandweiter Zusammenschluss von gut 700 Menschen, die sich kritisch mit Auswirkungen des Einsatzes der Informatik und Informationstechnik auf die Gesellschaft auseinandersetzen. Unsere Mitglieder arbeiten überwiegend in informatiknahen Berufen, vom IT-Systemelektroniker bis hin zur Professorin für Theoretische Informatik. Das FIfF wirkt seit 1984 in vielen technischen und nichttechnischen Bereichen der Gesellschaft auf einen gesellschaftlich reflektierten Einsatz von informationstechnischen Systemen zum Wohle der Gesellschaft hin. Zu unseren Aufgaben zählen wir Öffentlichkeitsarbeit, sowie Beratung und das Erarbeiten fachlicher Studien. Zudem gibt das FIfF vierteljährlich die „FIfF-Kommunikation – Zeitschrift für Informatik und Gesellschaft“ heraus und arbeitet mit anderen Friedens- sowie Bürgerrechtsorganisationen zusammen.

Quelle

Gestern erschien das Update unserer Blogsoftware auf die Version 2.3.3. Das Update verlief wie immer problemlos.

This bugfix release Serendipity 2.3.3 will bring you quite some smaller and larger fixes and minor enhancements backported from our master branch:

• Update bundled event_mailer plugin to support forcibly sending mails on published blog entries and add the ability to prepend a mail body. Also fixes missing "keep strip tags" configuration option.


• Media Library: Checkboxes allow you to insert multiple media files in a kind of gallery. Fall back to single-asset view when just one file has been selected. Let checkboxes be selected when clicking on the asset title, and hide the the 'Insert all' button when no assets are selected.


• Media Library: Use the <video> tag for videos in the library and for inserting them into an entry.


• Media Library: Allow plugins to skip HTML block insertion to use their own markup.


• Fix: Media Library: Items that are not images now get the correct link.


• Fix: Media Library: Prevent renaming an asset into an existing file, resulting in deletion of both from disk and database.


• Fix: Media Library: Remember directory from last upload.


• Fix: Media Library: Missing variable initialisation when removing empty folders.


• Fix: Stop generation of default page every time when serving JS (functions_routing.php).


• Fix: Don't allow requesting an archive page that doesn't exist.
  Thanks to @lotharsm!


• Fix: Add valid HTTP referrer when trying to delete a trackback from the frontend.


• Fix: Update bundled plugin plugin_comments to wrap text at word boundaries only, removing spurious whitespace in comment output.


• Fix: Update bundled plugin event_bbcode to get roman numerals working.
  Thanks to Fabien Chabreuil!


• Fix: Force positive limits for number of entries shown on title page and in RSS feed and fix potential SQL error with limit set to 0 in serendipity_fetchEntries().


• Fix: Escape version string in update notifier to avoid potential for XSS.

You can download the release file and unzip it to your installation as usual, or update from within Serendipity using the Serendipity Autoupdate Plugin (serendipity_event_autoupdate).

Nach der jüngsten Diskussion auf der ClamAV Mailingliste über verschiedene Sicherheitsrisiken, die bei der Verwendung des ClamAV Unofficial Signatures Updater script über das ich hier mal berichtet hatte, auftreten können, hat Ralph Seichter "Fangfrisch" als sichere Alternative entwickelt. Es war zunächst für den persönlichen Gebrauch gedacht, aber es funktioniert so gut, dass er auch eine ausführliche Dokumentation dazu geschrieben hat, in der Hoffnung, dass andere auch Fangfrisch benutzen.

Der auf Version > 3.7 basierende Python-Code funktioniert zuverlässig auf diversen Servern, daher ist die Zeit reif für einen öffentlichen Beta-Test. Ralph Seichter ist dankbar für ein Feedback.

Ich teste das hier auf einem nicht öffentlichen Server unter Raspbian Stretch.

Seit ein paar Tagen läuft das Blog mit Serendipity 2.3.2 und PHP 7.1.33. Merkwürdigkeiten bitte wie immer per Mail oder XMPP melden.

Vor einigen Wochen wurde endlich LineAgeOS 16 für das OnePlus 6T veröffentlicht. Die Installation hatte ich seither vor mir her geschoben, obwohl ich das Handy voriges Jahr bereits gerootet hatte: Eine Konvertierung der Benutzerdaten über Systemgrenzen hinweg ist trotz Tools wie Titanium Backup nach wie vor nicht ganz trivial. Aber machbar, dachte ich mir und bin dann zur Tat geschritten. Da der root Zugriff unter unter dem Hersteller Betriebssystem OxygenOS Dank TWRP und Magisk zwar einwandfrei funktionierte, jedoch nach jedem Upgrade wiederholt aktiviert werden musste, dachte ich mir, daß ich dann eigentlich gleich LineAgeOS installieren könnte. Also Backup anfertigen, ins Recovery booten und dann erst LineAgeOS, dann OpenGapps und Magisk installieren. Dabei ging irgendetwas schief - möglichweise war das TWRP von Bluespark  nicht ganz unschuldig daran, soweit ich mich entsinne, hatte sich dieses nur in einen der beiden Slots installieren lassen. Jedenfalls scheiterte der Versuch, das offizielle TWRP zu installieren mit der Meldung:

FAILED (remote: Failed to load/authenticate boot image: Load Error)

Nicht nur das, fortan weigerte sich das Mistding hartnäckig, überhaupt in Fastboot oder ins Recovery zu booten geschweige denn, TWRP zu flashen oder via fastboot zu starten. Also keine Chance, das Handy irgendwie zum Laufen zu bewegen. Toll. Verzweiflung macht sich breit. Ein gescheitertes Update führte in der Vergangenheit schließlich oft genug dazu, das teure Telefon zu "bricken" d.h. es war nur noch als teurer Briefbeschwerer und dem sozialen Umfeld zur Mahnung zu gebrauchen. Ich gebe zu, sogar einmal kurz die Supportseite angeklickt zu haben, um das Teil ggf. zur Reparatur einzuschicken. Aber nur für ca. 5 Sekunden. ;-)

Mit den entsprechenden Suchbegriffen bin ich jedenfalls bei xda-developers fündig geworden, wo es für diverse Geräte Unbrick Tools gibt, so auch für das OnePlus 6T. Solange sich das Gerät noch einschalten lässt, ermöglicht dieses (Windows)-Programm eine Wiederbelebung des Zombies. (Angeblich läuft das Programm auch in einer virtuellen Windows Maschine oder unter WINE, das habe ich jedoch nicht probiert, da ich zufällig noch einen Windows Rechner herumstehen habe.)

Das MsmDownloadTool v4.0.59 ist gute 2 Gigabyte groß, denn es enthält OxygenOS v9.0.13. Nach dem Start präsentiert sich das Programm sehr aufgeräumt. Zuvor sollte allerdings das Handy via Datenkabel mit dem Rechner verbunden sein und in der Systemsteuerung solltem QUSB_BULK oder unter Ports > Qualcomm angezeigt werden, was für den OnePlus Chipsatz steht.

Nach dem Start und einigen nicht sonderlich transparenten Aktionen, während derer an einen Kaffee trinken gehen kann, wird das Handy auf den Auslieferungszustand unter OxygenOS v9.0.13 zurückgesetzt, d.h. alle Daten sind weg. Sofern man kein Backup gemacht. Ach ja, und dieses auf einen entsprechenden, externen Datenträger gespeichert hat. Nicht nur wegen der fehlenden transparenten Aktionen bei der Wiederherstellung würde ich auf jeden Fall als erstes entweder TWRP flashen, /Data und /System wipen und das Originalbetriebssystem von OnePlus oder gleich LineAgeOS installieren. Das geht dann "einfach".

Und der Blutdruck sinkt. ;-)

Nach dem Update der Blogsoftware auf die aktuelle Version war mir nach einem neuen Outfit zumute. Daher läuft jetzt ein Test mit Bootstrap. Konfiguriert ist da noch nicht viel, kommt vielleicht, wenn ich Zeit und Lust dazu habe.

Social Media Links werden auch wieder eingesetzt. Die Leute verlangten danach. Natürlich DSGVO konform: Wir setzen das serendipity_event_social Plugin mit Shariff Unterstützung ein.