 Ich bin Rainer und ich arbeite jetzt seit einem halben Jahr bei Debian's Free Producible Builds Projekt mit. Das Projekt selbst gibt es schon etwas länger, seit 2013. Da gab es die ersten Ideen und Diskussionen auf der Debconf und dann im Jahr 2014 wurde das Ganze noch stark erweitert. Da kam dann irgendwann ein Continuous Integration Server dazu, der regelmäßig eben Pakete neu baut und die Ergebnisse vergleicht. Und dieses Jahr, im Januar, da war die FOSDEM, da haben Luna und Holger schon mal einen ähnlichen Vortrag gehalten und auf dem Vortrag basieren auch meine Slides, haben allerdings auch noch ein paar Updates. Was sind überhaupt Free Producible Builds? Darunter versteht man, dass, wenn man ein Paket baut oder eine Software baut, dass man zu einem beliebigen späteren Zeitpunkt wieder genau dasselbe Ergebnis bekommt. Also egal, wann man den Bildvorgang wiederholt, dann muss die gleiche Binary rauskommen. Und gleich heißt, dass die wirklich identisch ist, also dass die Checksum übereinstimmen. Bei freier Software haben wir eben auf der einen Seite den Quellcode und aus diesem Quellcode bauen wir die Binary. Die Binary ist eben das Produkt, mit dem die Benutzer eigentlich immer in Kontakt kommen. Also die laden irgendwie eine Binary runter mit einem Parketmanager oder so und führen die dann aus. Während mit dem Quellcode kommen eher selten die Benutzer in Kontakt. Aber der Quellcode ist halt eigentlich so das einzige, dass man wirklich untersuchen kann und gucken kann, ob da jetzt irgendwie, ob da jetzt Schadcoach drin ist oder so. Das ist halt mit einer Binary viel schwieriger. Und bei Free Producible Builds geht es eben darum, diesen mittleren Pfeil zu beweisen. Also dass die Binary wirklich aus dem Quellcode gebaut wurde, von dem es behauptet wird und dass da keine zusätzlichen Motivifikationen oder Hintertüren oder so drin sind. Darum geht es. Und warum ist es wichtig? Reproduzierbare Builds erlauben es eben, dass jeder unabhängig verifizieren kann, wie ich schon gesagt habe, dass eben die Binary zu dem Quellcode passt. Ja, jetzt gibt es vielleicht manche, die behaupten, ja, ich weiß ja, was in der Binary drin ist, weil ich es selbst kompiliert habe oder ich bin sehr verantwortungsvoll und so weiter. Und es sind alles hypothetische Risiken und da kann ja eigentlich nichts schiefgehen. Aber kann man sich da wirklich so sicher sein? Es gab halt in der Vergangenheit schon erfolgreicher Angriffe auf Infrastruktur von Linux oder FreeBSD zum Beispiel. Und wenn eben solche Infrastruktur angegriffen wird, dann sind eben auch alle Nutzer von dieser Software bedroht. Genau. Vor Kurzem war auch auf High City News das Putty dieser SSH-Cline, dass da auch wir so im Umlauf sind, die irgendwie eine Hintertür drin haben. Und als Benutzer, wenn man einfach nur die Binary hat, dann ist es schwer zu überprüfen, ob jetzt die Binary wirklich das macht, was es soll. Ja. Und es gibt halt vielleicht immer starke Motivation, irgendeinen Computer zu kompromittieren, wenn man eben Zugriff auf so ein Bildsurfer hat oder auf so einen Rechner von einem Entwickler oder Maintainer dann. Und das ist eben der Entwickler oder Maintainer von einer sehr wichtigen Software, ob SSL oder Apache oder so irgendwas, dann hat man sofort eine Hintertür in Millionen von Computern oder so. Hier noch ein kleines Beispiel, warum es wirklich wichtig ist, dass jedes Bit gleich ist, gleich sein muss. 2002 gab es eine Lücke in OpenSSH, eine Privileged Escalation Lücke, das heißt ein User mit eingeschränkten Rechten, der konnte die Rechte erweitern, um Route Rechte zu bekommen. Und unten ist eben der Diff, der Patch, der diese Lücke gefixt hat. Aus dieser Überprüfung ID Größer Channels Alloc wurde ID Größer Gleichchannels Alloc. Und wie sieht das Ganze dann in Asample aus? Ist wahrscheinlich schwer, da jetzt ein Unterschied zu sehen. Aus dem Jump if Less than equal wurde einfach ein Jump if Less. Und wie näher sieht das Ganze so aus? Der Obcode von JLE ist eben 0x7e und der Obcode von JLE ist 0x7c und wie näher unterscheiden die sich in genau einem Bit. Also genau dieses eine Bit hat den Unterschied ausgemacht zwischen eben dieser Sicherheitslücke und keiner Sicherheitslücke. So sieht das Ganze in Hex aus, links die verwundbare und rechts die gefickste Version. Diese 7e wurde eben zum 7c, was wirklich schwer zu sehen ist, wenn man versucht es manuell zu untersuchen. Dann reproduzierbare Bild sind keine so neue Idee. Das gab es vorher auch schon im Torprojekt und zwar für den Tor-Brauser. Und da ist es eben auch sehr wichtig, dass man da die Sicherheit hat, dass da nichts an der Binary modifiziert wurde, weil die Software wird halt von Leuten eingesetzt, die wirklich anonym sein wollen und wo vielleicht das Leben auf dem Spiel steht, wenn die anonymisiert werden oder so. Und die müssen eben auch sicher sein können, dass die keine modifizierte Binary oder so haben. Dann gab es es auch schon von Bitcoin. Angenommen, es gab englische bösartigen Modifikationen in den Bitcoin Binarys. Dann kann es natürlich zur Folge haben, dass englische Bitcoins, also Geld auf andere Konten transferiert wird oder so. Und die Benutzer, die würden natürlich niemanden glauben, dass da irgendwie der Computer vom Entwickler gehackt wurde oder so, sondern die gehen davon aus, dass der Entwickler, die hinter der Tür mit Absicht eingebaut hat oder so. Und um das zu widerlegen, will Bitcoin eben oder hat Bitcoin eben auch reproduzierebare Bills eingeführt, um eben einfach die Entwickler zu schützen. Weil die dann sagen können, okay, baut doch einfach die Binary nach und dann seht ihr schon, dass die Binary wirklich zu dem Source passt. Und die Geschichte reicht noch weiter zurück. Also es gab schon 2007 auf der Debian Devil Mailing Liste ein Vorschlag oder die Idee, dass das ganz cool wäre, wenn man Bit-identische Bills hätte. Aber das wurde zu dem Zeitpunkt noch weiter verfolgt. Und jetzt erst in jüngerer Zeit nach den Snowden-Veröffentlichungen nimmt es alles mehr Fahrt auf. Und Debian ist die größte Sammlung an freier Software überhaupt mit mehr als 21.000 Source-Paketen zurzeit. Und da wäre es schon ziemlich cool, wenn man net wie bei Tor oder Bitcoin nur einzelne Software reproduzierebar macht, sondern wenn man durch ein bisschen Arbeit das ganze Debian-Archiv auf einmal reproduzierebar bekommt. So, und wie stellen wir das an? Zum einen brauchen wir eine Möglichkeit, um die Bildumgebung aufzuzeichnen. Dann brauchen wir eine Möglichkeit, die aufgezeichnete Bildumgebung später zum späteren Zeitpunkt wieder zu reproduzieren. Also unter dem Aufzeichnen, da wollen wir eben alle Bildabhängigkeiten und die genauen Versionen, die am Bildprozess beteiligt waren, uns irgendwie merken, damit wir die später wiederbekommen und mit genau dasselben Versionen wieder nachbauen können. Und wir wollen unnötige Variation eliminieren. Also wenn in der Toolchain irgendwelche, wenn es da irgendwelche Variation, wenn der Variation die Ausgabe kommt, dann wollen wir das auch eliminieren. Wie zeichnen wir die Bildumgebung auf? Beim Bildprozess von Debian fallen außer den Debian-Paketen auch immer noch so Kontrolldateien an und wir haben jetzt eben eine neue Kontrolldatei Bildinfo eingeführt, die eben alle Bildabhängigkeiten und die Abhängigkeiten dieser Bildabhängigkeiten aufzeichnet. Und dazu kommen auch noch die Checksum von Surson-Beinari-Paketen. Alles was am Bildprozess beteiligt war, also wenn man jetzt im sauberen Change Route ein Paket bauen will, dann zeichnet der alle Bildabhängigkeiten auf, die benötigt sind, um diese Paket zu bauen und natürlich auch die Abhängigkeiten von diesen Bildabhängigkeiten in der genauen Version, weil man das später irgendwann reproduzieren muss. Nee, so viele, ich weiß nicht, nee. Ja, nee, das geht. Nee, es geht da nicht, es geht da nicht um die Bildabhängigkeiten, sondern so ein Surs-Paket kann ihr mehrere Beinari-Pakete erstellen und dann wird eben von denen die Checksum gelistet, weil von den Bildabhängigkeiten, da kennen wir ja die Checksums, die sind jetzt in die irgendwo im Debian-Archiv drin und die kann man dann über einen anderen Weg verifizieren. Aber da musst du kaum was zu sehen haben. Es würde vielleicht Sinn machen. Ja, ja, würde vielleicht Sinn machen. Aber hier ist auf jeden Fall mal so ein Beispiel von der Bild-Info-Datei und wie man hier sieht, sind wirklich nur die Checksums von dem Surs-Paket und von dem Beinari-Paket drin und dann eben unten aufgelistet alle Pakete, die beteiligt waren am Bildprozess in der genauen Versionsnummer. Was wir auch drin haben, ist der Bildpfad, weil wir haben irgendwann festgestellt, dass wenn der Bildpfad variiert wird, dann taucht er einfach an so vielen Stellen auf und es ist einfach ein fast urlösbares Problem, den zu eliminieren nachträglich und deshalb wird er mit aufgezeichnet und wir sagen, dass wenn eine Beinari reproduziert werden soll, dann muss eben auch dieser Bildpfad verwendet werden. Das ist so eine Anforderung, die wir stellen. Dann, wie reproduzieren wir die Bildumgebung? Da gibt es nämlich einmal dieses Snapshot Debian Org-Archiv, dass wirklich alle Pakete ab einem bestimmten Zeitpunkt archiviert, archiviert hat, das sind mittlerweile 29 Terabyte und alle Pakete, die irgendwann im Debian Archiv landen, die landen eben auch auf diesem Snapshot Archiv und wir können uns dann eben von dort die benötigten Abhängigkeiten später wieder runterholen, wenn wir die eben brauchen. Dann haben wir so ein experimentelles Tool, S3-Bild, es ist so ein Rapper um S-Bild. S-Bild ist ein Tool, das läuft auf den Debian-Bildsurfern und baut eben die Pakete in so einem sauberen Change Route und S3-Bild ist eben ein Rapper, der im Snapshot Archiv eben nach dem richtigen Datum guckt und dann die entsprechenden Pakete in der entsprechenden Version aus der Bildinfo-Datei installiert und dann den Bild startet. Es ist im Moment eher so ein Proof-of-Concept-Status und noch nicht so ganz fertig, aber es funktioniert schon mal. Und wie eliminieren wir ungewünschte Variationen? Bitcoin und der Tor-Brauser, die haben einen anderen Ansatz als Debian, die verwenden eine VM und in der VM können sie dann halt sicherstellen, dass wirklich immer der gleiche Kernel verwendet wird, gleicher Benutzer, gleicher Bildfahrt und so weiter. Und für Zeitstempel, damit da immer die, damit man da immer die gleichen hat, verwenden sie Leapfake-Time. Das ist so eine Bibliothek, die über LDE preload eben die Funktionsaufrufe für, für den, für die Zeitabfrage ändert und dann eben irgendeine fixe Zeit zurückliefert und dadurch haben die eben immer die gleiche Zeit bei wiederholten Bilds. Debian geht eher den Ansatz, wir wollen die Tools und die, die Tool Chain und die Bildsysteme fixen und immer, wenn, wenn wir sehen, dass da ein Tool irgendwelche Zufälle oder nicht Determinismen irgendwie einbaut, dann wollen wir das fixen und entfernen und Work Arounds akzeptieren wir nur wirklich, wenn es keine andere Lösung gibt. Einer dieser Work Arounds ist ein Tool, das wir entwickelt haben, Strip Non Determinism. Dieses Tool kann verschiedene Datei-Formate passen und normalisieren. Also es gibt verschiedene Archiv-Formate oder Dokumentationsformate, G-SIP und so weiter, die eben auch Zeitstempel drin haben und wenn die noch nicht auf einem anderen Weg eliminiert wurden, dann kann Strip Non Determinism eben diese Zeitstempel entweder entgegenz entfernen oder durch Deterministische Zeitstempel ersetzen. Also bei Debian gibt es ja immer dieses Change-Lock, dass immer, also jedes Debian-Paket, jede neue Debian-Version von dem Debian-Paket braucht eben so einen neuen Eintrag im Change-Lock und dieses Change-Lock hat eben auch so ein Zeitstempel und dieser Zeitstempel ändert sich ja nicht zwischen den Bilds und deshalb können wir den als Deterministischen Zeitstempel verwenden. Genau und für dieses Strip Non Determinism Tool gibt es auch so eine Debian-Helber-Version DH an der Score Strip Non Determinism, das in unserer Toolchain auch verwendet wird, um eben während der Bildprozess dann noch nicht Determinismen zu entfernen. Es ist in Pearl geschrieben, so wie auch die Package minus Das heißt Pearl ist etwas, das immer schon installiert ist, wenn Pakete gebaut werden. Also es ist kein riesiger Overhead, der dadurch eingeführt wird. Genau. Dann weiteres Tool von uns ist Debian-Div. Das hilft uns bei der Analyse von Paketen und Paketunterschieden. Es übernimmt zwei Dateien und gibt dann eben als HTML oder Plaintext die Unterschiede aus. Zwischen beiden Dateien und die Dateien, die können auch Debian-Pakete sein oder mittlerweile unterstützen wir auch RPMs, ISO Images, SquashFest Images und so weiter. Und es ist wirklich einfach, da Support für neue Dateithypen hinzuzufügen, um die irgendwie lesbarer zu machen. Also das Ziel von dem Tool ist es vor allem, die Unterschiede lesbar zu machen, damit man die möglichst einfach auch verstehen kann und analysieren kann, wo die Unterschiede herkommen. Es kann zum Beispiel PDF-Dateien entpacken. Also die PDF-Dateien sind ja meistens die Text-Streams, sind ja auch irgendwie gepackt und die kann man schlecht diffen. Und mit so einem Tool PDF-TK kann man die eben wieder entpacken und dann ist es eben Plaintext und es ist sehr einfach zu diffen. Und man sieht dann, dass sich zum Beispiel ein Datum unterscheidet oder so. Es kann auch Beiner-Restis assamplieren, was auch hilfreich ist und so weiter. Unterstützt viele andere Formate und nur, wenn es eben kein Format versteht, dann gibt es ein Fallback auf ein Binärer-Vergleich, da wird dann einfach ein Hex-Dump gemacht von der Datei und der wird verglichen. Und dann wird eben getestet und wieder getestet. Und zwar bauen wir das Paket auf reproducible.debian.net und bauen es dann ein zweites Mal und vergleichen dann die Ergebnisse. Ursprünglich war das ein kleines Shellscript von zehn Zeilen, aber das hat sich mittlerweile vergrößert. Mittlerweile sind das 28 Jobs, die auf diesem Jenkins-Server laufen. Davon sind acht dafür, da einfach nur um Pakete zu bauen und die werden alle zwei Minuten neu gescheduled, also die bekommen in die Warteschlange neue Pakete rein. Dann haben wir Jobs, die eben dieses Scheduling übernehmen. Wir haben eine SQL-Light-Datenbank, wo alle Pakete drin sind und Metadaten, wie wann die zuletzt auf Jenkins gebaut wurden und so weiter. Dann gibt es weitere Jobs, die eben diese P-Bilder-Change-Routes aktualisieren, dann haben wir Jobs, die ... Wir haben ein Git-Repository, in dem wir Notizen drin haben. Also wir gucken uns auch die Unterschiede an und machen Notizen dazu. Die kommt dann in so ein Git-Repository und da gibt es eben auch ein Job, der diese Notizen nimmt und HTML-Dateien generiert und das schön im Web veröffentlicht. Dann alle Ergebnisse landen auch in so einer großen Chasen-Datei. Dafür gibt es auch ein Job und verschiedene andere Maintenance-Shops und so weiter. Das sind also mittlerweile zwölf Shell-Scripts und zwölf Python-Scripts. Am Anfang waren das zum Großteil Shell-Scripts, aber mittlerweile sind auch mehr Python-Scripts dazugekommen aus Performance-Gründen und weil die einfach wartbarer sind. Also Jenkins.debian.net, das gab es schon lange vorher. Aber im September 2014 wurde auf Jenkins.debian.net eben auch, wurde um eben reprotisibel BILDS erweitert, damit wir auch Pakete bauen und vergleichen können. Das läuft auf VMs zurzeit von Profitbricks und zurzeit läuft eben auch, wird das Ganze auch erweitert. Wir wollen einen zweiten BILD-Host, weil zurzeit ist eben alles wirklich auf einem Host, es wird ein Paket gebaut, wieder gebaut und dann verglichen. Aber wir bekommen einfach mehr Variationen rein, wenn wir den zweiten BILD auf einem zweiten BILD-Host vornehmen, weil wir dann auch die Systemzeit ändern können, um ein Jahr um mehrere Monate verstellen und so weiter, was wir auf der 1VM nicht tun wollen. Und wir wollen auch in Zukunft das Ganze auf Jenkins.debian.org migrieren, also dass es dann irgendwann auf richtiger, offizieller Debian-Hatware läuft. Testen tun wir im Moment nur Pakete in Main auf am D64, aber in den drei zweiten Experimental Unstable and Testing. Der Scheduler ist so eingestellt, das hat zurzeit Unstable Pakete doppelt so oft scheduled, weil das einfach interessanter ist. Ja, wir haben auch IAC Benachrichtigungen, wo wir dann sehen, wenn jetzt ein BILD, das vorher reproduzierbar war, auf einmal nicht mehr reproduzierbar ist, dann sehen wir das zum Beispiel, was ganz cool ist. Ja, dem ganzen Code gibt es auch in so einem Git Repository, falls jemand Interesse hat. Und so sieht der Graf seit 1. Oktober 2014 aus. Grün sind die Reproduzierbahnpakete und auch die Unreproduzierbahn. Und ganz oben ist noch ein schmaler Streifen rot. Das sind die, die zurzeit nicht gebaut werden können aus englischen anderen Gründen. Ja, und das sind im Moment 81,7 Prozent, die wir mit unserer Toolchain reproduzierbar bauen können. Das sind mehr als 17.900 Zürspakete. Und das ist schon mal ganz beeindruckend, finde ich. Dann zu den Variationen. Der zweite BILD hat einiges an Variationen zum ersten BILD und zwar offensichtlich die Zeit, weil er einfach zeitlich nach dem ersten BILD ausgeführt wird. Aber wir setzen auch eine andere Zeitzone für die BILDs. Der erste BILD wird in GMT plus 12 ausgeführt und der andere BILD in GMT minus 14. Dadurch haben wir auch eine Differenz von Größe einem Tag, was auch ganz cool ist, weil dann Programme oder englische Tools, die lokale Zeit verwenden, für die ist es dann im Prinzip ein ganzer Tag Unterschied, obwohl die Differenzen der Zeit, wann die BILDs ausgeführt werden, wirklich nur ein paar Minuten ist. Aber wir sehen dann so auch, wenn sich was im Datum ändert, was ganz cool ist. File Ordering unterscheidet sich CPU Ordering, einfach dadurch, weil es eben parallel ausgeführt wird. Wir ändern Hostname, Domainname, wir ändern auch den Username, Groupname, UID, GID, wir ändern die UMask, wir ändern die Spracheinstellung, also der erste BILD wird dann mit englischer Spracheinstellung ausgeführt und der zweite BILD mit französischer Spracheinstellung. Wir fägen die Kernel-Version auf dem zweiten BILD mit Linux 64, was dann eben auch eine andere Kernel-Version zurückliefert. Seit kurzem ändern wir auch die Depth-Build-Options. Das ist da beim zweiten BILD einfach ein Core, der weniger verwendet wird. Aber wir haben auch schon Unterschiede gesehen. Also Pakete, die wirklich die Depth-Build-Options in irgendeinem Datei einbetten und mit ausliefern. Das war ganz interessant. Und seit dieser Woche variieren wir auch noch den Pfad. Da gibt es auch Pakete, die die Pfadvariable irgendwo einbetten, was auch nicht wirklich Sinn macht. Was noch nicht variiert wird, das sind Tag, Monat und Jahr. Das soll dann auch demnächst kommen, wenn wir eben einen zweiten BILD-Host haben. Und dadurch wird sich dann auch Proc-CPU-Info unterscheiden, weil das eben auch eine andere CPU sein wird, die da drin ist. Und was wir zurzeit auch noch entmachen, sind Rebuilds auf unterschiedlichen Dateisystemen, weil wir einfach zurzeit alles auf TempFS bauen wollen, weil das einfach am schnellsten ist. Und so sieht die Ergebnisseite auf Jenkins.debian.net aus. Hier ein Beispiel für Unstable. Man sieht dann eben links oben verschiedene Buttons für die einzelnen Bildstatus. Die Sonne bedeutet, da kriegt man dann alle Pakete angezeigt, die reproduzierbar gebaut werden können. Die Regenwolke bedeutet die unreproduzierbaren Pakete. Und die Gewitterwolke heißt, dass er alle Pakete anzeigt, die zurzeit gar nicht gebaut werden können. Und dann gibt es noch so ein paar andere Buttons, die weniger interessant sind zum Beispiel Gepläckliste, Pakete und so weiter. Man kann sich auch anzeigen lassen, irgendwelche Pakete, die Notizen schon von uns haben. Wenn man ein Paket fixen will, kann man sich angucken, was sind genau die Notizen, was ist da das Problem. Vielleicht hat man eine Idee, wie man das beheben kann. Oder man kann sich Pakete noch ohne Notizen anzeigen lassen. Wenn man daran interessiert, es einfach nur mal zu gucken, warum sich jetzt so ein Bild unterscheidet, dann guckt man sich am besten die Pakete ohne Notizen an und uns schicken oder kommenten in das Repository. So sehen die Seiten aus für einzelne Pakete. Also wirklich jedes Paket, das wir untersucht haben, bekommt eine eigene Seite. Wenn es einen Notiz dazu gibt, dann taucht die immer an erster Stelle auf. Hier zum Beispiel haben wir herausgefunden, dass sich im Paket App Armor, das erzeugt während dem Bild auch PDF-Dateien und da gibt es Zeitstempel drin, die sich eben unterscheiden. Und es gibt auch ein Kommentar, das sich der ID-Value unterscheidet. Und zu sehr vielen Issus haben wir eben auch in unserem Wiki eigene Unterseiten. Und auf den Unterseiten haben wir auch dokumentiert, wie man das Problem lösen kann oder ob es English Worker Runs dafür gibt. Genau. Dann auf der gleichen Seite gibt es dann oben im Menü, kann man sich den Depth-Diff anzeigen lassen. Und so sieht er dann zum Beispiel aus. Also Depth-Diff, das geht halt recursiv in eine Archive rein. Hier hat es zum Beispiel unpacked as data.taz, dann unpacked as data.taz. In data.taz sind zum Beispiel die Datei tag.tag.pdf.gz. Die muss eben auch wieder entpackt werden. Und die tag.tag.pdf, die kann dann eben lesbar gemacht werden, verglichen werden und der Diff wird dann eben angezeigt. Das komplette Bildlock kann man sich auch anzeigen lassen. Und dann gibt es oben auch noch andere Links, zum Paketräger, zum Backträger, zum Quellcode und so weiter. Auch zur Bildinfo-Datei, wenn man daran interessiert ist. Und wenn wir das Paket auch in anderen Zweigen, also zum Beispiel Testing oder Experimental gebaut haben, dann wird er auch einen Link angezeigt, wo man sich dann angucken kann, was sich da in den anderen Versionen unterscheidet. Und diese rote Flagge bedeutet, dass der Maintainer von dem Paket alarmiert werden will, wenn es eine Statusänderung gibt. Also das ist auch ganz interessant, wenn ein Paket reproduzierbar war und der Maintainer will wissen, ob der Paket reproduzierbar wird durch ein Update oder so, dann kann er sich darüber informieren lassen. Unsere Experimental-Toolchain, die besteht zurzeit aus acht Paketen, die gegenüber Experimental modifiziert wurden. Die wichtigsten Pakete dabei sind Deep Package Step Helper und CDBS, weil ohne unsere Patches für diese Pakete kann man zurzeit kein Paket reproduzierbar bauen. Weil die Package eben auch noch Zeitstempel da drin hat und ich glaube, die Dateilisten und so waren vor Kurzem auch noch unsortiert und so weiter. Ach genau, und wir haben auch noch eine Modifikation für die Package, das eben beim Bildprozess diese Bild-Info-Dateien erstellt. Ohne Bild-Info-Dateien ist auch kein Paket reproduzierbar. Und es ist auch noch nicht in Upstream Deep Package gelandet. Aber viele Patches, die wir stellen, sind schon submittet und werden auch von vielen Maintainern schon applied. Und wir haben eben auch für alle Pakete in unserer Toolchain so ein eigenes Git Repository. Hier ist ein Graf aller untersuchten Pakete. Also, der gibt an, ich habe ja erzählt, wir haben dieses Git Repository, wo unsere Notizen drin sind und der Graf gibt eben an, wie sich so die Anzahl der Notizen verhält, die steigt eben ständig weiter. Manchmal werden auch Notizen wieder entfernt, wenn ein Issue gefixt wird oder so, oder wenn irgendwas auf Pakete zutrifft. Das ist der Graf der identifizierten Issues, so ist auch ständig gestiegen und steigt weiter an. Wir finden da auch immer mehr Probleme. Auch ein cooles Feature, das wir haben auf Jenkins-Debian.net, sind Package Sets. Also Package Sets, das sind eben Untermengen von dem ganzen Debian-Archiv. Und zu diesen Untermengen können wir auch nochmal Statistiken generieren und Grafen generieren. Beispiele für diese Package Sets sind alle Essential-Pakete oder die häufigsten installierten Pakete oder für englische Desktop-Umgebung, die Pakete, die da dazugehören, wie für Knormk.de und so weiter. Oder wir haben Package Sets für ein paar Debian-Derivate, für Tails und Grimmel. Oder auch Paket-Sets für verschiedene Maintainer-Gruppen, wie die Pearl, Java und so weiter, verschiedene Maintainer-Gruppen, die bekommen dann auch ihre eigenen Sets. Die bekommen dann auch ihren eigenen Graf und Statistiken dazu. Es gibt noch mehr Goodies. Und zwar, man kann sich diese Seite anzeigen lassen, die man einfach auf reproducible.debian.net slash Paketname geht. Und was wir auch haben, sind Listen von unrepräsensierbaren Paketen pro Maintainer. Also man kann da einfach die Liste öffnen und die Namen suchen, wenn man Maintainer ist und dann zieht dann alle Pakete von sich, die zurzeit unreproduzierbar sind. Wir haben Listen ohne identifizierten Issue. Das ist ganz interessant, da halt mal reinzuschauen, wo die Probleme dann sind und das genauer zu untersuchen. Dann, seit einiger Zeit, wird der Reproduzierbarkeitsstatus auch auf dem neuen Paket-Drecker angezeigt. Also, wenn das Paket unreproduzierbar ist, dann wird es ganz oben da angezeigt. Dann gibt es für Maintainer auch noch ein Dashboard und diesen Package Overview. Da gibt es eine eigene Spalte, wo angezeigt wird, ob es reproduzierbar ist oder nicht. Was auch ziemlich cool ist. Okay, dann kommen wir mal zu den Ergebnissen, was wir so gefunden haben. Eines der häufigsten Probleme sind eben Zeitstempel, die eigentlich überall drin landen. Aber wir haben auch gefunden, dass File Order ein Problem ist. Also, manche Prozesse sortieren einfach nicht die Dateilisten oder so und dann hat man in englischen Archiven unsortierte Listen und dadurch unterscheiden die sich natürlich. Wir haben Pseudo-Randomness in temporärer Dateipfaden, die irgendwie eingebettet werden. Wir haben CPU und Memory-related Probleme. Also, wenn da irgendwie während des Bildvorgangs eine Code-Optimierung vorgenommen werden, dann ist es schwer zu reproduzieren vielleicht und auch so Probleme wie Local Settings. Ja, haben wir schon festgestellt. Jetzt kommen ein paar Beispiele für Zeitstempel, die für eine Bildvorgang hinzugefügt werden. Sehr oft gibt es eben Zeitstempel in G7-Dateien. Wenn irgendwelche Helfer-Tools verwendet werden, dann werden die Dateien meistens gepackt und so, dass der Zeitstempel eben unterdrückt wird, sodass gar keine erst eingebettet wird. Aber es gibt eben sehr viele Pakete, die den Zeitstempel noch einbetten, weil sie das Ganze eben manuell machen, die diese Helfer-Tools nicht verwenden. Und wir haben ein Zeitstempel gefunden, die von Maven in englischen Properties-Files erstellt werden. Qmake-Betted-Zeitstempel in generierte Make-Files ein. Weiteres QT-Tool-Betted-Zeitstempel auch in Header-Dateien ein. Pi-QT hat auch mal in so autogenerierten Resource-Code Zeitstempel eingebett, das ist mittlerweile gefixt. Aber als Beispiel ist es ja trotzdem noch. Der Elon-Compiler bettet Zeitstempel ein. Es gibt Zeitstempel in PE-Bineries von Mono oder Ming-W. Wenn da auch irgendwas gebaut wird, dann sind eben auch Zeitstempel drin. Es gibt Zeitstempel in Ada-Library-Information-Files, Zeitstempel in Ruby Jam-Spec-Files, in PHP-Registry-Files, englische Python-Template-Engines, die betten auch Zeitstempel ein. Dann gibt es manche Python-Module, die das aktuelle Datum an die Version anhängen. Und dadurch haben wir eben auch in den Pfaden Unterschiede, wie man hier sieht. Dann gibt es Archive, die sich die eben Unterschiede, Zeitstempel, und so haben. Zum Beispiel static libraries, das sind auch im Prinzip nur Archive, die eben englische Object-Files zusammenfassen. Das ist mittlerweile auch so weit gefixt, vor Kurzem seit ein paar Wochen werden die Bin-Utils mit irgendeinem Fleck kompiliert, sodass die immer deterministische Archive erzeugen. Also das ist auch nicht wirklich mehr ein Problem. Ja, weitere Zeitstempel in static libraries, Zeitstempel in ZIP-Archiven, Zeitstempel in Java-Archiven, die eigentlich auch nur ZIP-Archive sind. Es gibt Zeitstempel in TAR-Balls, es gibt auch Benutzer und Gruppen in TAR-Balls. Es gibt zufällige Reihenfolgen in TAR-Balls. Und hier sehen wir auch die U-Mask-Variation. Also auf der linken Seite haben wir ganz oben in der ersten Zeile zum Beispiel eine Permission von 7.55 und auf der rechten Seite von 7.75. Also da ist noch dieses W-Fleck gesetzt. Es kommt eben durch diese U-Mask-Variation. Dann gibt es sehr viele Zeitstempel in Dokumentationen, die auch während dem Bildvorgang produziert werden. Doxy-Chen macht sowas. DocBook2Man, CrewVDoc, Epidoc, Sphinx, GhostScript, Lathash. Also wir sehen hier zum Beispiel das Modifikationsdatum und CreationDate, das eben eingebettet wird. Und was sich dadurch auch immer unterscheidet, ist die ID, die immer relativ weit am Ende steht. Die ist im Prinzip so ein Check-Sum oder so ein Hash über den Zeitstempel und über den Dateinamen. Und ich glaube, die Datei größe und die unterscheidet sich auch immer. Und dafür haben wir bisher auch noch keine wirkliche Lösung gefunden, außer Fake-Time, aber das ist in unseren Augen keine Lösung. Deshalb brauchen wir da noch irgendwie bessere Ideen, wie wir das rausbekommen. Es gibt Zeitstempel von Techi2HTML. Techi2HTML kann auch irgendwelche Einträge in HTML Dateien unterschiedlich sortieren. Dann hier ist ein Beispiel, wo wir eine Monatsvariation haben von Help2Man. Das ist ein Tool, das ruft den Hilfetext von einem Programm auf, in dem es einfach das Programm mit minus minus help aufruft und generiert dadurch automatisch eine Man-Page. Und das ist mal ein Tool, das net den genauen Tag einbettet oder eine Uhrzeit, sondern wirklich nur ein Monat und Jahr. Und wir haben das nur festgestellt, weil wir eben so ein Paket am Ende von einem Monat gebaut haben, dann ist eben durch die Timezone-Differenz der erste Bild noch im Mai und der zweite schon im Juni. Und so haben wir das dann eben auch festgestellt. Aber wenn wir mal einen zweiten Bild-Surfer haben, dann ist es auch viel einfacher festzustellen, wenn wir da das Jahr ändern können und so weiter. Dann Knugroff-Bettet-Zeitstempel ein, Java-Doc-Bettet-Zeitstempel ein. Wobei für Java-Doc ist das Problem auch schon zum Großteil gelöst. Da gibt es nämlich auch so ein Parameter minus no time stamp, mit dem man das unterdrücken kann. Und sehr viele Java-Pakete, die verwenden so einen Java-Helper oder so einen Maven-Helper. Und wenn die damit die Dokumentation generieren, dann wird Java-Doc schon automatisch mit no time stamp aufgerufen. Also ist dieses Problem für die meisten Pakete schon gefixt. Eben nur für die noch nicht, die das Java-Doc wirklich manuell aufrufen. Es gibt Zeitstempel in Mantu HTML. Es gibt in der Tesh-Ausgabe, in der Devoid-Dateien gibt es Zeitstempel. Dann eine andere größere Klasse an Zeitstempeln sind Binarys, die irgendwie das Bilddatum einbetten und dann irgendwie im Versions-Dring anzeigen. Zum Beispiel Version 1.0 Compiled at so und so. Das gibt es sehr oft. Und das wird oft über C-Preprozessor Makros gemacht. Also da gibt es diese Date und Time Makros. Die werden während dem Compilieren vom C-Preprozessor ersetzt, durch eben das entsprechende Datum und Zeit. Und dadurch unterscheidet sich natürlich auch die Binary dann am Ende. Hier ist nochmal ein weiteres Beispiel, was auch oft gemacht wird, ist die Bildzeit über ein Makefile aufzunehmen. Hier wird zum Beispiel in den Makefile ein Hater automatisch generiert und dieser Hater ruft eben Date auf. Und dieses Makefile ruft Date auf und bettet die Ausgabe in den Hater ein. Dann Configurescript machen das auch sehr oft. Hier wird zum Beispiel der Hostname und das Datum auch in so einen Version-Funktar Hater eingebettet, wodurch es natürlich auch Unterschiede wieder gibt. M4 Makros nimmt das Datum auf, aber auch den Username, den Hostname. Dann haben wir auch schon Pakete gesehen, die Kernel-Version mit aufzeichnen. Also auf der linken Seite sehen wir Linux 3.16 und auf der rechten Seite Linux 2.6. Das gibt es auch. Dann hatten wir vor kurzem einen sehr lustigen Fall. Es gibt so ein Spiel und das bettet eben auch den Zeitstempel ein. Und der Zweck davon ist, dass wenn man das Spiel innerhalb von einer Stunde nach dem Kompellieren startet, dann bekommt der Benutzer eine Million Bonuspunkte, weil das Spiel davon ausgeht, dass man ist wahrscheinlich dann ein Programmierer von dem Spiel und das ist ziemlich cool und dann bekommt er halt Bonuspunkte. Aber führt natürlich auch zu Unreproduzierbarkeit. Es ist zwar eine nette Idee, aber im Falle von D-Wern macht es eben wenig Sinn, weil die Zeitdifferenz zwischen Paketbau und bis das Paket wirklich beim Benutzer landet, ist eigentlich immer größer als eine Stunde und macht daher wenig Sinn. Da wäre es gut, wenn man das irgendwie rauspatschen könnte oder so. Dann, was wir auch schon hatten, sind File-Ordering-Probleme. Das sieht man hier jetzt vielleicht nicht so gut, aber da ist die Dateiliste unterschiedlich sortiert. Wir hatten verschiedene Randomness-Probleme. Das ist vor allem bei Pearl-Programm oder Pearl-Bibliotheken der Fall. Wenn die irgendeine Ausgabe erzeugen und irgendeinen Pearl-Hash, also so ein Dictionary ausgeben, dann wird es einfach so gedammt, ohne irgendwie die Kies zu sortieren. Dadurch hat man eben auch eine Zufälligreihenfolge da drin, und das sieht man dann auch öfters, wie hier in dem Beispiel. Dann der Warbis Ock-Encoder, der bettet in Oxtreams eben auch zufällige Seriennummern ein, was auch ganz interessant war. Dann ein weiteres Beispiel von Python-Qt-Code-Generator. Der hat eben generiert eben auch so UIs, so automatisch, und sortiert eben nicht die Imports, und dadurch sind die eben auch zufällig angeordnet. Dann gibt es auch englische Namespace-Dateien, die zufällig angeordnet sind. Wir haben zufällige Pfade in OCaml Libraries gefunden, also da unterscheidet sich das Ende von dem temporellen Pfad, und es gibt sogar noch mehr Zeitstempel. Das war auch ein ganz interessantes Beispiel. Und zwar haben wir auf der linken Seite eine Info-Page, die so von upstream mitgeliefert wurde. Die wurde mit MakeInfo Version 4.13 generiert, und das sieht man auch noch in ältere Versionsnummern, Version 1.2. Und auf der rechten Seite ist dann die selbe Info-Page, die aber während dem Bildprozess wirklich neu generiert wurde. Was man daran sieht, dass jetzt MakeInfo Version 5.2 verwendet wird, was eben in Debian enthalten ist. Und da wurde dann auch die Version gebammt auf 1.3. Das liegt auch an der Zeitzone-Differenz vor allem, weil er im ersten Bild dann net erkennt, dass der Zeitstempel irgendwie neuer ist oder so. Und er denkt, der Bildprozess denkt dann, er muss jetzt diese Info-Page neu generieren, die ist noch aktuell genug, und macht das eben net. Aber wenn jetzt ein Benutzer aus einer anderen Zeitzone der selbe Paket baut, dann denkt der Bildprozess, ja, da gab es eine Änderung oder so, weil der Zeitstempel irgendwie in der Zukunft liegt oder so, und wird dann eben neu gebaut. Also wir haben auch Zeitstempel abhängische Rebuilds, was auch nicht so toll ist. Dann haben wir auch Zeitstempel in ePub-Files, also eBooks, und weiter unten sehen wir, dass die Referenzen auf irgendwelche Images zufällig sortiert sind. Wir haben auch Zeitstempel in PNG-Dateien. Also da gibt es ein ganz cooles Tool, dass PNG-Dateien wirklich lesbar macht, in plaintext umwandelt, und das kann die auch wieder zurück umwandeln in PNG. Und ja, da sehen wir dann auch oft, dass irgendwelche Zeitstempel eingebettet werden. Wir haben auch Zeitstempel schon gefunden in TrueType-Fonds. Wenn die während dem Bildprozess von FontForge generiert werden, dann gibt es da auch Zeitstempel drin. Aber das war auch noch nicht alles. Wir haben in den letzten vier Monaten noch viel mehr Issus gefunden. Es sind heute bei 129. Aber viele sind uns auch nicht so interessant, weil die nur eine geringe Anzahl an Paketen irgendwie beeinflussen. Die müssen natürlich auch irgendwann gefixt werden. Aber ja, genau. Vor vier Monaten hatten wir auch eine Anzahl von 2.243 Notizen. Das ist auch mittlerweile stark gestiegen auf 3.400 Pakete mit Notizen. Also wir sind da stark aktiv am Analysieren von Paketen, warum die unreproduzierbar sind und wo die Probleme liegen. Genau. Hier ist ein Graf über die Anzahl Bugs, die so in der letzten Zeit gefeilt wurden. Steigt auch immer an. Aber es werden auch Patches von uns applied. Und dann geht der Graf auch wieder etwas zurück. Und genau. Ihr könnt uns dabei natürlich auch helfen. Und zwar wenn ihr Software entwickelt, indem ihr keine Zeit oder irgendwas anderes System abhängig ist, irgendwie einbettet. Oder es zumindest optional macht, sodass man es während des Bildprozesses abschalten kann. Und wenn ihr irgendwelche Ausgaben habt, das Hypefader, dass ihr irgendwas über Listen iteriert oder über Dictionaries iteriert, dann vorher die Keys sortieren, damit wirklich schnell reproduzierbare Ausgabe rauskommt. Und Merge unsere Patches, wenn wir welche schicken. Dann haben wir ein sehr umfangreiches Wiki. Auf wiki.debian.org slash reproducible builds. Wir haben da was zur History. Wir haben eine sehr große Seite, wie man Pakete reproduzierbar macht. Da haben wir eben, wie schon erwähnt, zu sehr vielen Issus, eigene Unterseiten, wo dann eben steht, was man da tun kann genau. Ja, und wir haben Links zu den Bug Reports, zum Continuous Integration Server, eine Beschreibung zu unserer Toolchain und so weiter. Und ihr könnt Debian helfen, indem ihr euch auch anguckt, Pakete anguckt, schaut, wo die Probleme liegen und das Ganze analysiert. Und dann eben auch dafür sorgt, dass die reproduzierbar gemacht werden können. Es gibt noch so ein paar Issus, die wir noch nicht so ganz verstehen, aber es gibt noch so ein paar Infotaineries. Da wissen wir noch nicht, ob es englische Seiteneffekte hat, wenn die Zeitstempel entfernt werden oder so. Da ist noch etwas Arbeit nötig. Und auch an der Debian-Infrastruktur sind noch Änderungen nötig. Also wir müssen irgendwann in der Zukunft auch die Build-Info-Dateien irgendwie abspeichern, damit andere Leute die Build-Info-Dateien selbst in Build reproduzieren können. Dazu muss aber auch unsere Deep Package Patch irgendwann auch noch in den Bug Tracker, der funktioniert zwar schon ganz gut, aber ich glaube, der Maintainer ist damit noch nicht so ganz einverstanden. Und ja, da gibt es noch etwas Diskussionsbedarf. Und was wir auch wollen, ist, dass Reproduzierbarkeit irgendwann auch in die Debian-Policy reinkommt. Wir brauchen ein neues Logo. Und was auch cool wäre, wären englische Tools, die den Reproduzierbarkeitsstatus von aktuell installierten Paketen anzeigen. Genau. Mittlerweile gibt es schon eine relativ große Liste an Contributors. Und es werden auch immer mehr, die da mal zum Beispiel ein ERC vorbeischauen und irgendwie helfen oder im Wiki neue Sachen dokumentieren oder Patches einschicken. Also das ist schon ziemlich cool. So, ihr könnt mit uns in Kontakt treten, entweder über die Wiki-Seiten oder über die Mailing-Listen. Wir haben auch einen ERC-Kanal, Debian Reproducible, eben auf TC. Diese Woche hatten wir ein erstes reguläres Team-Meeting und das wollen wir jetzt alle zwei Wochen so weiterführen. Und vielleicht habt ihr auch schon auf Pläne Debian.org unsere wöchentlichen Reports gesehen. Wir haben es jede Woche geschrieben von Luna. Bei anderen Distributionen gab es auch schon Ansätze oder Ideen. Aber so richtig fortgeschritten ist da bisher auch noch nichts. Aber ich weiß, dass Holger zum Beispiel in Kontakt ist mit englischen FreeBSD-Leuten. Und in Zukunft fallen wir auch, dass FreeBSD reproduzierbar gebaut werden kann. Diese Woche, ich glaube gestern oder vorgestern erst, hat Holger auch in Jenkins eingebaut, dass Coreboot gebaut wird. Also das ist dieses freie BIOS. Das wird jetzt eben auch gebaut und verglichen, wo die Unterschiede sind. Demnächst soll OpenWRT auch noch folgen. Und es wäre cool, wenn zum Beispiel Fedora, was auch eine sehr wichtige Distribution ist, den Ansatz auch irgendwann weiter verfolgt. Und wenn ihr daran Interesse habt, könnt ihr auch einfach mal mit uns in Kontakt reden. Wir helfen gerne weiter. Und wir hoffen, dass reproduzierbare Bills irgendwann die Norm werden. Wir hoffen, dass unsere Dokumentation hilfreich ist für andere. Und die Zukunft sieht hoffentlich so aus, dass wir bis zum nächsten Debian Release, wenn es in vermutlich 2 Jahren ist, schon mal bereit sind. Das heißt, unsere Toolchain-Änderungen gemirkt sind und wirklich dann verfügbar sind. Was wir auch irgendwann wollen, sind reproduzierbare Installationsmedien und Live-Images. Irgendwann dann auch reproduzierbare Cross-Plattform-Bills, also dass man auf einer anderen Architektur dann baut. Das wäre auch cool wäre, was jetzt nicht so viel mit Debian zu tun hat, aber das wären Binary Transparency-Logs. Also, dass man irgendwo aufzeichnet, welche Binarys im Umlauf sind. Also, dass man irgendwo die Checksums veröffentlicht und das Benutzer, die eine Binary irgendwo runtergeladen haben, die können da dann anfragen. Gab es diese Binary schon mal irgendwo auf der Welt? Hat die schon mal jemand gesehen? Das wäre sehr wahrscheinlich, dass da irgendwie eine Hintertür da so drin ist. Genau, das ist auch so eine Idee. Aber noch mal zur Erinnerung, das ist alles mehr so ein Research-Projekt zurzeit, weil eben noch unsere Toolchain-Änderungen noch nicht in Debian enthalten sind. Ist es nicht wirklich reproduzierbar, aber was uns diese Machbarkeitsstudie gezeigt hat, ist, dass es theoretisch möglich ist. Und dieses Jahr ist in Heidelberg im August die Debconf und wir hoffen da eben, dass wir da weitere Fortschritte machen und genau da noch mehr darüber diskutieren werden. Dann an dieser Stelle auch nochmal ein großes Danke, vor allem an Luna, Holger und Mathia, die da sehr viel Arbeit reinstecken in das Projekt und eine, die das eben so nicht möglich gewesen wäre. Und auch noch vielen Dank an alle anderen, die irgendwie mitgeholfen haben und beigetragen haben. Und dann wäre ich am Ende der Präsentation. Gibt es englische Fragen oder Kommentare dazu? Ja? Die erste Frage, diese ohne Frage, die du meintest, dass ich als Menkler subscribe, und wenn du die Frage, wie man das macht? Ja, und das ist was ganz Neues. Einfach mal im IAC vorbeischauen und sagen, dass du, oder dass seine Pakete auf diese Liste sollen und dann werden die auf diese Liste mit aufgenommen und dann klappt es. Ja? Ah, okay. Ja, die Frage war nach dieser roten Flagge, wie man die Situation bekommen soll, wenn sich der Status ändert, wie man diese Flagge bekommt, weil das noch schlecht dokumentiert ist. Das werden wir dann natürlich auch besser dokumentieren in Zukunft, aber zurzeit einfach im IAC nachfragen bzw. die Liste der Pakete nennen, die da auf die Liste soll. Ja? Funktionieren die? Ja, du hattest ganz am Ende die Sache mit den Transparenz-Logs. Ich habe in letzter Zeit ein bisschen Gedanken zugemacht, und im Prinzip hätte man das ja eigentlich schon, wenn man die Paket-Infos samt Hashes im Git repo eincheckt, weil Git im Prinzip eine verifizierbare History hat. Wie werden denn im Moment die Paket-Infos von Debian verwaltet? Also, diese Bildfälle, werden die in irgendeine Repositorie eingetscheckt, und mit was wird das verwaltet? Richtig verwaltet werden sie zurzeit noch nicht. Also, die fallen bei dem Bildvergang eben auch mit raus. Das ist auch auf unserem Chancenserver, die kann man darunter laden. Unser Ziel ist es natürlich, dass die irgendwann später auch mit dem Debian-Archiv mit landen auf den ganzen Mirrors und so weiter. Aber das ist zurzeit einfach noch ein der Fall. Die Metadaten von Debian-Paketen generell verwaltet. Es ist eine gute Frage, das weiß ich nicht so genau. Kann für dich was so sagen? Also, weil ich weiß, ist das in erster Linie eine Post-Crestartenbank in einem hoffentlich vernünftig schützten Server, der halt auch die Invariante enforced, dass es zu jedem Paket-Namen-Paket-Versionsnummer nur jemals, maximal einen Binary jemals gab. Also, ich kann kein weiteres Binary hochladen, mit einem Namen und einem Nummer. Die ganzen Hashes davon stehen auch in den Packages-Files, die auf den Mirrors publiziert werden, die können die z.B. speichern. Ich fände mal auch, dass SnapshotDebian.org da auch als historisches Archiv dienen kann. Aber so ein Git-Repo, alles drin ist, existiert noch nicht. Ich will jetzt gleich rüber zu den Lightning-Talks, aber vielleicht können wir uns nachher nochmal irgendwie kurz behalten. Ja. Ihr baut ja jetzt alles mit AMD 64, aber es werden ja auch viele plattformunabhängige Pakete auf der PC. Wir sorgen, dass da noch ganz viel an neuen Issus hinzukommt, selbst bei diesen plattformunabhängigen Paketen, wenn wir auf verschiedenen Architekturen gebaut werden, dass er jetzt noch so Sachen auftauchen, wenn ihr alles unter PowerPC baut, dass da auch noch viele Unterschiede kommen. Oder denkt ihr, dass ihr da schon viel abgefangen habt jetzt mit diesen ganzen Timestamps und so weiter? Ich glaube, dass es für alle Architekturen gilt. Die werden natürlich auch schon von uns gebaut und da sehen wir auch schon die Unterschiede. Aber Pakete für andere Architekturen, die bauen wir zurzeit nicht. Ja, soll auch in der Zukunft dann vielleicht irgendwann gemacht werden. Oder wenn eben unsere Toolchain-Änderungen mal wirklich upstream gelandet sind, dann können auch wirklich die Benutzer verifizieren, ob jetzt die gleiche Binary rauskommt. Also, ja. Also, wenn dann dieser Debian-Helper quasi standardmäßig drin ist, dann würde es ja eher auf allen Architekturen damit gebaut werden. Das heißt, dann fehlt eigentlich nur die Verifikation. Genau. Und unser Ziel ist es natürlich, dass die Verifikation später irgendwann von den Benutzern kommt. Also, es soll ... Die Benutzer sollen selbst in der Lage sein, das Testpaket, was sie jetzt haben, wirklich aus den Sowasen gebaut wurde. Zurzeit ist es ja so, dass jedes Paket im Prinzip nur eine Signatur hat, eine kryptografische Signatur. Und wenn aber andere Personen die gleiche Binary erzeugen können, dann ermöglicht es natürlich diesen Personen, weitere Signaturen zu erstellen. Und dadurch wird natürlich auch dieses ganze Paket vertrauenswürdiger, dieses 5 oder 10 oder 20 Signaturen hat statt nur einer. Genau. Also, wir wollen, dass irgendwann die Leute im freien Feld da auch Verifikationen machen und Bescheid sagen, dass es eben möglich ist, die Verifikation. Okay, danke. Eine Frage noch ganz konkret. Ich habe mir mal ein paar Seiten angeschaut nehmen her. Ich habe ein Paket gefunden, da waren die einzigen Änderungen und dann haben wir die Timestamps von Detail in Datapunkt taggezählt. Also, im eigentlichen Debian-Arch-Paket heißt es, dass da noch etwas schiefgegangen ist, mehr Toolchain. Und ich dachte, das wird jetzt irgendwie rausgepatched durch euer System. Ja, es ist eigentlich auch rausgepatched. Was manchmal vorkommt ist, dass wenn jetzt eine neue Deppelbar-Version oder so in Unstable geladen wird, dann ist das Ganze natürlich schnell reproduziert, aber das passiert manchmal. Also, vermutlich ein vorübergehendes Problem mit der Infrastruktur. Gut, dann melde ich mich nachher nochmal direkt deswegen. Danke. Danke schön.