WEBVTT 00:00.000 --> 00:19.160 So, we are going to continue now on the topic of making things more deterministic. 00:19.160 --> 00:28.800 And the next talk is going to be about Lila, which is a decentralized tool for making reproducible 00:28.800 --> 00:34.240 build, like very fine reproducible, making it verifiable, the build are reproducible. 00:34.240 --> 00:45.280 In the next so as ecosystem, and the speakers today are Julien Marca and Rabuf, are also known 00:45.280 --> 00:54.600 as Ano Engel, thank you very much, and I am sure they are going to give a great talk. 00:54.600 --> 00:59.640 We are going to do the cool thing where they hold another Yimike, because there are two speakers 00:59.640 --> 01:03.600 and we only have one microphone, because I am keeping this one. 01:03.600 --> 01:15.600 All right, so, around the class for our speakers, and enjoy. 01:15.600 --> 01:22.120 Thank you, Martin, so I am Julien, this is Rabuf and we are going to talk about a tool called Lila. 01:22.120 --> 01:28.760 So, this presentation is about software supply chain and software supply chain security, 01:28.760 --> 01:35.200 because Lila is a tool that we designed to improve the software supply chain security. 01:35.200 --> 01:41.680 And especially the kind of question that it solves is a problem in software supply chain security 01:41.680 --> 01:48.920 that can happen at build or distribution time, which means essentially it solves the question 01:49.000 --> 01:57.440 of what if there was a not occur malicious person that gained control of the Nixx build infrastructure 01:57.440 --> 02:03.440 and was able to put in the cache some binary with some backdoor. 02:03.440 --> 02:13.000 And there is a generic solution to this that has been developed in the last ten years. 02:13.000 --> 02:15.800 It's the idea of build or reproducibility. 02:15.840 --> 02:22.320 So, if a build or reproducibility is what is the property of software components, 02:22.320 --> 02:26.040 where when you build that software several times and several machines, 02:26.040 --> 02:29.600 you get the exact same bit by bit results. 02:29.600 --> 02:35.320 And this simple idea brings a lot of benefits for software distribution, 02:35.320 --> 02:41.000 because then you can, when you are downloading a binary from someone, 02:41.000 --> 02:45.640 let's say the Nixxx cache, you could also ask some other 02:45.640 --> 02:51.640 people to rebuild the same software and verify that everybody agrees that whatever you're 02:51.640 --> 02:59.080 downloading from the cache is whatever you agrees that the software should be. 02:59.080 --> 03:04.600 So, there is this effort called reproducible builds with a lot of people working together 03:04.600 --> 03:09.280 to build a build of software more reproducible. 03:09.360 --> 03:16.000 And for to get the benefits of this, you need to kind of check all the software in Nixx 03:16.000 --> 03:18.640 and check if they are reproducible. 03:18.640 --> 03:22.720 So, last year in the same devroom, maybe some of you remember, 03:22.720 --> 03:27.120 I presented some of my research that I do as part of my PhD, 03:27.120 --> 03:33.520 where I essentially tried the evaluator reproducibility of all packages in Nixx 03:33.520 --> 03:38.640 through time and our main research was that as of today, 03:38.640 --> 03:44.560 the reproducibility of Nixxx is about the 90% mark. 03:44.560 --> 03:53.600 So, this is all cool, but the problem is that to do that, it took us 15,000 hours of build time 03:53.600 --> 03:55.760 and 10 machines. 03:55.760 --> 04:01.360 So, so we are the only one doing it, so you have to kind of trust us on this, on the results. 04:02.320 --> 04:07.200 And so it kind of defeat a bit the purpose of build reproducibility. 04:08.000 --> 04:16.720 And so, all this makes it difficult to sustain kind of monitoring for the Nixx community 04:18.640 --> 04:24.320 because of the enormous size of the package that. 04:24.320 --> 04:26.400 So, we decided we needed something else. 04:27.360 --> 04:37.920 Yes, and that something else is called lila, and lila is hash collection infrastructure. 04:37.920 --> 04:51.360 And that means if people run builds, they hash the result and they send a sign to the hash collection infrastructure. 04:51.360 --> 04:56.720 So, because we collect all those hashes, if the hash is matched, then we know there are several 04:56.720 --> 05:02.720 people who have gotten the same result. And the good thing is about the good thing about this is 05:02.720 --> 05:08.080 because you sign the hashes, people do not need to trust us, we just pass along the hashes, 05:08.080 --> 05:10.720 but you can trust to people who actually build the stuff. 05:12.720 --> 05:19.840 And so we don't use this, so we intend to use this for two different things. 05:20.800 --> 05:27.440 One thing is a trust in the reproducibility, the fact that something has been reproduced. 05:27.440 --> 05:32.640 So, that's something you will do downstream, but we also want to use this information 05:33.360 --> 05:40.320 to create reporting on the reproducibility of the packages so we can fix all the packages that are 05:40.320 --> 05:47.040 not yet reproducible. So, what does this look like? I'm sorry. 05:47.120 --> 05:53.600 So, a little bit of history, we started in a few years ago, we wanted it this for a while, 05:53.600 --> 05:59.600 but 2024 we started series depending on it. We applied for some funding, but that it happened, 05:59.600 --> 06:02.080 so we started it now free time, might some weekends. 06:03.680 --> 06:09.600 25, we participated in this of an excellent next security project. We got 06:11.040 --> 06:16.480 funding for a slice of our milestones, so that was really good. That was gave us a boost to get 06:17.360 --> 06:24.880 to today, and today we can proudly present that Lila is now backing the reproducibility 06:27.680 --> 06:32.080 graphs and reports that you can find on reproducible the next west of the arc. 06:33.280 --> 06:37.280 So, what does this look like? This gives you reproducibility over time. 06:38.240 --> 06:43.760 It gives you information about, for example, the minimal ISO runtime derivation, 06:43.760 --> 06:49.600 and so specific package sets, information about specific package sets, 06:50.720 --> 06:55.280 details about which exact derivation in those package sets are reproducible or not. 06:56.000 --> 07:05.200 This can also be linked to issues. We have dependency graphs. So, what's next, how can you help? 07:05.200 --> 07:11.200 Become a rebuilder. It's pretty easy. Find us on matrix or find us on reproducibility. 07:11.200 --> 07:16.960 But next west of the arc, fix the actual issues that we find. So, the issues that are 07:18.560 --> 07:24.480 read in the reports, and if you're a developer, then we have a bunch of ideas and I bet you 07:24.480 --> 07:28.560 also have a bunch of ideas to make reproducibility on the next west, even better. 07:30.720 --> 07:31.520 That's it for us.