Beiträge von kk

    Hallo,


    wir haben eben die Version 3.2.8 veröffentlich (und auch die 3.3.0-Preview entsprechend aktualisiert, diese enthält auch alle Änderungen aus der 3.2.8).

    Primär bringt diese neue Version nun direkte Unterstützung von DMARC-Records mit - analog SPF kann ein Standard-Eintrag pro Mailserver definitiert werden (Serververwaltung -> E-Mail -> Postfix-Einstellungen), sowie pro Domain optional ein abweichender DMARC-Record gesetzt werden.

    Syntaktisch wird derzeit nur geprüft, ob der Record mit "v=DMARC1" beginnt, wir planen darüber hinaus noch umfangreichere Prüfungen (damit Endkunden da nicht versehentlich "kaputte" Einträge erstellen).


    Außerdem wurden mit diesem Update eine Hand voll Bibliotheken aktualisiert, für die es in den letzten Tagen Updates gab.


    Alle Änderungen finden sich wie immer im Changelog.


    Viele Grüße


    -Klaus Keppler

    Ich wage ja kaum zu fragen, aber wird die Version 2 das Feature auch erhalten?

    Die DMARC-Konfiguration pro (Sub-)Domain sicher nicht (das ist da tatsächlich zu aufwendig), den Default-DMARC (pro Mailserver) planen wir aber zu backporten. Wird morgen hier im Detail geprüft.

    Da es ja aber (angeblich) eine vorübergehende "Störung" bei Microsoft war, ist die Sache vielleicht nicht mehr ganz so dringend.

    (https://learn.microsoft.com/en…ion-error#answer-13038394)

    Das DMARC-Feature ist im 3er-Branch soweit implementiert und manuell getestet.

    Die Build-Pipelines laufen nun, in ca. 1 Std ist Version 3.3.0 (Preview) fertig, in ca. 1:45h dann der "Backport" in die 3.2.8 (Stable).


    Unter Serververwaltung -> E-Mail -> Postfix kann man nun einen Default-DMARC-Record festlegen (empfohlen: v=DMARC1; p=quarantine). LiveConfig setzt dann für alle auf eigenen DNS-Servern verwaltete Domains entsprechende DMARC-Records - außer es existieren bereits manuelle Einträge.


    Zudem hat man in den (Sub-)Domain-Einstellungen die Möglichkeit, einen eigenen (abweichenden) DMARC-Record festzulegen. Und natürlich kann man weiterhin komplett eigene DNS-Einträge der Form _dmarc.<domain> anlegen.


    Das Handbuch wird morgen Vormittag entsprechend erweitert.


    Ich geben hier später noch mal Bescheid, sobald die Pakete in den Repositories bereit stehen.

    Hallo,

    seit der Nacht von Donnerstag auf Freitag (05./06. November) lehnt Microsoft (Outlook/Hotmail/Yahoo/AOL) offenbar E-Mails ab, deren Absenderdomain keinen DMARC-Record aufweist (SPF und DKIM spielt dabei keine Rolle).


    Aus technischer Sicht ist das absurder Blödsinn (SPF und DKIM sind die entscheidenden Mechanismen zur Spam-Erkennung, DMARC empfiehlt ja wiederum nur dem Empfänger-Server, was dieser mit nicht-konformen Mails machen soll). Eine p=none-Policy genügt Microsoft ja auch schon, was die Sinnlosigkeit dieser Sache nur unterstreicht.


    Da Microsoft das aber voraussichtlich nicht zurücknehmen wird, werden wir (sehr) kurzfristig in LiveConfig die Möglichkeit zur (Massen-)Verwaltung von DMARC-Records hinzufügen, analog SPF-Records.

    Wenn nichts dazwischen kommt, wird das Update heute im Laufe des Tages erscheinen.


    Viele Grüße


    -Klaus Keppler

    The PHP packages for older versions provided by us (see here) also contain the patches against php2shell, so this would have been the most simple way to just install php-7.4-opt.

    How do the permissions for /etc/liveconfig/lua.d/ and the files therein look like? (please run ls -al /etc/liveconfig/lua.d).

    Weil wir einige Rückfragen diesbezüglich hatten und haben, hier noch ein paar Informationen/Nachträge zu den Patches:

    • Unsere PHP-Pakete für PHP 5.6 bis 8.1 basieren auf den Security-Backports von Remi Collet (php-src-security).
    • Die php2shell-Patches sind dort "nur" für PHP 7.2 bis 8.1 vorhanden, für PHP 5.6/7.0/7.1 haben wir den Patch aus den Paketen von Ondřej Surý (deb.sury.org) integriert.
    • Am 22.10. gab es bei den Paketen von deb.sury.org noch mal ein Update; hier wurde aber "nur" ein Patch für GHSA-54hq-v5wp-fqgv integriert, der in dem Repository von Remi Collet bereits integriert war (deshalb betrifft das "unsere" Pakete nicht).
    • Es gibt zudem ein alternatives Patch-Set von Anton Barinov; eigenen Angaben nach sind diese etwas umfangreicher und führen zu keinem Fehler beim Upload-Progress-Bar bei einigen Anwendungen. Wir haben uns diese angesehen (schaut auf den ersten Blick alles plausibel aus), uns aber dafür entschieden beim "offiziellen" Minimal-Patch der PHP-Foundation zu bleiben - schlichtweg weil dieser Pfad vermutlich intensiver deployed/getestet ist. Wer Probleme beim Upload mit PHP 5.6-8.1 hat, möge doch bitte auf ein aktuelles PHP wechseln...

    Vielen Dank für die vielen positiven Rückmeldungen!

    Ich gebe das Lob aber auch an das gesamte Team weiter, welches hier hinter den Kulissen mitgemacht hat (und u.a. auch den kompletten Build-Cluster pflegt... alleine 10 Server für die PHP-Builds).

    Besonderen Dank auch an Jörg (der uns als allererster am 20.10. auf das anstehende Update aufmerksam gemacht hatte, noch vor allen Mailinglisten) und an Anton (der uns gestern Pizza ins Büro schicken wollte). :)

    Nicht unerwähnt bleiben sollten aber auch Arnaud Le Blanc und Ilija Tovilo, welche den Patch für die beiden CVEs entwickelt und maßgeblich für viele PHP-Versionen angepasst haben, sowie natürlich Remi Collet und Ondřej Surý für das Backporting von Patches in alte Versionen!


    PHP 8.6 steckt ja auch schon in den Startlöchern (wir werden RC4 in Kürze bereitstellen). Wo wir uns aber vermutlich alle einig sind ist, dass das mit PHP so nicht weitergehen kann. Alleine gestern haben wir zwölf Versionen auf sechs Distributionen und meist zwei Architekturen aktualisiert - das waren sage und schreibe 110 Builds mit insgesamt 902 (!) Paketen.


    Wir werden in den nächsten Wochen Strategien entwickeln, wie Kunden "einfacher" zu einer Umstellung auf aktuellere PHP-Versionen überzeugt werden können. Einige Ideen bzw. Feature-Requests gibt es ja schon (z.B. in der Webserver-Verwaltung eine Massen-Umstellung von PHP-Versionen).

    Weitere Vorschläge bislang sind noch:

    - eine Funktion zur gezielten Benachrichtigung betroffener Kunden (mitsamt einer Liste der betroffenen Domains/Subdomains)

    - PHP-Feature pro Domain (durch Kunden) deaktivierbar (z.B. bei statischen Websites)


    Unserer Einschätzung nach dürfte es nur eine Frage der Zeit sein, bis ähnlich kritische Sicherheitslücken gefunden werden; durch KI erhöht sich die Taktung ja dramatisch. Um so wichtiger ist es, die Prozesse rechtzeitig anzupassen.


    Viele Grüße


    -Klaus Keppler

    Die PHP-Versionen 5.6 bis 7.3 wurden nun auch aktualisiert - damit sind alle Pakete aller aktiven Distributionen (plus Debian 11 - aus Gnade) gepatched.


    Weitere Details dann morgen - heute war ein langer Tag. :)

    Wir stehen bereits seit kurz nach Mitternacht in den Startlöchern. Das Source-Update ist für 16:00 MESZ angekündigt, die Builds werden pro Distribution und Architektur rund 30-35 Minuten dauern und dann sukzessive bereitgestellt.

    Für PHP < 8.2 wird aber voraussichtlich noch nicht mit sehr kurzfristigen Updates zu rechnen sein (wir haben hierfür die Security-Backports von Remi Collet im Auge), möglicherweise gibt es aber einen Workaround für zumindest einen von zwei Angriffspfaden (Details folgen in Kürze, wir recherchieren noch und bereiten einen separaten Beitrag dazu vor).


    Viele Grüße


    -Klaus Keppler

    Hallo,


    danke für den Hinweis. Hier gab es leider einen Fehler beim Datenbankschema - Upgrades waren nicht betroffen, aber frische Installationen haben hier ein falsches Attribut (NOT NULL) in der betroffenen Spalte. Wir haben das bereits korrigiert, Version 2.19.4 ist eben in der Pipeline und wird dann in den nächsten Stunden online gestellt.

    Interessant... die Spalte PERMISSIONS.P_ID hat üblicherweise die "auto_increment"-Property.

    Wir haben eben mal ein Upgrade auf einem Debian 13 mit MySQL durchgetestet und hier keine Probleme feststellen können.

    Können Sie noch nachvollziehen, wie seinerzeit die Umstellung von SQLite auf MySQL erfolgt ist? Das mitgelieferte MySQL-Datenbank-Schema enthält auch auto_increment für die PERMISSIONS-Tabelle.