Fragen? Antworten! Siehe auch: Alternativlos
Was mich daran am meisten schockiert: das hat keiner gemerkt. Niemand. Avahi gibt es nen Jahr? Länger? Und niemand außer mir hat offenbar mal unabhängig mdns implementiert. Der Effekt ist, daß wenn man mit dem dietlibc Resolver nach einem von avahi beantworteten Host fragt, die Antwort gefressen wird. Ich habe mal einen Workaround in die dietlibc eingebaut, aber hey, ist das zum Kotzen oder was?
Update: Jemand hat dem avahi-Autor Bescheid gesagt, und der hat mich jetzt per Email angepinkelt. Die Situation stellt sich tatsächlich etwas differenzierter dar als bisher dargestellt. avahi implementiert die aktuelle Spec, ich eine ältere. Meine Schuld, hätte ich vor dem Meckern mal gucken können. In der aktuellen Spec steht, daß das RD Bit Null sein soll beim Senden, und daß man es beim Reinkommen ignorieren muss. Das stand früher nicht in der Spec, aber man muss die Wayback Machine bemühen, um auf frühere Versionen zugreifen zu können; offenbar sind den zeroconf-Leuten die früheren Versionen peinlich. Anyway, ich habe mir avahi bei der Gelegenheit noch mal kurz angesehen, und muss sagen, ist nicht so schlimm wie gnupg, aber leider auch nicht so richtig toll. Ich hab da jetzt keinen kompletten Audit gemacht, aber schon mal direkt nen (nicht exploitbaren) off-by-one buffer overflow gefunden, und eine Endlosschleife in der DNS Dekompression. Ich denke mal, für avahi wird es demnächst ein Update geben. Der CVS-Code bei der dietlibc akzeptiert jetzt konform zur aktuellen Spec auch mDNS-Pakete, die das Bit anders setzen als es bei ihnen ankam. Ich möchte an dieser Stelle übrigens die mDNS-Specschreiber aufrufen, diesen Blödsinn zu lassen, und die Regeln von DNS bezüglich dieser Bits weiter bestehen zu lassen — Eingabe == Ausgabe. Dann kann man mehr Code wieder verwenden und ihr ganzes Gefasel von wegen Code-Wiederverwerten und Protokoll-Beibehalten stimmt dann auch tatsächlich. Eines ihrer Argumente ist ja gerade, daß man die APIs beibehalten kann, und daraus folgt, daß res_query das Paket nicht selber baut, sondern res_mkquery tut das, und daher ist es auch nicht kosher, wenn res_query dann im Paket rumdoktorn soll, um das RD Bit zu löschen (immerhin sagt die mDNS-Spec dafür nur SHOULD, daher spare ich mir das). Leider sagt die aktuelle mDNS-Spec auch, daß bei rausgehenden Antworten das RD-Bit Null sein soll, und die DNS-Spec sagt, daß bei Antworten dieses Bit übernommen werden soll. Wenn die das Gefasel mit API-Beibehalten also ernst nehmen, dann sollte hier ganz klar Eingabe == Ausgabe gelten.