Apple scheint sich da gerade ein "Hase und Igel"-Spiel mit den Malware-Schreibern zu leisten bzw. darin verwickelt zu sein.

Apples XProtect.plist ist mittlerweile bei Version 5 angelangt (also bereits 4 Apple Updates seit Bestehen dieser neuen Funktion), alle paar Stunden gibt's da seitens Apple derzeit ein neues Update zum Abholen. Alle paar Stunden wird eine neue MacDefender-Variation geboren, eine davon treibt derzeit u.a. bei Facebook ihr Unwesen und versucht sich zu verbreiten. Mittlerweile gibt's auch schon Variationen, die manche als MacDefender.E, MacDefender.F und MacDefender.G bezeichnen. Apples XProtect hat bisher die Signaturen bis MacDefender.E.

Apple verwendet zudem etwas andere Signaturen als verschiedene AV-Software-Hersteller, muss offenbar auch öfters updaten. Die derzeit in den Netzen rumwandernden MacDefender-Variationen werden von anderen AV-Software-Herstellern zum großen Teil bereits durch frühere Signaturen erkannt, welche vorausschauenderweise ein breiteres Spektrum an Variationen pro Signatur abdecken, sodass es auf deren Seite diesbzgl. derzeit weniger Anlass gibt, ständig mit den Signatur-Updates hinterherzuhecheln, so wie Apple es grad' wohl tun muss.
Clamav z.B. deckt mit seinen bisherigen Signaturen MacDefender.A bis MacDefender.C auch die gerade kursierenden Erscheinungsformen von MacDefender ab und erkennt sie, welche andere und insbesondere Apple derzeit als MacDefender.E und MacDefender.F klassifizieren (müssen).

Wer Apples voreingestelltem 24-Update-Rythmus vertraut, der bekommt davon wohl nix mit, und der wartet im ungünstigsten Fall ewig auf Apples Updates, weil er, wenn es ungünstig läuft, genau dann, wenn das Update von launchd angestoßen werden soll, nicht online ist (z.B. beim Hochfahren des Rechners oder bei Laptops, die nicht sofort eine Internetverbindung haben, wenn sie hochfahren).

Also im Moment wohl besser mal ab und zu häufiger das Ganze manuell anschieben im Terminal und von einem Admin-Account aus mittels sudo /usr/libexec/XProtectUpdater mit ggf. sofortigem Ergebnis und sofortiger Änderung der XProtect-Liste, sollte Apple diesbzgl. was bereitstellen.

Bin mal gespannt, wie lange dieses Spiel noch weitergeht, das Apple Security-Team dürfte im Moment jedenfalls ganz gut zu tun haben, ständig alle paar Stunden neue Updates für die XProtect.plist raushauen zu müssen...
Vielleicht ist der in MacOSX voreingestellte Rythmus für die automatischen Updates von 24 Stunden unter diesen Umständen doch etwas zu groß und unpraktisch bemessen und sollte verkleinert bzw. auf mehrere Zeitfenster pro Tag verteilt werden, um die Chancen zu erhöhen, dass die Anwender diese Updates auch rechtzeitg und vor allem frühzeitig genug bekommen...

sierkb
Man pages zitiert, aber den eigenen Fehler weiter ignoriert:

MacMark:

Es ist ja toll, dass wir beide darin übereinstimmen, dass launchd an sich funktioniert (ich habe nirgendwo bestritten, dass in diesem Fall launchd nicht korrekt funktioniert! Ich habe lediglich deutlich gemacht, dass so, wie die betreffende Plist-Datei, welche von launchd abgearbeitet werden soll und die darin angegebenen Zeitpunkte/-Intervalle problematisch und verbesserungsbedürftig sind).
Und dass es anscheinend zudem auch noch Probleme mit der Zuverlässigkeit des zugehörigen PrePanes gibt.

Du scheinst immer noch nicht zu begreifen, dass es überhaupt nicht darum geht, launchd selber infrage zu stellen. Das Ergebnis, das bei dem Ganzen rauskommt, davon leite ich meine Argumentation ab!
Und im Ergebnis funktioniert's eben bei zahlreichen Nutzern in der Praxis nicht so, wie es theoretisch sein sollte! Da kann launchd noch so stoisch und akkurat seinen Terminplan abarbeiten, wenn der regelmäßig ins Leere greift und die Aufgabe, die er per auszuführen hat (nämlich zu schauen, ob es ein Update für XProtect-plist gibt, wenn ja, es runterzuladen und sich dann wieder schlafen zulegen), wird nicht erfolgreich ausgeführt, dann ist da irgendwas gelinde gesagt suboptimal von Apple angelegt und ganz sicher nicht im Sinne der eigentlich angedachten Sache.
Zudem stimmt es eigenartig, dass es da draußen Nutzer gibt, die drüber berichten, dass ihre XProtect.plist-Datei offenbar seit Tagen nicht angerührt worden ist, obwohl ihr Rechner ständig online ist. Und sie erst eine aktualisierte XProtect.plist erhalten haben, nachdem sie den Vorgang manuell angestoßen hatten. Irgendwas ist da also faul. Um launchd und sein Uhrwerk selber geht es bei dem Ganzen nicht!

