Ein dringender Hinweis an alle Blogger: Die aktuellen Cracker-Angriffe gegen WordPress gehen weiter. Jetzt gibt es massive Trackback-Spam, die gecrackte Blogs massiv verlinken soll. Die Vorgehensweise der Spammer bringt es mit sich, dass diese Trackbacks von Akismet nicht als Spam erkannt werden, und deshalb erreichen die Spammer ihr Ziel. Eine einfache Abhilfe gegen das Problem wird im verlinkten Text aufgezeigt. Bitte unbedingt die Konfiguration des eigenen Blogs anpassen.
Und ganz wichtig: Die Information verbreiten! ❗
(Der Text auf Unser täglich Spam ist von mir, er darf gern übernommen werden, als wenn er unter der Piratenlizenz veröffentlicht wäre.)
Lumières dans la nuit 
ach du…… als ausenstehender kann man das ganze auch sarkastisch betrachten……
vieleicht ist ja WP selber schuld sich solche aufmerksamkeit zu machen.
ein gesundschrumpen gehört meines erachtens mit zur evolutuion.
wie du öfters ansprichst, is da der zeitdruck mit drann schuld… und ich bezeichne das schlicht als blöd…..
wenn der (hypothetisch) überlebenskampf von markt mechanismen abhängt, ist man quasi nah am abgrund, denn diese mechanismen mögen sich ändern, aber der soll ist dann vieleicht noch nicht erbracht.
für jäger und sammler…. vor allem sammler im ursprung, also keine heuschrecken…… völlig unlogisch, denn man erfand ja auch die vorratskammer……
in einer welt von überfluss, werden grundbedürfnisse vergessen….. das spiegelt sich zum einen in der entfremdung von sich selbst, und zum anderen auch in der vermehrten armut in der gesellschaft…..
naja, als stiller beobachter hat vieleich wp nicht den stellenwert, den es vieleicht einnehmen will…. die entwicklung mit anbindung an firefox mag ja eine faszinierende erfindung sein, aber menschsein ist imho mehr als nur pure logic – oder die scripte heut zu tage einfach nur ausschuss zum gesellenstück.
atakke….
Na, vielleicht finden sich noch ein paar Leute, die Lust haben, bei einem Fork mitzumachen. Das erste Ziel: Entschlacken und Dokumentieren, um endlich wieder die Software den Menschen zurückzugeben. (Und alle Extras über die Plugin-Schnittstelle.) Das zweite Ziel: Maximale Kontrolle des Bloggers über alle Dinge, die im Moment verdeckt geschehen. Das dritte Ziel: Den ollen Dinosaurier so ablösen, wie es damals die kleinen Nager gegen die Dinos geschafft haben — aber bitte, ohne dass man die schon gemachten Fehler wiederholt.
Das ist leider das Schwierigste dabei…
Ansonsten habe ich mich eben mit Akismet in Verbindung gesetzt und denke mal, dass sich das Problem in den nächsten Stunden erledigt haben wird. Andere Plugins gegen Spam sind besser klargekommen.
klingt alles interessant 💡 😀
axo:
unabhängig von meiner kritik an WP wünsch ich dir natürlich dass du vielleicht ein paar interessenten an einem fork findest, wenn du das wirklich durchziehen möchtest.
was meine person betrifft. ich bin kein guter php hacker um mir sowas zuzutrauen.
Es soll irgendwann ja vielleicht GravitalisRS herauskommen, allerdings läge dann, wenn ich es richtig verstanden habe, das Schwergewicht nicht mehr auf der Blogfunktion, sondern mehr darauf, CMS-Funktionalitäten stärker in den Vordergrund zu rücken und den Usern die Anpassung zu erleichtern. Ich bin gespannt, was daraus wird, verspreche mir aber nicht allzu viel davon, weil es aus recht speziellen Zielsetzungen heraus entsteht.
Ansonsten ist weit und breit von einem Fork nichts zu sehen. So ein Projekt kann man nicht unterschätzen, daher wird die Zögerlichkeit kommen. Ich glaube zumindest, dass durchaus einige andere Fähige ebenfalls mit diesem Gedanken spielen, aber sich auf so etwas einzulassen, wenn man eigentlich genügend anderen Kram an der Backe hat, will auch gründlich überlegt sein.
Nebenbei: die Ablösung des Dinos fände ich dabei nicht wichtig. Das ist vielleicht als Zielstellung auch kontraproduktiv, weil der Eindruck entstehen könnte, Transparenz, Übersichtlichkeit und Sicherheit gehen unter dem Druck von Communitywünschen und Veröffentlichungsterminen dann genauso unter wie jetzt.
Zu LostBit (5): Na ja, die „Ablösung des Dinos“ und andere fiebrige Phantasien von „Weltherrschaft durch Software“ sollte ich vielleicht deutlicher als satirisch kennzeichnen, das ist schon wahr. 😉
Aber ich finde es schon beachtlich, dass ein gutes Viertel meiner hier installierten Plugins nicht mehr dazu da ist, Funktionen von WordPress zu erweitern (was ja der eigentliche Zweck eines Plugins wäre), sondern dazu dient, unerwünschte „Funktionen“ abzustellen (Nofollow-Auszeichnung von Links in Kommentaren, fehlerhaft „geschönte“ Anführungszeichen, überflüssige Datenhaltung, überflüssige Datenübertragung, sinnlose Meldungen im Dashboard) oder Fehler (mit Mailversand oder TinyMCE) in der hier verwendeten Version 2.3.3 zu umgehen. Würde ich jetzt den empfohlenen Update auf 2.5 machen, kämen weitere derartige „Plugins“ hinzu, um bekannte Probleme mit der Medienverwaltung zu umgehen. Diese Strokelei kann es doch wirklich nicht sein.
Jeder aktive WP-Blogger, der seine Software nicht völlig gedankenlos benutzt, könnte in seinen installierten Plugins ähnliche Beobachtungen machen können. Und jedes dieser Plugins kann bei einem Update auf eine neue Version Probleme bereiten und ist eher anfällig für Angriffe als das viel besser gesichtete Kernsystem von WordPress.
Ein Fork wird eine Mordsarbeit. Im Grunde ist 2.3.x ein gutes System (mit einigen Schwächen), das leider schlecht im Quelltext dokumentiert ist.
Die erste Aufgabe wäre wohl die Dokumentation des Standes, auf den man aufsetzen will. Hierzu sind Funktionen und Variablen so zu kommentieren, dass sich mit einem Tool wie Doxygen automatisch eine Doku für weitere interessierte Programmierer erstellen lässt, im Falle von Doxygen lassen sich dabei auch gleich Bugs und wichtige Todos kennzeichnen. Wenn man schon dabei ist, kann man auch gleich die Schnittstellen für Plugin-Programmierer und Theme-Designer im Quelltext dokumentieren, um für die Zukunft ein bisschen Sorge dafür zu tragen, dass diese Doku nicht unvollständig ist und der Release „hinterhinkt“. So etwas ist eine Strafe für jemanden, der Vater und Mutter erschlagen hat; niemand wird sich um solche Arbeit reißen.
(Den Mischmasch von Präsentation und Code in den Themes würde ich — trotz berechtigter Kritik an diesem Design — so lassen, denn er hat sich auch ein bisschen bewährt. Außerdem sollte im Bereich der Themes Kompatibilität angestrebt werden, da viele Blogger sich mit hohem Aufwand Themes gebaut haben, die sie gewiss nicht noch einmal anfassen werden, um auf ein schlankeres WordPress zu wechseln. Dass ich in einem Blog ein für 1.5.x gebasteltes Theme bis 2.3.3 verwenden konnte, zeigt, dass man auch im „richtigen“ WordPress manchmal an die Anwender denkt. Und das ist gut, denn für die ist es geschrieben.)
Was schon jetzt an WP auffällt, ist der immense Umfang von JavaScript-Code im Kernsystem. Zurzeit sind das 23766 Zeilen Javascript (gezählt mit
findundwcin*.js-Dateien, dabei wird also noch etwas „übersehen“). Dieser Codeumfang reflektiert die Entscheidung, eine Anwendung in einem Browser zu bringen, und wie man an den gegenwärtigen Problemen in 2.5 sieht, führt diese Entscheidung zu einer kaum noch beherrschbaren Komplexität des Kernsystemes angesichts der immer noch bestehenden Unterschiede in den Browsern. (Sowohl mit dem aktuellen Opera als auch mit dem IE 7 sind Funktionen nicht fehlerfrei benutzbar.) Allein deshalb sollte man sich fragen, ob diese Entscheidung nicht ein Fehler sein könnte, ob die auf diese Weise schlecht gemachte Anwendung nicht besser in einer „richtigen Anwendung“ aufgehoben wäre. Diese könnte entweder eine Clientsoftware für die XMLRPC-Schnittstelle sein, die mit Hilfe eines portablen Toolkits (Qt, wxWindows oder GTK — vielleicht aber auch Java) als Desktop-Anwendung läuft und alle Funktionen von WordPress zur Verfügung stellt, sie könnte aber auch (weniger gut) ein umfangreiches Java-Applet sein, das im Browser läuft. Wenn eine solche Anwendung entwickelt wird, können die serverseitig zur Verfügung gestellten Funktionen auf ein sinnvolles Minimum (zum Beispiel kein voll aufgeplusterter WYSIWYG-Editor) reduziert werden, die aber für viele Blogger schon ausreichen werden. Man muss ja nicht gleich auf den WP-1.5-Stand zurückgehen, wenn es um den Upload von Dateien geht, 2.3 ist da gut brauchbar.Viele Funktionen des Kernsystems gehören meiner Meinung nach in Plugins, die man auch ruhig mit dem Kernsystem ausliefern könnte.
Alles, was an WP gut ist, sollte belassen werden. Dazu zählt zum Beispiel die Benutzerschnittstelle von WP 2.x, die meiner Erfahrung nach auch von Anfängern und technischen Laien gut verstanden wird. (Ob die wohl immer so schnell herausfinden werden, dass man in WP 2.5 einen Link in der Blogroll unter „Schreiben“ anlegt?)
Aber alles, was an WP schlecht ist, sollte überarbeitet werden, auch wenn auf diese Weise eine gewisse Inkompatibilität entstehen kann. Zum Schlechten gehört ohne jeden Zweifel das gegenwärtige Design des Zugriffs auf die Datenbank. Jeder Autor eines Plugins ist dafür verantwortlich, seine Variablen selbst mit
$wpdb->quote()zu quoten, was das Gesamtsystem anfällig für SQL-Injections durch ein schäbig programmiertes Plugin macht. Dies ist die häufigste Quelle von Sicherheitsmeldungen, und man kann durchaus sagen, dass WP an dieser Stelle durch sein Design unsicher ist. Deshalb sollte diese Schnittstelle verworfen und durch ein anderes Konzept ersetzt werden. (Einfach zu machen wäre die Angabe eines Formatstrings und einer variablen Liste von Parametern, die dann in der Datenbankklasse gequotet werden.) Das zieht natürlich nach sich, dass man den gesamten Code anfassen muss, um die immerhin 1149 Verwendungen der Instanz$wpdbanzupassen. Eine Erleichterung wäre aber, dass fortan die Verwendung des konfigurierten Präfixes für die Tabellennamen nicht mehr in der Verantwortung des Anwenders der Klasse läge, der hierzu ein paar Instanzvariablen hat, sondern dass sie durch einfache Textersetzung bei der Verarbeitung einer Query vorgenommen werden könnte.Angesichts der gegenwärtigen Angriffe auf WP-Blogs wäre ich auch sehr dafür, dass im Dashboard Warnungen angezeigt werden, wenn die Zugriffsrechte das Überschreiben von Dateien des Kernsystemes, der Themes und der Plugins mit den Rechten des Webservers ermöglichen. Viele Nur-Anwender scheinen sich derartiger Gefahren gar nicht bewusst zu sein, bis sie dann schließlich sehen, dass ihr Theme auf einmal versteckte Spamlinks enthält. Die Textareas zum Bearbeiten von Theme und Plugins würden dann natürlich wegfallen. Da es Widgets für die Themes gibt, scheint mir diese Möglichkeit auch nicht so wichtig wie in früheren Versionen, wo man oft mal ein oder zwei Zeilen schnell in die Sidebar aufnehmen wollte.
Wie gesagt, eine Mordsarbeit wird das alles. Und im Moment sehe ich niemanden, der dabei mitmachen will. Mein Beitrag als Coder an einem solchen Fork könnte durchaus groß sein, aber ich kann es mir als obdachloser Bettler nicht einmal leisten, das entstehende Produkt hosten zu lassen. (Eine einfache, billige Webpräsenz tut es nicht, wir brauchen einen richtigen SVN-Server für das kollektive Arbeiten an Quelltexten.)
Ich habe nicht einmal die Hälfte verstanden von dem, was Du geschrieben hast. 😉
War es nicht so, dass Eingaben durch eine zentrale Prüfung durchgeleitet werden sollten, um die Gefahr von Injections zu verringern und den Wartungsaufwand zu senken? (Sorry, wenn das verquer ausgedrückt ist, ich bin da nicht vom Fach und habe die Meldungen zu WP auch nur oberflächlich gelesen.)
Wenn ich im Lotto gewinne oder ein reicher Erbonkel stirbt, schaffe ich Dir ein Dächlein und einen Server ran, das Problem wird dann nur noch sein, Leute zu finden, die Vater und Mutter erschlagen haben. *g*
Muha, der skizzierte Projektaufwand ist so gewaltig, dass es für mich arg abschreckend klingt. Wahrscheinlich auch für Leute, die das könnten, zumal die ja meistens sowieso schon viel zu tun haben. Hmpf. Wenig Hoffnung. 😥
Zu LostBit (7):
Ach, und ich dachte schon, ich könnte einmal ungebremst Techspeak von mir geben… 😉
Nur noch mal zur Datenbank. Wenn man im Moment eine Query macht, muss man etwa so vorgehen (das ist hier vereinfacht). Nehmen wir einmal an, wir wollen die Kommentare zu einem Post.
global $wbdb;$id = $wpdb->quote($id);
$res = (array) $wpdb->get_results("
SELECT * FROM {$wpdb->comments}
WHERE comment_post_ID = ‘$id‘
");
Dieses
$idist eine PHP-Variable, die direkt in die Query eingebettet wird. Und dieses{$wpdb->comments}ist eine Instanzvariable der Instanz für den Datenbankzugriff, die den Namen der Kommentartabelle mit dem passenden Präfix enthält.Die
$idhier ist in der Regel etwas, was vom Leser beeinflusst werden kann. Deshalb ist es erforderlich, eventuelle Sonderzeichen zu quoten, indem man$wpdb->quote()aufruft. Tut man das nicht (und ich habe schon Plugins gesehen, die das nicht tun), denn könnte ein Angreifer unter Umständen dafür sorgen, dass folgendes in der Variablen$idsteht…$id = "1‘; DELETE * FROM ‘wp_posts";…denn haben wir eine SQL-Injection; und zwar in diesem Fall eine, die sämtliche Posts löscht. (Dafür muss der Angreifer das Tabellen-Präfix kennen. Dies wird aber oft der Vorgabe entsprechen. Allein deshalb sollte jeder das Präfix in seiner Konfiguration anpassen, um diesen Angriff zu erschweren.) Die Verantwortung für die „Entwertung“ der Sonderzeichen liegt also stets dort, wo eine Query gemacht wird.
Diesen Art Zugriff auf die Datenbank würde ich am liebsten abschaffen. An seine Stelle sollte etwas treten, das folgendermaßen verwendet wird:
global $wpdb;$res = (array) $wpdb->get_results("
SELECT * FROM comments
WHERE comment_post_ID = #
", $id)
Der Unterschied hier ist, dass
$idals Parameter für einen Funktionsaufruf ist. Es liegt in der Verantwortung dieser Funktion, eventuelle Sonderzeichen für die Abfrage zu entwerten, so dass dieses Versehen nicht mehr möglich ist. Des weiteren sollte eine solche Funktion auch gleich die Namen der Tabellen mit dem entsprechenden Präfix versehen, bevor die Query auf die Datenbank losgelassen wird. Die alte API sollte verworfen werden, die neue Schnittstelle sollte die alte völlig ersetzen. Im Kernsystem sind dies zum größten Teil recht kleine Änderungen, aber es führt eine Inkompatibilität zu diversen Plugins ein.Hm, und ich dachte, gerade bei der API hätte sich mit 2.5 Entscheidendes verbessert, das genau in diese Richtung geht.
Nein, das hat sich nicht verändert. Es gibt zwar einen deartigen Eintrag im WordPress-Trac, der wird aber immer wieder auf die nächste Version verschoben…
Zu Nachtwächter (10):
insecure by design
sowas müsste an oberster stelle für einen versionssprung stehen.
da die verantwortung für unsicherheit aber scheinbar bei den 3pd entwicklern liegt, können die wp-entwickler seelenruhig ihre hände in den schoss legen….. ja, so menschen muss man vertrauen 😆
Ja, die Erwartung habe ich eigentlich auch immer. Aber so, wie der Veröffentlichungsrhythmus stur befolgt wird, können wir wohl damit rechnen, dass selbst 3.0 eher ein Kosmetik-Release sein wird. 👿
Grmfbrmblmbm, dazu fällt mir nix mehr ein.
Aber vielleicht gibt es bis dahin ein paar Leute, die sich lieber an einen Fork machen, bevor sie jemanden erschlagen.
Zu LostBit (12): Bei den WordPress-Entwicklern hat eine ganz schlimme Idee in das Gehirn gebissen, und das ist die Idee des „Wachstums“. Das System muss immer größer und mächtiger werden, und zwar sichtbar, damit man auch immer wieder über das Wachstum berichten kann.
Bei einer kommerziell vertriebenen Anwendung wäre das verständlich, es wäre eine Maßnahme der Reklame. Die meiste kommerzielle Software enthält heute Features, die nur einer Minderheit ihrer Anwender überhaupt bekannt sind, während sich die Mehrzahl der Anwender mit jenen Funktionen begnügt, die schon vor vielen Jahren zur Verfügung standen. Um auch jenen Menschen, die niemals eine neue Funktionaltät benötigen, einen Eindruck des „Wachstums“ zu geben, wird vor allem an der grafischen Präsentatation herumgeschraubt, die selbst bei „professionellen“ Anwendungen immer trickreicher (und tendenziell etwas infantil) wird. Der Unterbau aus älteren Zeiten hingegen, der macht oft Probleme — es gibt heute noch Fehler in MS Word, die ich seit der Version 6.0 kenne.
Ich glaube, die Parallelen zur gegenwärtigen Entwicklung bei WordPress sind deutlich genug.
Ebenfalls sollte aber deutlich sein, dass so eine Herangehensweise bei einer freien Software gar nicht nötig ist, einfach deshalb, weil keine Reklame benötigt wird. Wo kein kommerzieller Druck besteht, besteht durchaus die Möglichkeit, Dinge gründlich und gut zu machen. Diese Möglichkeit wird leider immer seltener wahrgenommen, nicht nur WordPress ist ein Beispiel hierfür. (Auch mein geliebtes Linux ist an vielen Stellen nicht mehr das, was es mal war: Ein kleines, schmales System, das einfach nur tut, was ich von ihm will. Dieser Pinguin hat doch gewisse Auswüchse bekommen, die ihn etwas monströs erscheinen lassen.)
Die Nachäffung des Projekt- und Zeitdrucks einer kommerziellen Anwendung ist sinnlos. Für die Entwickler. Und. Für die Anwender. Die einzigen, die im Moment etwas von den Fehlern haben, die sich bei diesem unangemessenen Prozess anhäufen, sind die Spammer und Cracker.
An sich ist ein Blog eine sehr einfache Art der Publikation. Es handelt sich um eine chronologisch geordnete Liste von Beiträgen, die eventuell zusätzliche Auszeichnungen enthalten (Kategorien, Schlagwörter). Dies kann ergänzt werden um einige statische Seiten oder eine Liste von Links. Es muss doch möglich sein, diese Grundfunktion eines Blogs so zu implementieren, dass sie für einen Anwender gut benutzbar und in ihrem Kern fehlerfrei ist! Wer ein Blog verwendet, tut dies ja nicht, weil er in Wirklichkeit ein vollwertiges CMS haben möchte, dieses gäbe es übrigens auch schon. Sondern. Er tut es, weil er bemerkt, dass diese relative Strukturlosigkeit der veröffentlichten Inhalte ein Vorteil ist, der das Veröffentlichen leicht macht. (Übrigens auf Kosten der Leser, die manchmal Probleme haben, sich in dieser Strukturlosigkeit zurechtzufinden.)
Ein Fork sollte sich wieder auf die Grundfunktion eines Blogs besinnen. Und. Er sollte nicht versuchen, eine komplexere Anwendung im Browser laufen zu lassen, sondern lieber danach streben, das Grundsystem fehlerfrei zu kriegen. Die Anwendung gehört meines Erachtens auf den Desktop.
Wobei ich annehme, dass dies bei WordPress v.a. daher kommt, dass Automattic mit der WordPress.com-Community ja doch etwas mehr „unter Druck“ steht (oder sich selbst unter Druck setzt) als andere freie Blogsysteme, z.B. durch die Bezahlfeatures dort. Die .com-(Bezahl)user erwarten was für ihr Geld, sie wollen ihr Theme selbst gestalten, ihr Blog individualisieren können, und das alles soll möglichst einfach und bequem sein, und hübsch natürlich auch, und Automattic muss natürlich reagieren. Dass es dann in die Downloadware einfließt, bzw. vice versa Anregungen zu dieser zurück nach .com, ist okay, aber es scheint mir, sie versäumen, sich Zeit zum Luftholen und Überblick zu nehmen.
Oder anders gesagt: Community und Entwickler wurden „falsch erzogen“ (nehme ich zumindest an; es liegt ja v.a. in der Hand der Projektvorderen, Richtlinien zu setzen). Es hat sich eine Eigendynamik entwickelt, die das Projekt in Hyperventilation treibt. Erwartungen und Ansprüche liegen mehr auf zusätzlichen Features, und weniger auf Konsolidierung und Sicherheit.
Naja, es ist ohnehin müßig, darüber zu spekulieren, wie das zustande kommt. Deiner Kritik stimme ich zu und denke auch, dass es besser wäre, WP mal einer Grundreinigung zu unterziehen. Ich würde Dich ja gerne unterstützen, aber ich komme leider nicht wirklich in die Sache hinein. Schon mehrmals habe ich begonnen, PHP zu lernen, aber dann kommt immer wieder irgendwas dazwischen, was mir wochen- und monatelang die Zeit stiehlt, ich vergesse fast alles, muss neu anfangen, wieder Unterbrechung, wieder vergessen … auf diese Weise kann es sich höchstens noch um ein halbes Jahrhundert handeln. *g* (In Wirklichkeit habe ich es inzwischen aufgegeben damit.)
Dennoch, ich könnte mir vorstellen, dass es einige fähige Leute gibt, die sich danach sehnen, aus dem Hamsterrad herauszukommen und lieber mit mehr Ruhe und Umsicht an etwas Solidem zu arbeiten. Ich hoffe, dass die sich dann nicht gleich etwas anderem zuwenden, sondern mal Deine Beiträge durchlesen und sich die Sache durch den Kopf gehen lassen.
Zu LostBit (14): ohjeeeeeeeee…. ich wusste garnicht dass wordpress auch kommerziell ist – danke für die info!
für mich wieder ein grund mehr diese software nie wieder einzusetzen!
Nur zur Erklärung: Die Software an sich, WordPress, ist frei.
Dass Automattic kommerzielle Services betreibt, von denen einer auch noch so heißt wie das freie Blogsystem (den man aber auch kostenlos nutzen kann, dann eben nur mit mehr Einschränkungen), hat höchstens Auswirkungen auf die Gewichtung der Aufgaben, und das wahrscheinlich auch nur im engeren Automattic-Umfeld (einige Entwickler sind bei Automattic angestellt, und Cheffe von Automattic ist quasi auch Cheffe der WordPress-Entwickler, in dem Sinne, dass er das letzte Wort spricht).
Sorry, wenn ich für Verwirrung gesorgt habe.