>>160387Der MIME-Typ wird bereits vorher identifiziert via
file (also das Unix-Programm... welches einen wirklich blöden Namen hat, absolut ungooglebar. Benutzt übrigens selbst auch eine seccomp-Sandkiste, wie restriktiv die ist, weiß ich allerdings nicht) oder, für Archivformate, unser eigenes Werkzeug (in
src/archiveinfo), das auf libarchive aufbaut und ebenfalls seccomp verwendet, weil
file zum Dekomprimieren sonst externe Programme aufrufen müsste, was die seccomp-Sandbox ausschaltet (ich glaube, deshalb war das notwendig). [0] (Also
file könnte also beispielsweise zwar ein
tar erkennen, aber kein
tar.gz, ohne ein externes Programm aufzurufen.)
Der
magick identify-Befehl dient tatsächlich eigentlich nur dazu, die Dimensionen des Bildes auszulesen [1]. Wobei die gleiche Dietchan-Funktion die Informationen für alle Dateitypen parst, also auch z.B. die Länge bei Video- und Audiodateien; das Ausgabeformat der aufgerufenen Programme wird einfach entsprechend angepasst, sodass es immer gleich ist. Da
identify Bestandteil von ImageMagick ist, war es naheliegend, die dort vorhandene Funktionalität zu benutzen statt die Formate auch noch selbst zu parsen. Für das reine Parsen könnte man übrigens ggf. auch
wuffs nehmen [2], zumindest teilweise – es unterstützte zumindest anfangs einige Features nicht, wie z.B. progressive JPEGs, aber zumindest das wurde, glaube ich, mittlerweile nachgerüstet –, aber zum Daumennagelgenerieren braucht man ja noch weiteres: Resampler, Farbräume, Meta-Daten-Parser (Bildorientierung auslesen bei Fotos etc.) und natürlich Code, um das Ergebnis zu schreiben, was
wuffs, soweit ich weiß, bisher gar nicht unterstützt, zumindest nicht für Bildformate (ich glaube, es kann JSON in CBOR umwandeln und sowas, aber keine Bildformate).
>Felix weiß auch nicht, aber Felixens Vorgehensweise wäre, möglichst einfache Testfälle (2x2 Bild mit Schwarz, Graustufen, 100% R/G/B-Farben, etc.) zu basteln, und zu schauen, ab wann die ersten Unterschiede auftauchen.
Ja könnte man, allerdings ist es für mich nicht wirklich so kritisch, dass ich den Aufwand investieren wollen würde, solange etwas vernünftiges herauskommt. Die Ergbenisse sind weder offensichtlich falsch noch allgemein schlechter oder besser. Manchmal sind unsere Dateien ein paar Bytes kleiner bei gleicher subjektiver Qualität, manchmal ein paar Bytes größer.
Es ist einfach nur seltsam, weil der Code ja entweder die Funktionen von ImageMagick verwendet oder Reimplementierungen davon, die im Grunde kopierpastetet wurden und nur geringfügig angepasst und vereinfacht (z.B. sind unsere Streams immer seekable... bei ImageMagick nicht, aber effektiv müssen sie sowieso für so ziemlich alles seekable sein, weshalb es im Originalkot drölftausend Stellen gibt, an denen geprüft wird, ob ein Stream (bzw. "Blob" im IM-Lingo) seekable ist und dann ggf. seekable gemacht wird durch Anlegen einer temporären Datei. Es würde mich nicht mal wundern, wenn daher der Unterschied kommt, weil der Originalcode einfach überall verstreut und dupliziert zig Sonderfälle hat.
Der ImageMagick-Kot ist allgemein die Hölle. Voll von Copy&Paste, so hat jedes CLI-Frontend wie
convert,
mogrify (was auch immer das heißen soll),
identify und die drölfzig anderen Varianten im wesentlichen den identischen, tausende Zeilen langen Kot, nur um die Kommandozeilenargumente zu parsen (bzw. zu Überspringen... selbst parsen kann es sie nicht, dafür ist wieder ein anderer Teil zu ständig). Sind dabei auch noch inkonsequent, weil anscheinend immer mal wieder irgendwer hier oder da einen Bug gefixt hat, aber vergessen hat, es bei den anderen Dateien nachzupflegen. Ich hab das direkt mal vereinfacht, indem ich alle Optionen in eine Tabelle [4] gepackt habe und jetzt nur noch
eine Funktion habe, die die Optionen parst. Der resultierende Kot ist kürzer als der Originalkot für auch nur
eines der Frontends. Zum Vergleich, so [5] sieht das im Original aus. Und für jeden einzelnen Befehl dupliziert. m(
Verwendet außerdem nichtssagende Beriffe wie
mogrify,
conjure etc., verwendet seine eigenen, komischen Begriffe
Blob statt etablierten Begriffen wie
Stream, hat seinen eigenen Boolean-Type, der ein Enum ist und der ganze Kot ist voll von
if (x != MagickFalse),
if (x == MagickTrue) etc.. Außerdem konnten sie sich nicht entscheiden, ob
MagickTrue Erfolg signalisiert oder einen Fehler. Es ist bei jeder Funktion anders und es ist nicht dokumentiert. Die Kommentare lügen außerdem häufig, sind an den falschen Stellen platziert, weil zwischenzeitlich neue Funktionen eingefügt wurden...
Der ImageMagick-Kot gehört so mit zu dem schlimmsten, den ich je gesehen habe. Was den Code für das Parsen von Optionen angeht, der sieht in etwa aus wie Bild relatiert, und wie gesagt, in mehreren Dateien dupliziert (bis auf minimale, wahrscheinlich unabsichtliche Unterschiede). Man will sich die Augen ausstechen. Man erkennt auch sofort, in welcher Ära der Kot ursprünglich geschrieben wurde, aber das ist keine Entschuldigung. Wenn man den Kot gesehen hat, wundert man sich nicht mehr darüber, dass das Ding ständig neue Sicherheitslücken hat.
>TGA hat statt einem magischen Header einen magischen Footer, der allerdings optional ist:
>https://en.wikipedia.org/wiki/Truevision_TGA#File_footer_(optional)
Spaßfakt: TGA brauchen wir eigentlich nur, weil unsere Captcha-Implementierung TGA ausgibt. Genau deshalb, weil TGA so schön minimalistisch war. Aber ausliefern will man das dem Klient natürlich nicht, also wird es vorher von ImageMagick in PNG umgewandelt.
>Auch: Diätkanal in Fil-C wann? Schließlich lüftet djb bereits Fil-C.
Wenn du das kompiliert bekommst... kannst es ja mal probieren. Bezweifel aber, dass es funktioniert. Mit dietlibc auf jeden Fall nicht, denn dietlibc unterstützt noch nicht einmal Clang. Habe mich damit ehrlich gesagt bisher mit Fil-C noch nicht beschäftigt. Bin aber auch nicht sicher, ob das funktionieren würde, so wie unsere Datenbank funktioniert, die ja im Grunde eigentlich nur ein gemapptes Speicherabbild mit zusätzlichen Journal ist. Fil-C hat doch irgendwelche Garbage Collection oder so? Ist mir nicht klar, wie das funktionieren würde.
>Man kann auf Gentoo auch (die meisten Pakete) statisch linken, da wäre dann eine Grenze erreicht. :)
Ja gut, das ginge dann definitiv nicht. Wobei in diesem speziellen Fall der von Verfechtern des dynamischen Linkens angeführte Vorteil, nämlich dass man automatisch Sicherheitsupdates bekommt, ohne seinen eigenen Kot rekompilieren bzw. neu linken zu müssen, vielleicht sogar nicht ganz unberechtigt ist. Also ich installiere gefühlt jede Woche eine neue ImageMagick-Version mit Bugfixes. Ich kompiliere mein Dietchan aber nicht so oft. Und ich finde es ganz praktisch, dass ich automatisch die Updates bekomme (da die ganze Verarbeitung ja als neuer Hintergrundprozess gespawnt wird).
Durch den Sandkasten sollten die Bugs zwar jetzt eigentlich keinen Schaden mehr anrichten können, selbst wenn sie vorhanden sind, aber man nimmt die Fixes ja trotzdem gerne mit.
[0] https://gitgud.io/zuse/dietchan/-/blob/7e38a3ef6a740d21e3ba4689ae01c7689d87c934/src/dietchan/upload_job.c#L180
[1] https://gitgud.io/zuse/dietchan/-/blob/7e38a3ef6a740d21e3ba4689ae01c7689d87c934/src/dietchan/upload_job.c#L455
[2] https://blog.fefe.de/?q=wuffs
[3] https://gitgud.io/zuse/secmagick/-/blob/master/common/options.c?ref_type=heads#L49
[5] https://github.com/ImageMagick/ImageMagick/blob/9c0546a6e2c3512ebfdcc94f6bedfd45977bc9b3/MagickWand/mogrify.c#L56