Ouch... Das scheint eine Breitseite für dnsmasq zu sein. Gerne genommen in allen möglichen Cloud stacks um die VMs mit IP Adressen zu versorgen.

Sollte jeder mal schnell nachsehen. OpenWRT und diverse CPEs auf Linux Basis könnten auch noch betroffen sein.

Mir war das gar nicht so aufgefallen die letzten Jahre das dinge wie httpredir.debian.org etc einzug gehalten haben. Ich hatte die diskussion um die sicherheit von HTTP Redirects verfolgt (Ursprünglich ist apt keinen redirects gefolgt). Heute habe ich dann mal gesucht was es mit dem cdn-fastly so auf sich hat und wieder ein Erkenntnisgewinn in diesem Debian Wiki Artikel.

Alles was wir kannten ist Deprecated. Wer also noch ein httpredir.debian.org, cdn.debian.org, oder debian.net deb sources in der apt/sources.list findet kann das alles rauswerfen. Das zu nutzende CDN ist deb.debian.org was von Fastly und Amazon Cloudfront bereitgestellt wird.

An der ganzen Apple APFS Encryption Geschichte finde ich eigentlich nicht das Faktum interessant das das Password angezeigt wird. Am ende ist das ein kleines Programmierfehler

- printf("%s", password);
+ printf("%s", hint);

Fixed. Was ich viel spannender finde.

WARUM HABEN DIE DAS KLARTEXT PASSWORD?

Normalerweise sollte mit dem Password nur der encryption key unlocked und dann vergessen werden. Das Klartext Passwort sollte nirgends gespeichert werden und am besten nicht einmal im Speicher oder Swap verbleiben.

Das ganze Thema ist mega fishy. Da ist mehr kaputt als nur das einzeigen eines Passwords - Da ist das gesamte Handling von Passwörten und Encrpytion Keys kaputt. Und wenn man mal ehrlich ist hört sich das einer semi einfachen Backdoor an. Da ist irgendwo das Passwort - man muss es nur finden.

Ist das wirklich pfiffig das der Bind ab version 9.9 die secondary zonen, also die für die er slave ist, als binary im filesystem ablegt?

Binary formate haben ja oft das problem das wenn sie corrupten sie auch wirklich gleich ganz verloren sind. Im Ascii file kann der Mensch noch dinge reparieren. Deshalb halte ich u.a. das systemd-journald Thema für abgrundtief kaputt.

Damit ist das mit dem "wir gucken uns mal eben die zone an" auch vorbei.

0x00000000: 00000002 00000001 59D7DE61 00000000     ........Y��a....
0x00000010: 00000000 00000000 00000068 00010006     ...........h....
0x00000020: 00000036 EE800000 00010012 0C726F6F     ...6�........roo
0x00000030: 742D7365 72766572 73036E65 74000040     t-servers.net..@
0x00000040: 01610C72 6F6F742D 73657276 65727303     .a.root-servers.
0x00000050: 6E657400 056E7374 6C640C76 65726973     net..nstld.veris
0x00000060: 69676E2D 67727303 636F6D00 783A3E14     ign-grs.com.x:>.

Dazu kommt das das space saving eher marginal ist:

-rw-r--r-- 1 bind bind    1929 Oct 11 07:25 root-servers.net
-rw-r--r-- 1 root root    2505 Oct 11 09:44 root-servers.net.ascii

Und man kann die raw Files natürlich konvertieren - was aber länger dauert als das parsen/laden einer ASCII Zone mit dem Bind was mir völlig unerklärlich ist.

Dazu kommt das named-compilezone ziemlich komisch agiert. Wenn ich den namen der Zone nicht kenne oder falsch angebe dann lässt sich das Zonefile nicht von raw nach ASCII konvertieren. D.h. im raw File scheinen Informationen zum verstehen des Files zu fehlen.

Ausserdem scheint named-compilezone auch noch Netz zu brauchen um Glue records aufzulösen. Das finde ich an sich schon absolut Kaputt. Wenn dann auf der ISS oder in der Neumayer Station am Nordpol jemand lokale Zonefiles konvertieren muss geht nichts weil gerade der Satellitenlink kaputt ist. Kritische Infrastrukturkomponenten wie DNS, DHCP, Authentisierung müssen im Zweifelsfalle ohne externe Abhängigkeiten funktionieren.

Alles in allem keine wirklich vertrauenserweckende Lösung.

Es scheint aber die möglichkeit zu geben wieder zum alten Verhalten zurück zu kommen in dem man in allen Slave zonen ein

masterfile-format text;

setzt.

Die sind ja süß von der Sparkasse. Beim ersten Einloggen auf den Webseiten der jetzt fusionierten Sparkasse Gütersloh-Rietberg zeigt die Sparkasse mir meine Stammdaten an und bittet um bestätigung.

Soweit macht das ja Sinn - Ab und zu mal dem Kunden die Stammdaten zeigen.

Aber was entdecken da meine Augen. Angeblich habe ich der Werbung auf den Telefonnummern zugestimmt. Ich bin mir ganz sicher das ICH das nie gemacht habe. Ich bin der erste der solche Absätze in irgendwelchen Verträgen sofort streicht und ganz genau liest.

Also - Wollen wir das ändern. Da reicht nicht etwas da Häkchen wegmachen. Man muss jeden Haken einzeln mit dem TAN Generator bestätigen.

Nachdem ich die Telefonnummern durch habe fällt mir auf das eine entsprechende Spalte bei der Adresse fehlt. Warum? Also mal auf Adressdetails editieren und auch da ein Haken das Werbung erwünscht sei. Also auch den eliminiert.

Und hinterher gleich noch eine Mail an die Sparkasse wo wir der Werbung explizit mit Unterschrift zugestimmt haben. Ich bin mir sicher das ich das nie habe.