Du scheinst es immer noch nicht verstanden zu haben, dass es hier nicht um die Funtionsfähigkeit oder Nicht-Funktionsfähigkeit von launchd selber geht, sondern dass die Funktionalität als solches und vom Ergebnis her (und nur das ist relevant -- das Ergebnis!) des XProtect-AutoUpdates nicht so ist wie sie ein soll! Was nützt ein ans sich funktionierender launchd-Dienst (ich habe immer vom Ergebnis her aus argumentiert), wenn das, was er bewirken soll, nämlich regelmäßige automatische Updates der XProtect.plist vorzunehmen, vom Ergebnis her offenbar nicht zuverlässig und berechenbar funktioniert (und z.B. ein in direkter Abhängigkeit des Update-Ergebnisses kein zeitlich unmittelbares automatisches Nachholen angestoßen wird, bis ein erfolgreiches Konnektieren mit Apples Server erfolgt ist).

Inzwischen liegt XProtect.plist übrigens bei Version 7, die Signaturen von MacDefender.C, MacDefender.D, MacDefender.E, sind entgegen der bisherigen Einzelnennung inzwischen in einer Signatur als MacDefender.CDE zusammengefasst, und eine weitere Signatur für MacDefender.F ist hinzugekommen. Apple scheint da also zu lernen und seine Signaturen nun ziemlich ähnlich wie es die AV-Hersteller auch machen, so abzufassen, dass sie gleich mehrere Variationen desselben Malware-Typs in einer Signatur zusammenfassen bzw. die betreffende Signatur etwas generöser abzufassen, sodass gleich mehrere Variationen desselben Malware-Typs von dieser Signatur erfasst und abgedeckt werden.

Wir haben jetzt Tag 7 seit Apples letztem Snow Leopard Security Update und seite Einführung des XProtectUpdaters. Im Schnitt also 1 Aktualisierung von XProtect-plist pro Tag (gestern sogar 2mal pro Tag). Mal sehen, wie es weitergeht und ob der Trend anhält und wir nächste Woche bei Version 14 von XProtect-plist angelangt sind...

Bei mir zählt auch gute Detailarbeit, nicht nur das Ergebnis.

Apple verwendet wohl weiterhin straight hashes, ansonsten hätten sie mit einem Update auch den Mechanismus und nicht nur die Signatur-Datei austauschen müssen. Sie können C, D und E mit einem Eintrag abdecken, weil C, D und E offenbar die gleichen drei signifikanten Dateien im Installationspaket (das ist ein Verzeichnis) enthalten. Die restlichen Dateien werden für die Entscheidung ignoriert.

Dann würdest Du grundsätzlich anders argumentieren, wenn es Dir wirklich um die Sache ginge. Dir geht es in erster Linie nicht um die Sache, Dir geht es in erster Linie darum, Apple gegen Kritik zu verteidigen. Und am Ende das letzte Wort zu haben. Deine Detailversessenheit bei Details, die eigentlich gar nicht zur Debatte stehen und nur, um irgendwie Recht zu bekommen und das letzte Wort zu haben, ist eigentlich regelmäßig nur noch eine einzige Karikatur. Das kann zumindest ich irgendwann einfach nicht mer Ernst nehmen, tut mir leid.
Nicht ein einziger Satz, nicht ein einziges Zugeständnis von Dir, dass Apple hier in dieser Sache etwas nicht ganz Stimmiges und nicht ganz so Funktionales abgeliefert hat, wie es im Sinne des zu erzielenden Ergebnisses eigentlich sinnvoll und richtig gewesen wäre.
Dein fast grundsätzliche Kritiklosigkeit und fast grundsätzliche Schönrednerei betreffend allem, was Apple hier macht, und Dein ja teilweise recht aggressives und pro-aktives Verteidigen gegenüber allem, was auch nur nach Kritik riecht, entwertet Deine Argumente im Detail. Anstatt einfach mal ganz offen zu sagen: "Ja, in der Tat, das ist suboptimal gelöst von Apple und nicht so, wie es vom Ergebnis her eigentlich sinnvoll wäre, da müssen die wohl noch nachregeln!"

Nachdem sie zuvor 3 jeweils getrennte Signaturen verwendet hatten, nämlich je eine für C, eine für D und eine für die E-Variante... Die sie 48 Stunden später dann zu einer Signatur CDE zusammengefasst haben.

Clamav z.B. hat da bisher kein 7 Signatur-Updates für gebraucht, da deckt bereits schon die C-Variante die Varianten ab, die Apple offenbar erst mit D und E erfassen konnte. Sprich: der Signatur-Schreiber, der diese Signaturen bei Clamav geschrieben und hochgeladen hat, hat ziemlich gute Arbeit geleistet, wenn seie Signatur so vorausschauend geartet ist, dass selbst 2 nachfolgende Varianten bereits von der Signatur für die C-Variante abgedeckt wird, ohne dass ein Signatur-Update notwendig geworden ist (entsprechende Details und Diskussion darüber u.a. auch im Clamav- und im ClamXav-Forum). Apple brauchte dazu 3 oder 4 Anläufe und Signatur-Updates, um zum gleichen Ergebnis zu kommen. Es fragt sich also, wer da von beiden Parteien effektiver, geübter und kraft Erfahrung etwas vorausschauender ist im Umgang mit dem Ganzen -- Apple oder die diesbzgl. etwas schon länger damit konfrontierten Signatur-Schreiber der AV-Software-Anbieter.

Dedizierte "straight hashes" pro Version ist die sicherere und genauere Vorgehensweise.

Wer neugierig ist, kann sich die bekannten Schädlinge nun per App anzeigen lassen: macmark.de/apps/wallsoftroy_de.php