The long road to reproducible builds
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Part Number | 58 | |
| Number of Parts | 79 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/19581 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FrOSCon 201558 / 79
1
2
10
11
12
13
17
21
23
24
26
28
29
30
31
32
33
34
35
38
39
40
42
43
44
47
50
51
53
57
59
60
61
62
63
66
67
70
71
75
76
77
78
79
00:00
FreewareOpen sourceEvent horizonBuildingBitBinary fileIdentical particlesBus (computing)Thomas KuhnDew pointSystem on a chipFisher's exact testSimulationComputer clusterCAN busSoftwareWalkthroughOpen sourceXMLUMLComputer animationLecture/Conference
01:23
BuildingNetwork operating systemCAN busProof theoryHypermediaSingle-precision floating-point formatSoftwareOpen sourceModule (mathematics)PlatteRAMComputer animationDiagramLecture/Conference
02:30
Punched cardInformation securitySpecial unitary groupMalwareNetwork operating systemConditional-access moduleMIDIIdentical particlesOpen sourceSystem callDirac delta functionSoftware testingContent (media)InternetService (economics)Stress (mechanics)BuildingOpen sourceXML
04:17
FreewareBitWeightNormed vector spaceSoftwareTelecommunicationChaos (cosmogony)WikiInformationIntegrated development environmentOpen sourcePatch (Unix)Virtual memoryDebian GNU/LINUXExplosionSoftwareOpen sourceRun-time systemPolymorphism (materials science)FreeBSDBuildingBootingVersion <Informatik>Similarity (geometry)Sound <Multimedia>ProzedurNorm <Mathematik>PILOT <Programmiersprache>FreewareVariable (mathematics)Computer animation
08:00
StatistikerDiagram
08:44
Java appletFile formatComputer fileWritingBinary fileRevision controlInformationIntegrated development environmentCAN busArchitectureOpen sourceBuildingMiniDiscBounded variationWeightSet (mathematics)Motion captureDomain nameSpacetimeBefehlsprozessorData typeKernel (computing)Source codeLine (geometry)Software testingServer (computing)FreewareExtension (kinesiology)Pairwise comparisonEmailTwin primeUltraviolet photoelectron spectroscopyValue-added networkFunction (mathematics)Network operating systemSpecial unitary groupInterior (topology)EmulationSummierbarkeitMetropolitan area networkExecution unitChemical polarityArmMenu (computing)Control flowTime zoneVariable (mathematics)Distribution (mathematics)MathematicsClosed setScripting languageComputerOpen setMacro (computer science)FAQData compressionMaxima and minimaRootPointer (computer programming)Library (computing)Uniform boundedness principleOvalVarianceFluid staticsDeterminismAsynchronous Transfer ModeOrdinary differential equationUniform resource nameTimestampData conversionGroup action8 (number)Order (biology)Quicksort3 (number)Graphical user interfaceMassNormed vector spaceWide area networkInclusion mapSoftware engineeringMoving averageTouch typingAreaChemical equationARCHIVE <Programm>PNGComputer hardwareMoment (mathematics)PDF <Dateiformat>Distribution <Informatik>Systems <München>Polymorphism (materials science)Time zoneCompilerObject (grammar)Version <Informatik>Block (periodic table)Chain ruleComputer fileInternetEstimationHausdorff spaceFreewareAndroid (robot)File formatCore dumpOpen sourceOpenBSDMainframe computerDebian GNU/LINUXKernel (computing)EmailRAMSoftwaremakeBuildingPowerPCComputer animation
18:17
Interior (topology)CAN busElectronic meeting systemPatch (Unix)Open sourceErlang distributionSummierbarkeitInterface (computing)Uniform boundedness principleDot productRaw image formatRevision controlAlgorithmLine (geometry)Function (mathematics)Row (database)Software engineeringDisintegrationCurvatureSpecial unitary groupEmulationRule of inferenceStructural loadWide area networkInclusion mapHash functionOrder (biology)Newton's law of universal gravitationComputer clusterMetropolitan area networkUniqueness quantificationComputer fileEmailUniform resource nameMach's principleInfinityLink (knot theory)Suite (music)Value-added networkSimultaneous localization and mappingChainTimestampMultiplication signQuicksortElectronic mailing listDeterminismAverageOpen setData compressionDatabase normalizationControl flowSystem callVarianceBuildingScripting languageInformationSheaf (mathematics)Online helpWeightPlot (narrative)Public domainHuman migrationMaxima and minimaGraphic designSoftware maintenanceWikiRepository (publishing)Software testingLocal GroupSoftwareMathematicsSystem identificationArm3 (number)System on a chipNetwork operating systemPhysical lawMenu (computing)Multi-agent systemSurjective function8 (number)Limit (category theory)World Wide Web ConsortiumServer (computing)Amsterdam Ordnance DatumAnnulus (mathematics)Port scannerVirtual memoryGraph (mathematics)StatistikerDebian GNU/LINUXOperateurWikiModemSoftware repositoryHash functionMoment (mathematics)PAPOpen sourceSoftware bugUniform resource locatorOpenSSLScripting languageSource codeSoftwareInternetNumberSet (mathematics)Mobile appProduct (category theory)StreckeDistribution <Informatik>TOUR <Programm>Link (knot theory)Patch (Unix)LIGA <Programm>Computer animation
27:51
Metropolitan area networkArmUniform resource nameRaw image formatMenu (computing)Execution unitEmulationVacuumAmsterdam Ordnance DatumSign (mathematics)CAN busServer (computing)Maxima and minimaSummierbarkeitValue-added networkMulti-agent systemWide area networkLevel (video gaming)Local GroupSoftwareMathematicsPatch (Unix)System identificationChainComputer wormRow (database)MIDIComputerSpecial unitary groupMagneto-optical driveConditional-access moduleRankingNetwork operating systemBus (computing)Java appletNormed vector spaceInclusion mapMoving averageSinePersonal area networkNewton's law of universal gravitationDean numberElectronic mailing listComputer fileVarianceSoftware engineeringPlastikkarteDivision (mathematics)12 (number)Interior (topology)WeightArtificial neural networkMaizeGodDedekind cutInformation managementIdentity managementEmailOpen sourceDistribution (mathematics)Version <Informatik>Server (computing)Propositional formulaInternetState of matterMoment (mathematics)Debian GNU/LINUXTable
31:19
Maxima and minimaMathematicsNetwork topologyWide area networkCuboidBefehlsprozessorSound effectUpdateTOUR <Programm>Firefox <Programm>Slide ruleMoment (mathematics)Web browserSoftware bugProgram codeLecture/Conference
36:31
MikroarchitekturObject (grammar)Mainframe computerComputer hardwareApache MavenDebian GNU/LINUXSoftware bugCompilerCompilerSSHRouter (computing)BuildingSoftwareQuarkInternetComputerPOWER <Computerarchitektur>TOUR <Programm>Computer animation
41:43
Core dumpBuildingFreewareOpen sourceComputer animation
Transcript: German(auto-generated)
00:08
Ich bin Holger Levson, war gerade fünf Tage auf der Debian-Konferenz davor auf dem CTC-Camp, also ich bin etwas sehr müde. Wer von euch Contributed to Freier Software? Und wer zu Debian? Und wer zu anderen Distros? Was so?
00:35
Oder anders gesagt, dieser Talk ist hauptsächlich auf Debian, zeigt aber daran auch die Beispiele anderer Distros.
00:41
Und ich bin sehr interessiert an anderen Distros auch. Das sind die Leute, die gerade im Debian Reproduce Overbuilds Team mitmachen. Davon waren ziemlich viele, also ich bin der Einzige, der den Talk erzählt und die waren halt auf der Debconf.
01:03
Worum es geht, ist, dass bei Freier Software gibt es halt Sources und Binaries. Und das Problem ist halt, dass Freie Software kann man halt sich angucken, modifizieren, Review weitergeben,
01:21
aber kein Mensch benutzt die Source, sondern alle benutzen Binaries. Und das Problem an Binaries ist halt, die werden benutzt, aber es gibt keine Möglichkeit zu gucken, ob ein Binary aus einer bestimmten Source kommt. Man kann den Source verifizieren, angucken, aber dass das Binary aus dem Source kommt, da gibt es einfach keinen Beweis.
01:43
Das Einzige, was man machen kann, ist halt die Source ein zweites Mal bauen und hoffen, dass dasselbe rauskommt. Die Probleme wurden in diesem Talk von Mike Perry und Seth Schön auf dem 31c3 gut beleuchtet. Die haben da einmal das Beispiel gehabt von der OpenSSH-Lücke, das war im CVE 2012 oder so.
02:08
Und der Unterschied im Binary ist ein Bit. Ein Bit ist andart und du hast einen Remote-Boot-Exploit. Ein anderes schönes Beispiel, was sie da auch hatten, war ein Kernel-Modul, was Sources im RAM modifiziert hat.
02:22
Also die Sources auf der Platte blieben gleich, die Sources im RAM waren anders, wurden halt kompliziert und kamen ins Binary rein. Und auch die Dienste arbeiten aktiv daran, also das ist ein Beispiel, was im Zuge des Noden- und Intercept-Geschichten rauskam.
02:41
Die haben in diesem Falle halt einen Trojaner für das macOS-Development-Kit, um eben halt die macOS-Binary so zu verändern. Selbst wenn die Entwickler denken, ihr habt eine sichere Maschine, das muss nicht so sein. Und auch im Debian-Fall sind es, weiß ich nicht, 50 oder so Bildmaschinen, die den ganzen Tag am Internet hängen.
03:03
Und die kann man nicht prinzipiell nicht sicher machen. Und die Idee ist halt, dass jeder die Möglichkeit haben soll, Binary's zu reproduzieren, mit dem er selber baut. Und das nennen wir halt Reproduce-over-Builds.
03:23
Oder auch Deterministische Builds. Vernünftiges deutsches Wort habe ich noch nicht gefunden für das Bild. Und es ist aber auch nicht nur um Security, sondern es hat noch andere Sachen. Also bei Debian kriegen wir Fails to Build von Source sehr viel mit.
03:40
Es gibt auch nebenbei Debug-Pakete jetzt in Debian. Und das Schöne, wenn die Builds reproducible sind, dann kann man die Debug-Pakete zu jeder beliebigen Zeit kreieren. Und auch andere Sachen, wenn man Änderungen an der Toolchain hat und in Debian-Fall an der Palper und hofft, dass sich daran nichts ändert.
04:05
Also man meint, man hat was in der Palper geändert, dass ein Paket Binary nicht sich ändert. Dann kann man das hiermit halt beweisen, dass es so ist. Und inzwischen, the whole world is watching.
04:22
Wir haben vor zwei Jahren angefangen, waren aber auch gar nicht mal die ersten. Also zuerst fing es an, Bitcoin hat zuerst den Bitcoin-Klientrip reproducible gemacht, weil die Entwickler halt Angst haben, was ist, wenn da halt eine kaputte Version drin ist. Und Bitcoin hat jetzt 4 Milliarden Marktwert gehabt damals. Das ist halt eine ziemliche Initiative für Leute, das zu machen.
04:42
Und die Bitcoin-Entwickler können sich halt nicht sagen, wir waren das nicht. Also die Weg, dass sie es sagen können, das war unwendig, ist mit reproducible Builds. Tor ähnlich. Debian komme ich gleich zu. NetBSD hat eine Variabel MKREPRO, die kann man setzen. Das gibt dann reproduzierbare Bauten für NetBSD.
05:01
FreeBSD haben auch schon daran gearbeitet. Da sind wohl fünf Fehler im Base-System. Kurboot habe ich verifiziert. Kurboot ist komplett reproducible, ohne Payloads. Es gibt ein paar Payloads, die sind noch nicht reproducible. Und OpenWRT ist, die Pakete sind bis auf fünf Ausnahmen von 200 Stück, alle reproducible.
05:24
Die Images zum Booten selber noch nicht. Und wir denken, reproducible Builds sollen die Norm werden. Bei freier Software auf jeden Fall, aber an sich bei jeder Software.
05:46
Zum aktuellen Status. Vor zwei Jahren haben wir in Debian angefangen damit. Seit ungefähr einem Jahr sind wir sehr aktiv dabei. Wir haben diverse Vorträge gehalten, die sind alle bei uns im Wiki verlinkt.
06:02
Auch die, die ich eingangs erwähnte, vom 31c3. Wir schreiben jetzt wöchentliche Reports seit 16 Wochen, glaube ich. Diese Reports sind immer so drei, vier Bildschirmseiten lang. Diese Woche nach der Debian Conf noch viel länger. Technisch hat sich seit dem letzten Jahr der Debian Conf einiges getan.
06:23
Ich gehe auch gleich nochmal im Detail ein, was wir da alles gemacht haben. Strip Determinism ist ein Tool, um nicht-deterministische Sachen zu entfernen. Das Bildenvironment, das zeichnen wir auf, weil der Weg ist, um Software reproducible machen,
06:43
ist in der selben Umgebung wieder zu bauen. Das ist der einzig garantierte Weg. Es kann sein, dass ähnliche Umgebungen auch dieselben Ergebnisse geben. Aber richtig garantiert werden kann das nur, wenn man das exakte Bildenvironment hat.
07:03
Noch nicht, aber ich komme da auch gleich nochmal dazu. Reproducible DebianNet ist unser Testsystem, was ich auch gleich erkläre. Diffoscope ist ein Tool, das wir geschrieben haben. Das hieß früher der Bindiff, um Unterschiede in Binärpaketen ursprünglich anzuzeigen.
07:23
Source Date Epoch ist eine Variabel, die wir einführen, damit, was Leute immer gemacht haben, sie haben gebaut und das Bild Date als Variabel genommen, von wann die Software ist.
07:40
Das ist an sich nicht von wann die Software ist, sondern die Software ist, von wann die Sourcen das letzte Mal modifiziert werden. Source Date Epoch enthält das letzte Modifikation der Sourcen als Epoch-Variabel, also ausgehend vom ersten Mal, seit 70. Wir haben diverse Patches geschrieben, um das zu machen. Da jeder Statistiken liebt und man mit Statistiken schön lügen kann,
08:05
haben wir den Graph, den wir gemacht haben, der sowieso eine Lüge ist. Da oben ist 100% bis Weihnachten gemacht. Die Realität sieht leider so aus. Auch das ist nicht die Realität, sondern das ist unser Testsystem. Wir haben diverse Variabel.
08:22
Wir bauen zweimal und haben da diverse Unterschiede in den zwei Bilds drin, die ich gleich erkläre, aber ich gehe davon aus, dass in der Realität, wenn ihr alle oder wer auch immer die nachbaut, da gibt es noch mehr Unterschiede und wir sind nicht wirklich bei 83%.
08:43
Zu dem Strip Non-Determinism Tool, das normalisiert diverse Fallformate, A-Archive, ZIP-Archive, JAR-Archive, was auch ZIPs sind, HTML, DOC, PNG, da tut es die Timestamps raus. Das ist written in Perl, weil man wegen dieser Trusting Trust,
09:05
man kann den Compiler nicht trauen, dass es in derselben Sprache geschrieben wird, dass es sowieso zum DB-Markete bauen verwendet wird. Das macht es halt möglich, diverse Sachen zu normalisieren, die die Pakete nicht haben.
09:20
Damit räumen wir das quasi auf. Um die Sourcen wiederherzustellen, also um die Bildumgebung wiederherzustellen, sind wir auf ein Bildinfo-File gekommen, was neu ist, was bei die Package rausfällt, und in diesem Bildinfo-File stehen halt drin die Sourcen, die Checksamen der Sourcen, die Checksamen der Binaries
09:42
und alle Pakete, die installiert worden sind. Bei Debian gibt es Snapshot, Debian Org, da kann man jede Version sich holen, die jemals veröffentlicht wurde, also für alle Architekturen, alle Distributionen. Und damit können wir halt präzise das wieder installieren. Ein Bildinfo-File sieht halt so aus, das ist so ein ganz normales RFC-822-Format,
10:03
wo halt die Bildarchitektur drin steht, das Source-Paket, die Binaries, die gebaut werden, und das sind die Checksamen der Sources hier, da, und das sind, zusammengefasst, und das sind das Bild-Environment, da sind alle Pakete aufgelistet, die zum Bauen benötigt wurden. Was wir noch haben ist leider dieser Build-Pass hier, der da.
10:24
Wir haben keinen Weg gefunden, den Build-Pass variabel zu machen. Der Build-Pass wird über den Compiler in sehr vielen Objekten drin und wir haben keinen Weg gefunden, den rauszunehmen. Im Moment muss man ihn festlegen, wir hoffen, dass es irgendwann noch geht, aber im Moment haben wir das nicht.
10:40
Und wie wir das machen? Wir bauen halt einmal, speichern die Ergebnisse, ändern das Environment, bauen zweites Mal und vergleichen. Das ist an sich relativ simpel. Das sind die Dinge, die wir variieren. Wir ändern den Host-Namen, wir ändern Domain-Namen, die Zeitzone,
11:03
die Language, die LCL, den User, UAD, Git, den UTS-Namespace, die Kernel-Version, UMass, CPU-Type, noch nicht, aber in zwei Wochen, sag ich mal. Das Jahr, Monat, Tag ändern wir auch noch nicht, aber da wir die Timezone ändern und wir bauen den ersten Build,
11:20
bauen wir mit GMT minus 12 und den zweiten mit GMT plus 14. Das heißt, da liegen mehr als 24 Stunden dazwischen. Also sehen wir auch Tagesunterschiede. Und wenn wir am ersten oder letzten das Monats bauen, sehen wir auch öfter mal Monatsunterschiede. Es wird noch mehr Unterschiede geben. Also eine Sache, die wir bis jetzt noch nicht getestet haben, war Filesysteme,
11:43
weil die Filesysteme verhalten sich auch unterschiedlich. Zum Beispiel die Block-Size ist unterschiedlich und darum ist die reportete Größe von Dateien teilweise anders. Und darum hat jetzt einer von uns aus dem Team DisorderFS geschrieben, was halt sowohl die Dateien in einer zufälligen Reihenfolge,
12:02
das ist ein Fuse-Filesystem, und es gibt die Dateien in einer zufälligen Reihenfolge zurück und reportet auch unterschiedliche Block-Size. Und das werden wir, weiß ich nicht, diese Woche einführen. Das ist halt gestern in Unstable. Und dann wird wieder der Graf ein bisschen runtergehen.
12:22
Testen tun wir das Ganze auf diesem reproducible-debian-net, was ursprünglich mal ein Shell-Script war, lief. Inzwischen sind das 67 Jenkins-Jobs, die zwischen auf sieben Hosts laufen. Also das kommt auch davor, weil wir für jeden dieser sieben Hosts haben wir drei Jobs, die Change Roots einrichten und drei, die P-Bilder konfigurieren.
12:40
Und wir testen da Unstable, Debian-Testing, Unstable und Experimental. Und ab demnächst auch ARM-HF und auch PowerPC E1164. Und wir testen auch nicht nur Debian, sondern auch NetBSD, OpenBRT, Core, Boot und FreeBSD derzeit.
13:01
Demnächst auch Fedora. Wobei wir da, es ist so ein Test-App, ich baue gerade einfach bei NetBSD einfach das Basissystem und vergleiche die bei OpenBRT ein paar Pakete. Und auf Fedora werden wir so 200 Pakete bauen, das Basissystem, um zu gucken, wie sich RPM verhält.
13:26
Das sind einfach Shell-Scripter, die einfach aufrufen, im FreeBSD-Fall halt Make Build World, Make Install Kernel und das dann vergleichen. Wenn wer Lust hat von euch, andere Sachen auf dieser Debian-Hardware zu testen, ich habe Interesse halt an Fedora, aber auch an OpenBSD oder Arch.
13:44
Ich will an sich die gesamte Free-Software-Welt erforschen. Android, wäre interessant. Es gibt da, Replicant macht da auch was. Ja, könnte man machen.
14:01
Und Dank an Profit Bricks, auf deren Hardware läuft das. Das ist ein Momentensystem mit 50 Cores und 70 GB RAM. Und wir sind gerade dabei, das auf kleinere Nodes zu verteilen. Das ist alles gesponserte Hardware. Diffoscope, was früher Diff-Dap-Bind-Diff heißt,
14:22
untersucht Unterschiede zwischen zwei, ursprünglich zwei Changes-Files, inzwischen einfach zwischen zwei Objekten. Das geht dann rekursiv rein. Man kann also auch inzwischen einfach zwei Verzeichnisse angeben oder zwei RPMs oder zwei SquashFS-Filesysteme, zwei ISOs, was auch immer. Und der Diff-Dap-Bind-Diff geht da rein und uncompressed Archive,
14:45
uncompressed PDF, disassembled sources, um darzustellen die Unterschiede. Ich habe gleich diverse Screenshots, was klar macht, was Diffoscope macht. Und am Ende macht es auch Binary Comparison. Und das ist seit, na, jetzt nicht today, sondern seit letztem Donnerstag ist es in stretch.
15:06
Das ist ein Beispiel-Output und das sind halt die Unterschiede zwischen zwei Builds. Warum die jetzt anders sind, ist mir gerade nicht klar. Das sind irgendwelche Git-Chars.
15:22
Diffoscope hat auch einen Text-Mode für Leute, die das lieber so lesen. Oder auch für in Mails reinpasten ist das deutlich besser. Dann das andere, was wir jetzt neu gemacht haben, ist Source-Date-Epoch, weil eben das Bilddatum normalerweise nicht besonders sinnvoll ist.
15:42
Das ist eine standardisierte Bild-Environment-Variabel, die halt benutzt werden soll statt dem aktuellen Datum. Und die wollen wir auch nicht debianmäßig haben, sondern die versuchen wir upstream reinzukriegen. Im Fall von Debian nehmen wir als Modifikation den letzten Debian-Change-Log-Entry und sonst den letzten Datei des Sources.
16:05
Und gefixt haben wir es bis jetzt in Help-To-Money, Epidoc, Ghostscript und Text-to-HTML. In Spinks gibt es ein Pull-Request, der, also upstream ist es genommen worden, aber noch nicht genommen worden, der Debian-Maintener hat schon reingenommen. Wir haben das Ganze noch für diverse andere Softwares gemacht.
16:25
Inklusive GCC, weil wenn du mit minus minus Date, wird den GCC halt auch sonst normal die aktuelle Bildzeit reinschreiben und mit Source-Date-Epoch nicht. Und sieht gut aus an sich, dass der Patch reinkommt.
16:44
Was wir gefunden haben, wir hatten im Forestem-Talk, falls den wer gesehen hat, da hatten wir so 70 Beispiele und das war dann ein ziemliches Durchscrollen. Jetzt sind es ein paar weniger. Also es gibt Timestamps in G-Sub-Headers. Und zwar sind die, ich meine, die sind auf jeden Fall der Timestamp
17:03
und ich meine auch die Timezone spezifisch. Und da ist an sich die Lösung ziemlich einfach, einfach minus N auf beim G-Sub-Aufruf machen und dann fällt das raus. Python-Version hat dasselbe auch. Auch da in Setup-Py einfach Tag-Date gleich falsch setzen
17:21
und dann macht Python das nicht mehr. Und sonst sind halt hier immer die Bilddates drin. Static-Libraries haben auch Timestamps drin. Das geht halt auch mit dem Deterministik-Mode von Bin-Utils. PNGs haben auch Timestamps drin. Kein Mensch braucht sie an sich, so als default zumindest.
17:41
Mal sind sie sinnvoll. Lässt sich aber auch mit beim Convert einfach auf Null setzen. Tarbols haben User und Group im Tarbol drin. Das lässt sich dann auch mit Onaroot oder was auch immer festsetzen. Das weitere Problem bei Tarbols, die Reihenfolge im Tarbol ist auch nicht deterministisch.
18:02
Und dann kann man das durch Sort-Pipen. Das Problem bei Sort ist, Sort hängt wiederum von der Locale ab. Darum muss man halt noch LCL setzen. Timestamps in Tarbols dasselbe. Also da muss man auch wieder Minus-Minus-End-Time machen.
18:21
Erlang-Files haben das auch. Ruby, Gamestacks haben das. Es ist überall drin. Aber vom Feedback von den Upstreams, die bis jetzt meistens schon sehr schnell verstanden haben, dass man das durch die Source-Set-Ipoch ersetzen kann.
18:44
Configure Scripts auch. Hash-Order. Hashes werden auch in zufälliger Reihenfolge angelegt. Die kann man auch normalisieren. Ich habe leider vergessen, was da steht. Header-Files auch. Make-Files-Rekorden.
19:00
Auch die Timestamps da. Da muss man dann teilweise doch nach Upstream das Make-File schicken. Das ist generell auch der Weg, den wir gehen wollen. Wir könnten vieles in Debian in die Package fixen, aber wir wollen an sich das in den Upstream Make-Files fixen, damit auch andere Distors davon profitieren. Wir haben in Debian ein paar Toolchain-Issues gefixt.
19:23
Also in Wheel, DocBook, Front4, Speisen-Support. Und wir haben auch außerdem neben den Toolchain-Sachen haben wir 644 Bucks submitted gehabt. Mit Reproducibility-Issues, mit Patches. In der letzten Woche sind nochmal ca. 100 dazugekommen.
19:47
Der Graph sieht so aus, wobei wir inzwischen 400 weitere Bucks haben, die in diesem Graph nicht drin sind. Nämlich Pakete, die halt nicht bauen. Die kriegen wir halt dadurch, dass wir sofort immer bauen, kriegen wir die auch mit und machen auch Bucks dafür.
20:06
Zu den einzelnen Sachen, was wir jetzt gefixt haben in die Package. Da haben wir eine Sache gefixt. Das ist halt die File-Order der Package. Der Produkt ist jetzt deterministisch.
20:21
Was noch drin sind, sind die Timestamp in den A-Headers. File Permissions und auch die Reihenfolge in dem Data-Control. Das ist nicht deterministisch. Und wir wollen dieses Bild-Info-File haben. Das ist auch noch nicht in DPPKG drin. Auf der DebConf haben wir jetzt gerade mit dem DPPKG-Maintener und den FTP-Masters geeinigt, wie dieses Bild-Info-Format aussieht.
20:43
Das ist ziemlich genau, was ich eben beschrieben habe. Das einzige wesentliche Unterschied ist, dass wir in die Spezifikation reinschreiben werden. Das ist experimental und kann sich noch ändern. Der Paper hat auch wieder die M-Times, die noch gemacht werden müssen.
21:03
Und der Aufruf von Dehastripten und Non-Deterministen. Die gepatchten Pakete, die diese Bucks gefixt haben, die ich hier gerade aufliste, sind bei uns in unserem Archiv drin. Darum haben wir diese 83 Prozent. Und darum ist sehr graf eine Lüge, weil das eben noch nicht in Unstable ist.
21:21
Aber jetzt mit dem Einigung bei der DebConf gehe ich davon aus, dass im nächsten Monat, sage ich mal, wirklich auch CID auf 83 Prozent kommt. CDBS hat denselben, dass es Source Date Epoch benutzt ist, dass eine Bucke noch offen ist. Und bei S-Build ist das Problem noch,
21:43
dass S-Build aus Sicherheitsgründen einen zufälligen Pfad nimmt bei jedem Bauen, damit zwei User gleichzeitig dieselbe Software bauen können. Und das müssen wir auch noch in Mod finden, damit das nicht passiert. Wir haben einen S-Rebel-Skript geschrieben, was S-Build benutzt und Snapshots,
22:02
damit man die Sourcen reproduzieren kann. Und dieses S-Rebel-Skript benutzt moment noch unser Repo. Und sobald unser Repo obsolit ist, werden wir es halt in S-Build reintun, dass alle Leute einfach die Binaries reproduzieren können.
22:20
Und auch auf dem Bild dies bauen die moment noch mit dem S-Build, mit dem zufälligen Pass. Das muss halt noch geändert werden. Und das FDP-Archiv muss diese Bild-Info-Files annehmen, was halt jetzt passieren wird. Und irgendwann müssen wir auch noch mal Debian-Policy ändern und reinschreiben.
22:41
Packages müssen reproduzierbar bauen. Im Moment ist das alles noch Wishlist und eine Idee, wie es sein könnte. Wobei auf der Depp-Komf jetzt der Raum war voll, da waren 250 Leute drin oder sowas. Und wir haben gefragt, ob wir die Bugs jetzt schon, im Moment sind es alles Wishlist-Bugs, ob wir die auf Importen machen sollen. Und an sich war der ganze Raum dafür.
23:05
Also, dass es Policy Must wird, wird nicht fürs nächste Debian-Release in einem Jahr passieren, sondern wahrscheinlich eher in drei Jahren. Wenn ihr helfen wollt,
23:21
das ist jetzt, wie gesagt, der Debian-spezifische Teil. Aber so habe ich eben auch geguckt, ob OpenSSL reproduzierbar ist. Einfach zu dieser URL da gehen. In dem Fall schräg schräg OpenSSL. Und dann kommt die Testseite für OpenSSL.
23:40
Was das Interessante ist, ist der BinLift-Link hier. Das zeigt den Unterschied an. Wenn wir annotieren, wir schreiben Notizen für Pakete, die wir untersucht haben, und dann kommt erst mal so eine Note, wenn die da ist, sonst kommt der BinLift-Output. Im Debian-Package-Trekker steht der Ziel auch drin,
24:01
dass das Paket nicht reproducible ist. Und auch in der Debian-Package-Overview und im Maintainer-Dashboard wird auch angezeigt, ob Pakete reproducible sind oder nicht. Wir haben im Wiki diverse Tipps für die einzelnen Issues,
24:21
also Timestamps hier und da. Wir haben auch ein weiteres How-To geschrieben oder sind dabei, gerade zu schreiben, was sich mehr an nicht Debian-spezifisch ist, sondern generell die Fälle erklärt. Das ist auf reproducible-debian-net-slash-how-to verlinkt. Und wir sind auch gern bereit,
24:41
sowohl per Mail oder per IRG weiterzuhelfen. Wenn man selber testen möchte, also wenn wir uns einfach hochladen, das wird automatisch getestet, selber testen braucht halt ein P-Builder-Setup mit einer eigenen Config, um unser Repository zu benutzen.
25:02
Wie das aufzusetzen ist, ist im Wiki dokumentiert. Und wir werden dieses Skript auch in Dev-Skripts reintun, sobald die PKG gefixt ist. Dann ist unser Repo nicht mehr nötig. Wenn ihr mitmachen wollt,
25:20
es macht super Spaß. Jede Woche lerne ich etwas Neues, was ich vorher mir nicht vorstellen konnte. Wir reviewen die Pakete, sowohl die Debian-Dev angucken, kategorisieren, versuchen, die Ursachen zu finden, hacken an diesem Diffuskop und Strip Non-Determinism
25:42
und submitten Patches. 97% aller Bugs, die wir machen, haben inzwischen Patches. Das ist ziemlich gut.
26:01
Es sind nur 22.000 Source-Pakete. Und davon sind nur 3.000 unreproducible im Moment. Durch diesen Diffuskop sieht man oft, was das ist.
26:54
Die eine Sache ist, den Source Code zu verstehen und diese Fehler zu finden. Die meisten reproducible Issues
27:01
sind oft trivial, weil es nur ist, die Sortierung zu fixen. Oder es sind auch bei vielen Sachen Tool-Probleme. Wie man die Pakete findet, ist ein bisschen schwierig, die Maus auf dem Kopf zu bedienen. Hier ist unsere Hauptseite.
27:27
Das ist die reproducible Debian-Net-Seite. Hier sind die Statistiken da. Dann kommt hier der andere Teil. Wir haben 3.900 Pakete mit Notes. Wir haben 313 Pakete mit Issues,
27:44
die nicht identifiziert sind. Das sind die wirklich Interessanten. Ich könnte auch daneben klicken, aber es ist hier Packages without Notes.
28:01
Falls sollte ich aber ein Netz anmachen.
28:31
Der Weg ist hier hinzugehen. Die mit grün sind die, die ich schon mal angeguckt habe. Dann nehme ich ein neues Paket.
28:42
Das ist unreproducible. Das Depp unterscheidet sich da. In dem Depp unterscheiden sich die Dinger. Die install-size variiert hier. Um ein Byte. Das eine Byte-Unterschied kommt dann nicht daher.
29:03
Oder vielleicht doch daher. Warum das da ist, weiß ich nicht. Dieses reproducible Debian-Net baut ständig Pakete nach.
29:22
Das baut jeden Tag 1.300 Pakete nach. Wenn neue Versionen hochgeladen werden, werden die automatisch getestet. Wir testen auch kontinuierlich alte Versionen neu gegen die neuen Libraries. Im Moment dauert es 2-3 Wochen, um es komplett durchzubauen.
29:45
Wir können auch Pakete schedulen. Es werden automatisch welche schedulet, die hochgeladen werden. Wenn ich gerade OpenGit Annex angeschaut habe, kann ich auch sagen, bau das jetzt noch mal und lass die Artefakte da.
30:02
Diese Depps werden dann auf den Server gelegt, dass du die runterladen kannst und dann selber vergleichen kannst. Wenn ihr nicht bei Debian mitmachen wollt, könnt ihr euer eigenes Team aufmachen.
30:28
Wie gesagt, jede Software-Diskussion sollte reproduzierbar sein. Wie starten, am besten einfach unsere Seiten angucken, was wir gemacht haben, mit mir reden oder mit uns reden
30:42
und rum experimentieren. Der eine Java-Maintainer in Debian ist da sehr aktiv bei.
31:02
Also hat sich noch keiner gefunden, der er lang versteht, warum das ist. Bei Haskell sieht es besser aus. Wir haben uns das schon angeschaut. Die Bootstrap haben wir schon angeschaut.
31:22
Das waren auch wieder M-Times. Die waren unterschiedlich. Generell ein Problem ist, dass die Reihenfolge, wie die Pakete installiert werden, nicht deterministisch ist. Damit laufen die Post-Ins in unterschiedlicher Reihenfolge ab. Wenn die Users anlegen, haben die unterschiedliche User-IDs. Dann bricht das alles zusammen.
31:42
Da müssen wir gucken, wie wir das machen. Es ist auf jeden Fall unser Ziel, reproduzierbare Images zu haben. Container-Images zu haben, Live-Images. Das soll alles kommen. Live-Image oder Installer ist letztendlich dasselbe.
32:04
Wir sind schon bei Fragen.
32:22
Das kann ich so generell nicht sagen. Ich weiß, dass Leute auch Defoskop benutzen, um zwei verschiedene Versionen die Unterschiede anzugucken. Um zu gucken, ob nur die Beinahe sich ändern, was geändert wird. Das habe ich noch nicht gemacht.
32:40
Unterschiede mit verschiedenen GCC-Bauten untersucht. Das wäre bestimmt interessant. Dafür verstehe ich auch zu wenig von GCC. Wir finden auch die Bugs,
33:07
wo Leute Bild-Time-Optimisation machen. Das ist nicht so gut, wenn man nachher den Code auf einer anderen CPU ausführt. Das sind einfach Bugs. Die finden wir jetzt. Das ist ganz gut.
33:54
Die Tales-Leute haben versucht, Tales zu diffen. Das installierte Tales. Das diff war 200 Megabyte groß.
34:02
Dann haben die es mit Fake-Time gebaut. Fake-Time sorgt dafür, dass die Zeit immer gleich ist. Damit ging das diff auf 20 Megabyte zurück. Wir sind noch dabei einige Bugs zu fixen, damit wir die anderen Bugs sehen.
34:28
Kannst du? Im Moment wirst du auf jeden Fall noch Unterschiede sein, weil die ganzen Bild-Times noch drin sind.
34:41
Das kommt drauf an. Das findet man nicht ganz.
35:06
Wenn diese Änderungen in DPKG und Dapp-Paper drin sind, dann sind 80% der Pakete identisch, wenn du sie baust. Die anderen sind halt noch nicht identisch, weil da noch kleine oder große Unterschiede sind.
35:23
Zu diesem Fake-Time nochmal, ich habe den Bug hier nicht in den Slides drin. Die Tor Browser-Leute benutzen Fake-Time, um Tor Browser damit zu bauen. Da verhält sich der Java-Compiler komisch. Da gibt es diverse Bugs, die Fake-Time auslöst,
35:40
sodass wir dazu gekommen sind, nicht Fake-Time zu benutzen. Das ist zwar eine schnelle Lösung, aber führt zu weiteren Problemen. Die Tor Browser hat es auch neulich beim Firefox-Update auf 38 oder so gerissen, wo dann das ganze Bildsystem in die Uhr geflogen ist wegen Fake-Time. Darum wollen wir das halt nicht.
36:01
Wir wollen diese Bild-Entgebung wiederherstellen, wollen wir in einem normalen System haben und nicht, was eben Bitcoin und Tor auch macht. Die verlangen, dass man das in einer VM nachbaut, die genauso konfiguriert ist. Dann hast du einen VM-Container, wo du auch wieder nicht weißt, wo der herkommt. Bei dem weißt du irgendwann,
36:22
dass du diese Bild-Environment wieder reproduzieren kannst. Wir haben auch noch einen Projekt, der Rebootstrap von Linux-Toolchains auf anderen Architekturen macht. Der macht Cross-Kompilieren der Toolchains. Das Ziel ist, dass beim Cross-Kompilieren auch dasselbe rauskommt.
36:40
Dann hast du einen verschiedenen Compiler gebaut und dann weißt du auch, dass diese Trust-in-Trust-Geschichte gelöst ist, wenn du es mit hinreichend vielen Compilern gebaut hast. Das kommt dann sicherlich auch noch.
37:20
Wenn die in Debian sind,
37:21
dann gucken wir uns das auch schon an. Wir bauen ja auch mit Maven in Debian und die Pakete vergleichen wir auch.
37:58
HMAF war die nächste Hardware, die ich in die Finger bekommen habe.
38:02
Darum habe ich die genommen. Wir müssen jetzt generell unser Skript erweitern, dass es auf verschiedenen Hosts baut per SSH. Das hatten wir spezifiziert und hatten auf der Debcom keine Gelegenheit, das zu hacken, aber ich denke, es ist ein halber Nachmittag und dann geht das. Dann können wir auch beliebig viele Architekturen hinzufügen, so lange ich die Hardware kriege.
38:26
Ich habe mit ihm gesprochen in drei Monaten. Es kommt demnächst, auch bei PowerPC64-EL hat auch Debian die Systemadministrieren genügend Blades davon,
38:42
die eideln. Dann wäre es auch interessant, die Arch-All-Pakete anzugucken, ob die auf verschiedene Architekturen dasselbe bauen. Das ist das nächste, was wir machen.
39:00
Wir wissen, dass es bei vielen Paketen funktioniert, aber das systematisch durchtesten haben wir noch nicht.
39:20
Software hat Bugs. Ich kenne keinen. Unsere Idee ist, wir wollen Bit-by-Bit identische Builds haben. Man benutzt nur die Binaries und nicht die Dokumentation, die mitgebaut wird. Die Dokumentation ist Teil des Binärpaketes.
39:42
Die Postinskripte, die als Route laufen, ist viel zu sagen, der ganze Bit-Haufen muss komplett identisch sein. Anstatt dass man reingeht und guckt, ist der Unterschied nur im HTML-Dokument, oder ist der Unterschied im Binary? Daher wollen wir, damit man nur die kompletten Dapps nehmen kann
40:00
und sagen, die Dapps sind 100% identisch. Auf jedes Paket, das nicht identische Dapps hat, gucken wir mit Diffoskop rein, wo die Unterschiede liegen. Der Maintainer sind wir. Geschrieben hat es Lunar.
40:22
Inzwischen haben wir noch 3-4 weitere Leute damit gearbeitet. Diffoskop empfehle ich wirklich auszuprobieren. Das ist wirklich lustig.
40:45
Es verarbeitet auch RPMs und auch ISOs kann es vergleichen. Und zwei Verzeichnisse. Also zwei Objekte. Du kannst Diffoskop, Verzeichnis 1, 2 machen. Was bei RPM noch interessant ist,
41:01
RPM hat in der RPM-Spekt drin stehen, dass es da ein Feldbilddate gibt. Was per Definition nicht geht. Man kann es natürlich auch auf den ersten 1970 setzen. Dann ist das gut. Darum will ich auch Fedora bauen, weil ich genau da sehen will, was da fehlt.
41:30
Wenn ihr keine weiteren Fragen habt, bleibe ich noch mit Dank an das Reproducibles-Team und an die Linux Foundation Core Infrastrukturinitiative,
41:41
die Lunas und meine Arbeit sponsern. Danke euch für euer Interesse.