[00:00.000 --> 00:16.500] Welcome. So to break the flow of presentations a bit, there's now going to be a discussion, [00:16.500 --> 00:23.800] so not just a presentation, but a discussion. But I'm still going to give a short presentation [00:23.800 --> 00:34.280] first to create some context. First, who am I? Okay. I need to speak louder. Okay. No [00:34.280 --> 00:43.600] worries. So I'm an embedded software architect. This discussion is also mostly focused on [00:43.600 --> 00:50.800] the embedded aspects. I'm working on Linux OS integration for as a consultant for dozens [00:50.800 --> 00:59.200] of customers. And I'm also a maintainer of the build route project, which is a team of four [00:59.200 --> 01:08.080] maintainers or five, depending on how you count. And that's actually the context from which I come. [01:08.080 --> 01:16.720] I mean, from which I give this presentation. I don't actually care about S-bombs. It's just [01:16.720 --> 01:25.040] something that needs to be done. And so, yeah, there we go. Because maybe not everybody is [01:25.040 --> 01:30.400] familiar with it. I'll give a quick overview of what an embedded Linux build system is. So [01:30.400 --> 01:37.560] basically, it's taking a lot of sources, some open source sources coming from the internet, [01:37.560 --> 01:45.200] some in-house components coming from various ways that you can get at them. Sometimes these [01:45.200 --> 01:50.320] in-house components are going to be binaries as well. And then the embedded build system takes [01:50.320 --> 01:58.640] all that together with the configuration and produces a number of artifacts. One thing to [01:58.640 --> 02:03.320] note is that the number of artifacts is really small. So we are talking about maybe five files [02:03.320 --> 02:12.080] or something like that. It's not like when you create an operating system that you have all [02:12.080 --> 02:17.400] these files that you need to keep track of. So from my point of view, as a maintainer of such [02:17.400 --> 02:23.360] an embedded Linux build system, the problem is actually quite simple. We know what the inputs [02:23.360 --> 02:29.680] are. We have just a few outputs. And we can just say, okay, these outputs are generated from these [02:29.680 --> 02:38.000] inputs. So that's actually what we do in build routes. We don't have SPDX at the moment. We don't [02:38.000 --> 02:44.360] have anything complicated. We just have a list of packages with the package name in a version, [02:44.360 --> 02:53.400] where it comes from, the source URL. Also, the tarballs themselves and the hashes for checking [02:53.400 --> 03:01.280] the tarball, the patches which are applied to them, the licenses, and the dependencies. So the [03:01.280 --> 03:08.600] build dependencies. So what other packages were used to generate this particular package? And [03:08.600 --> 03:13.600] then the assumption is that all of this together goes into your target image. So there's no [03:13.600 --> 03:20.760] distinction of what is used for what particular output. There's also a list of files for package [03:20.760 --> 03:30.960] which you can kind of use to reconstruct the, to get more fine grains. And then what I think is [03:30.960 --> 03:38.160] the actual thing you want to have is the CVE information. So the two things which I think are [03:38.160 --> 03:45.480] needed are the licenses. And that's part of this top part. And the vulnerabilities, the CVE information. [03:45.480 --> 03:58.080] And so there's a separate tool that extracts that. And it uses CPE IDs to relate our package name [03:58.080 --> 04:04.480] and version to what is in the CVE database. Now when you do this, this is of course not [04:04.480 --> 04:10.040] reproducible because it uses CVE information over a certain time. And new CVEs are created all the [04:10.040 --> 04:22.960] time. So it's something that you have to rerun all the time. So as I said, it's very simple. There's [04:22.960 --> 04:28.080] a lot of things which are missing and where my question is basically, is this something relevant [04:28.080 --> 04:35.200] to work on? So one thing that is missing is external files that you supply yourself. It's [04:35.200 --> 04:42.760] basically all the configuration which I mentioned here, this part. The assumption is that as a [04:42.760 --> 04:50.680] user, you know what these files are. You can inject them yourself. Same with the built root [04:50.680 --> 05:00.400] source. We could make a tarble of the built root source, but we didn't really see the point. Then [05:00.400 --> 05:07.680] we come to more important things, things that's vendor dependencies. So if we are, as bombs are [05:07.680 --> 05:13.240] used for two purposes basically, one purpose is for license information and second purpose is for [05:13.240 --> 05:20.200] vulnerability tracking. Now if you have a vendor dependency in some package, we just see the top [05:20.200 --> 05:28.200] package that vendors it in and not the actual vendor dependency. So we don't have the package [05:28.200 --> 05:33.080] name and version of that. This used to be not much of a problem because not many people were [05:33.080 --> 05:41.680] vending, but now you have go stuff, rust stuff, NPM stuff, which brings in all these dependencies [05:41.680 --> 05:48.880] and they're kind of invisible to us. We also have everything in one file not spread out over [05:48.880 --> 06:01.720] dozens of SPDX files. If it's good, this is bad, I don't know. We don't have a SPDX format. We have [06:01.720 --> 06:07.960] it only at the package level, not at the individual source file level. So our inputs are basically [06:07.960 --> 06:15.000] tarballs, not C files. And as I mentioned before, we don't have mapping of source to target files. [06:15.000 --> 06:22.520] So that brings us to the discussions points. For me, the most important thing to discuss is [06:22.520 --> 06:27.680] what, why are we doing this? So what are the consumers? How is this information going to be [06:27.680 --> 06:37.560] used? Because that kind of determines what should be used as input as well. If you look at, for [06:37.560 --> 06:43.720] instance, the SPDX specification, it doesn't really say whether you have to look at a source file [06:43.720 --> 06:50.680] or you can treat the tarball as a source. It just says, okay, there is a relationship there. It's [06:50.680 --> 07:10.040] not, I'm going to give you the microphone. I'll come up here with you. So it turned around. There [07:10.040 --> 07:18.160] is, sorry, back to the question. You got me confused now. SPDX. Individual source files or [07:18.160 --> 07:27.440] tarballs? Individual source, a tarball is just a file. Exactly. And you can use SPDX at any level. [07:27.440 --> 07:31.520] And so if you just want to look at the packaging level, the package level, and say, hey, it's this [07:31.520 --> 07:37.320] source file, this tarball file, that's fine. That works. You do not need to take it down to the [07:37.320 --> 07:42.960] source file. And it's a minimum set of fields that you just basically, all the concepts you had up [07:42.960 --> 07:46.000] there, you should be able to express right now with what we've got in SPDX today without any [07:46.000 --> 07:51.120] trouble. And so you basically would put a package there with the metadata that you want to keep [07:51.120 --> 07:59.000] at the higher level, and you point maybe to a file that has a hash. Simple enough. Yep. So I see. [07:59.000 --> 08:08.880] Another remark there. [08:08.880 --> 08:14.880] I'm guessing that at some point you would want either a kind of dependency tree, which can [08:14.880 --> 08:20.360] pop up. So you get a full list of more dependencies. And in conjunction with what was said about the [08:20.360 --> 08:26.200] tarball, which contains other files, could this be done in a way that you eventually have in a [08:26.200 --> 08:32.480] flat format, or in a way that can be flattened, all the dependencies at the top level, so you can [08:32.480 --> 08:41.480] parse them as much as you want. So the remark question is, if I understood correctly, so the [08:41.480 --> 08:49.560] next one is basically a hierarchy of dependencies, but you can flatten it to just have input and [08:49.560 --> 08:57.680] output. What I think for an embedded build system, I think it's enough to only have this flat one [08:57.680 --> 09:01.840] without the hierarchy, because the hierarchy is difficult to determine for the embedded build [09:01.840 --> 09:09.400] system. And I don't think it has useful information, unless there is anybody that can say there is [09:09.400 --> 09:24.360] actually useful information in the hierarchy. Yeah, I'm going to try to speak about that a little [09:24.360 --> 09:33.960] bit later. But yeah, there's like a ton of uses for having a structured S-bomb. And if you saw, [09:33.960 --> 09:38.840] for example, the Siemens use case, where they enrich S-bombs, you need to have that structure to [09:38.840 --> 09:45.640] enable to let you know when the enrichment happens, where the extra information is going to be [09:45.640 --> 09:53.600] happening. Also, if you want to compose an S-bomb by taking pieces from another one, like my [09:53.600 --> 10:00.280] friend Ivana here has been doing a really great work on composing S-bombs. So if you want to [10:00.280 --> 10:05.040] compose an S-bomb by taking pieces from one and moving that data to another one, you need to have [10:05.040 --> 10:11.760] that structure. And there are like several use cases that need to, you need, where you need the [10:11.760 --> 10:25.200] structure. But then I wonder what the, I mean, if you compose S-bombs, there is supposedly also a [10:25.200 --> 10:35.480] corresponding composition of the binaries themselves that the S-bombs describe, right? [10:35.480 --> 10:42.080] Because in the end, an S-bomb is a description of a binary. The binaries can be repackaged, [10:42.080 --> 10:46.520] for example. You can have a binary product of a field, and then you seep it, and you ship it, [10:46.520 --> 10:54.240] and so it. So indeed, if you're going to repackage stuff, then this is relevant. I'm surprised [10:54.240 --> 11:11.480] that our use cases were repackaging stuff. So, yeah, there's a question from, from the chat. [11:11.480 --> 11:18.560] What about handling patches? Good question. So what we currently have in Biltrooth is just patches [11:18.560 --> 11:24.480] are one of the sources, and they're, they're described as one of the sources, or, well, [11:24.480 --> 11:29.720] they're included in the, in the tree as one of the sources. Is there anything else to say [11:29.720 --> 11:34.520] about patches? There's also a specific relationship for patches. Yeah, there's a, in SPDX, there's a [11:34.520 --> 11:40.160] specific relationship for patches, because it's a modification rather than an actual source. [11:40.160 --> 11:48.040] What about naming? Yeah, so is it, I think there was one more remark about patches. [11:48.040 --> 11:57.800] Yes, I was the one in the chat. The thing is, if you have a curl, and you have a curl that you [11:57.800 --> 12:03.280] have patches for, it's not the same curl. There could be other vulnerabilities in your distribution [12:03.280 --> 12:10.400] than the original one from Github, or another one from VST. Yeah, so indeed, it's essential that you [12:10.400 --> 12:19.240] track patches rather than, I mean, you have to, to, you definitely have to record that what you [12:19.240 --> 12:25.400] are using is not curl version X, but curl version X plus patches, and then also which those patches are. [12:25.400 --> 12:40.400] Which takes us to the naming problem. Yeah, so if you've got a naming problem, you say OpenSSL, is it OpenSSL? [12:40.400 --> 12:51.400] It's the OpenSSL. It's the OpenSSL, or is it OpenSSL wrapper, and is it OpenSSL someone's patched, [12:51.400 --> 12:57.400] or modified, or built in a particular way because you've got so many options, and we, yes. [12:57.400 --> 13:07.400] So the remark was, if you say this is OpenSSL, or even OpenSSL version X, that doesn't necessarily uniquely [13:07.400 --> 13:13.400] be identified because it can be patched, or it can be built with certain options, so that information [13:13.400 --> 13:18.400] about how it's patched and how it's built has to be recorded as well. [13:18.400 --> 13:21.400] So do you capture that as part of build route now? [13:21.400 --> 13:31.400] Well, so implicitly, yes, but not explicitly. So it's captured because we have the baseline, which is basically [13:31.400 --> 13:39.400] identified by CPE ID, which is the upstream version, let's say, or well the version as published by the [13:39.400 --> 13:48.400] maintainer of the package, and then the patches are recorded separately. [13:48.400 --> 13:54.400] The configuration, as I mentioned before in build route, we don't really record, that's up to the user themselves [13:54.400 --> 14:02.400] to record it, so it's, I mean, that's definitely a room for improvement there. [14:02.400 --> 14:11.400] Yeah, there's a problem with anything that's building from source in this way, is that the name and version are unique. [14:11.400 --> 14:13.400] This is why we have to attach this. [14:13.400 --> 14:14.400] Right, yeah, exactly. [14:14.400 --> 14:15.400] This is why, recently we have hashed. [14:15.400 --> 14:19.400] Yeah, you have to check the hash, and that's why you need to build information, because just because it says [14:19.400 --> 14:28.400] OpenSSL 1.1.2 doesn't mean that the place your security vulnerability was actually even compiled into the code, right? [14:28.400 --> 14:34.400] Yeah, so the remark was that, what was the remark? [14:34.400 --> 14:37.400] The package inversion information when you're talking about. [14:37.400 --> 14:42.400] Yeah, package inversion information is not enough, are not unique, yeah. [14:42.400 --> 14:46.400] So like it's not going to be the same, like it might not even be the same between two people that built the same thing. [14:46.400 --> 14:48.400] Yeah, because of configuration. [14:48.400 --> 14:51.400] Yeah, so. [14:51.400 --> 14:53.400] And the solution for that is hashing. [14:53.400 --> 14:55.400] Yeah, you can hash the outputs. [14:55.400 --> 15:01.400] Hash the outputs, yeah, but then the thing is simply hashing the outputs. [15:01.400 --> 15:07.400] Okay, then you have an identifier of something, but okay, you have, you actually have the output. [15:07.400 --> 15:10.400] You could hash that, but they don't give you any information. [15:10.400 --> 15:12.400] Right, that's what you need to build. [15:12.400 --> 15:16.400] You need actually to build information itself. [15:16.400 --> 15:24.400] We're also, even there, the usefulness is a bit limited because in the end it goes to the CVE database and in CVE database, [15:24.400 --> 15:26.400] you don't have this information anyway. [15:26.400 --> 15:33.400] You don't have it in a, well, you may sometimes have it in an informal way in the description, [15:33.400 --> 15:42.400] but you definitely don't have it in a formal way saying if configured X then, so unless there is also some changes there, [15:42.400 --> 15:49.400] I don't think there's much use to, I mean, it's important to record it for manual analysis, [15:49.400 --> 15:59.400] but since there is on the other side no formal recording of it, I'm not sure if it makes sense to record it formally. [15:59.400 --> 16:08.400] So what we do for the CVEs is we don't, we only put in the, we put the CVE in and then just once, which ones we've patched. [16:08.400 --> 16:14.400] So like, that way if you go look it up, you know, I don't need to worry about this one, but if there's any new ones. [16:14.400 --> 16:20.400] Yeah, that's basically what is done in built-in as well, but not in an SPDX format, just... [16:20.400 --> 16:27.400] The CVE ID is a field external reference you can associate with the package. [16:27.400 --> 16:30.400] Yeah, so the remark is in SPDX, yeah. [16:30.400 --> 16:35.400] In SPDX is the external references and you can associate a CVE with a specific package. [16:35.400 --> 16:41.400] You can also associate a Perl with that same package and if you wanted to put both of them there, you could. [16:41.400 --> 16:48.400] It's flexible there and because of the time scales of vulnerabilities and so forth, [16:48.400 --> 16:52.400] what you want to record at a point in time whether something's patched or not or other things like that, [16:52.400 --> 16:55.400] this is all hopefully able to be done. [16:55.400 --> 17:02.400] The question is, you know, are people having tools that are semantically accessing it right now? [17:02.400 --> 17:09.400] Yeah, well, so one of the things about the consumer's tools is actually we are seeing tools emerge. [17:09.400 --> 17:15.400] In fact, I know of two off the top that are basically consuming S-bombs and matching them to vulnerabilities. [17:15.400 --> 17:19.400] So that takes care of the monitoring over time because there's two different time cycles. [17:19.400 --> 17:24.400] There's what's known at build and then there's what's known in the field over time. [17:24.400 --> 17:33.400] And so the two projects I'm aware of are Daggerboard and the other one is the one that's sitting in the SPDX repo [17:33.400 --> 17:35.400] that looks up vulnerabilities. [17:35.400 --> 17:42.400] You basically feed it in an S-bomb in SPDX and it will go and query the databases for vulnerabilities. [17:42.400 --> 17:44.400] Yeah, SPDX tool. [17:44.400 --> 17:45.400] To OSV. [17:45.400 --> 17:47.400] To OSV, yeah. [17:47.400 --> 17:53.400] And so there are tools out there that are emerging and I think we'll be seeing more and more in the years. [17:53.400 --> 17:57.400] Yeah, maybe as a reaction to that. [17:57.400 --> 18:04.400] So my intuitive reaction is, yeah, but we also have a tool that generates this information already. [18:04.400 --> 18:10.400] I mean, as part of build routes, you can just run that tool again five years later and you get that information. [18:10.400 --> 18:19.400] But there's a cave-out where I think it's actually useful to have the built information formally recorded [18:19.400 --> 18:23.400] and that's basically the same thing as what archaeologists do. [18:23.400 --> 18:29.400] You don't know what techniques are going to emerge later and that can be useful then. [18:29.400 --> 18:37.400] So if you build something now, you should record all the information now that can be recorded. [18:37.400 --> 18:43.400] The other little add to that is that use case is also very important in the high assurance world [18:43.400 --> 18:48.400] where you are being asked to attest exactly which vulnerabilities you know about. [18:48.400 --> 18:56.400] But that's an audit case or a high assurance case and so some places they will want to have that. [18:56.400 --> 19:02.400] Okay, I would like to move on to a different subject which I mentioned here. [19:02.400 --> 19:08.400] That is vendor dependencies because I think that's a, I mean, from the point of an embedded build system, [19:08.400 --> 19:12.400] that's an important thing to solve. [19:12.400 --> 19:15.400] We actually have multiple vendor dependencies. [19:15.400 --> 19:18.400] I'll first give an intro and then, yeah, multiple vendor dependencies. [19:18.400 --> 19:23.400] So we have some vendor dependencies which are directly included in the source code. [19:23.400 --> 19:27.400] For instance, Tomlip is a good example. [19:27.400 --> 19:34.400] Tomlip is a library that is meant to be vineered in. [19:34.400 --> 19:40.400] And so, yeah, people just copy it into their source code. [19:40.400 --> 19:42.400] So that's really difficult to trace. [19:42.400 --> 19:44.400] Then there is Git submodules. [19:44.400 --> 19:47.400] You clone a Git tree. [19:47.400 --> 19:52.400] That is the information you have in the, as a build system. [19:52.400 --> 19:55.400] That's the information you have in your build metadata. [19:55.400 --> 19:59.400] But then if there are submodules referenced from there, [19:59.400 --> 20:04.400] that information is not part of the metadata of the build system. [20:04.400 --> 20:08.400] And then Cargo will go in PM modules, obviously. [20:08.400 --> 20:13.400] And then there are some cases where the build system itself vendors things in. [20:13.400 --> 20:19.400] For instance, in open embedded, you have the kernel meta which is kind of entered in. [20:19.400 --> 20:25.400] And which is not, I mean, I don't know if it's taken into account for the SPDX. [20:25.400 --> 20:27.400] But you need to take special action there. [20:27.400 --> 20:29.400] That's the important thing. [20:29.400 --> 20:35.400] It's not using the normal parts of taking sources. [20:35.400 --> 20:41.400] So, yeah, my question to the audience is how can we deal with these vendor dependencies? [20:41.400 --> 20:43.400] You had a remark. [20:43.400 --> 20:45.400] A question? [20:45.400 --> 20:46.400] An additional question. [20:46.400 --> 20:48.400] Okay, sorry. [20:48.400 --> 20:50.400] I'm going to keep you. [20:50.400 --> 20:55.400] This is actually just a problem beyond Sbom generation. [20:55.400 --> 20:59.400] Because if you're trying to do air gap builds, these are huge problems in general. [20:59.400 --> 21:01.400] But that we've encountered. [21:01.400 --> 21:08.400] So, you know, ideally we could download all of these sources and archive them without, [21:08.400 --> 21:11.400] and then go tell the tool to go pull them from the archive, [21:11.400 --> 21:14.400] which is often difficult if not impossible. [21:14.400 --> 21:18.400] So, yeah, it'd be nice if the tool like cargo and go. [21:18.400 --> 21:20.400] I think cargo is not too bad. [21:20.400 --> 21:25.400] But go and MPM are pretty bad last we checked for being able to do that kind of thing. [21:25.400 --> 21:29.400] And that would make this a lot simpler too. [21:29.400 --> 21:37.400] Yeah, so the thing that I want to add to that is that, so getting the sources is not the difficult part. [21:37.400 --> 21:39.400] So if it's just for licensing, that's doable. [21:39.400 --> 21:43.400] But for supply chain, you want to know provenance. [21:43.400 --> 21:45.400] And that's the hard part. [21:45.400 --> 21:51.400] There is, unless the, I think for all these things, [21:51.400 --> 21:57.400] unless the source, the upstream itself gives some provenance information, [21:57.400 --> 22:00.400] preferably in a formal format, [22:00.400 --> 22:07.400] then there is no, it's really hard for us as a build system to go and look for it. [22:07.400 --> 22:11.400] For cargo and go, it's actually doable to do it on our side, [22:11.400 --> 22:15.400] because it's, you have a log file which gives the exact information, [22:15.400 --> 22:19.400] not in an easily consumable format, but the information is there. [22:25.400 --> 22:30.400] For MPM, it's, yeah, of course it's MPM. [22:30.400 --> 22:41.400] And GITSIP modules also, the information is there, but you don't have version numbers. [22:41.400 --> 22:47.400] You have GIT hashes which are not something that you will be able to check against the CVE database. [22:47.400 --> 22:52.400] And to some extent, that's also the case for cargo and go versions, [22:52.400 --> 22:57.400] because often they're also, they're specified by GIT hash. [22:57.400 --> 23:01.400] And then they're directly included in sources as usual, hopeless. [23:01.400 --> 23:05.400] Any other? [23:05.400 --> 23:07.400] Well, it's just some perspective. [23:07.400 --> 23:09.400] So one thing to keep in mind about those is, [23:09.400 --> 23:13.400] there are those dependencies that get rendered in, [23:13.400 --> 23:15.400] and you need to capture those in the S-Bomb. [23:15.400 --> 23:17.400] You can see them in two ways. [23:17.400 --> 23:21.400] One is from the dependency list angle, [23:21.400 --> 23:27.400] and in that case, just having the version and then name, [23:27.400 --> 23:32.400] and ideally the hashes of those dependencies is enough. [23:32.400 --> 23:37.400] And the other angle is if you're trying to actually inventory all of the files that get rendered in. [23:37.400 --> 23:40.400] So it depends on the use case of the S-Bomb. [23:40.400 --> 23:43.400] You may want to capture one or the other or both. [23:43.400 --> 23:50.400] But the, so just for dependency's sake, it may be, depending on the build system, of course, [23:50.400 --> 23:57.400] it may be the case that you only need the list of dependencies without the actual file information. [23:57.400 --> 24:00.400] Yeah, the thing is the file information is easy to get, [24:00.400 --> 24:06.400] it's the list of dependencies which they record. [24:06.400 --> 24:09.400] I think picking on what Adolfo just said is, [24:09.400 --> 24:15.400] a lot of builds dependencies just say latest, or not explicit. [24:15.400 --> 24:19.400] On the view that people say, I want to keep up to date patch-wise, [24:19.400 --> 24:22.400] because we're told we've got to keep everything patched, [24:22.400 --> 24:27.400] but for making it dependable, it's the worst thing because it's going to change. [24:27.400 --> 24:32.400] So, yeah, I was trying to just get a debate, [24:32.400 --> 24:35.400] but actually that's, I think, is a lot of the things, [24:35.400 --> 24:39.400] and people are generally lazy, I'll just pull in open SSL. [24:39.400 --> 24:42.400] I don't care what version, I'll just pick up the later, [24:42.400 --> 24:46.400] because it'll be version X today, it'll be version Y next week, [24:46.400 --> 24:50.400] and I'm not bothered about that, I don't want to have an admin. [24:50.400 --> 24:54.400] So, how do we handle that? [24:54.400 --> 24:56.400] Because with the growth of ecosystems, [24:56.400 --> 25:04.400] that basically is what people find very convenient. [25:04.400 --> 25:06.400] Yeah, so I don't think we have an answer to that. [25:06.400 --> 25:11.400] I think we can get one last question, the question you had, [25:11.400 --> 25:14.400] and then we have to stop, I think. [25:14.400 --> 25:17.400] And the question would be, how would you handle [25:17.400 --> 25:20.400] vendor dependencies that come as binaries? [25:20.400 --> 25:22.400] Yeah, the question is, how do you handle [25:22.400 --> 25:26.400] vendor dependencies that come as binaries? [25:26.400 --> 25:33.400] I guess you record what you know, that's the perfect answer. [25:33.400 --> 25:36.400] Actually, this is probably the answer in general, [25:36.400 --> 25:39.400] to any question you record what you know. [25:39.400 --> 25:45.400] Actually, you want to record it in as formal way as possible, [25:45.400 --> 25:48.400] because like for this cargo, go dependencies, [25:48.400 --> 25:51.400] actually our source store has the log file, [25:51.400 --> 25:53.400] which has the exact information of the dependencies, [25:53.400 --> 25:58.400] it's just not something that you want to go and crawl through afterwards [25:58.400 --> 26:01.400] to reconstruct it. [26:01.400 --> 26:09.400] Would it be doable to have two phases, first download the sources, [26:09.400 --> 26:13.400] then you are in a container, you cut the internet, [26:13.400 --> 26:18.400] you stop the interfaces, and you build. [26:18.400 --> 26:23.400] So there's more remark to the offline build thing. [26:23.400 --> 26:26.400] So to solve the offline build problem, [26:26.400 --> 26:29.400] what you can do is cut the build in two phases. [26:29.400 --> 26:31.400] The first phase, where you just do downloads, [26:31.400 --> 26:33.400] and then you have a download territory, [26:33.400 --> 26:35.400] which you expose to the second phase, [26:35.400 --> 26:38.400] where you do the actual processing. [26:38.400 --> 26:41.400] And there are two problems with that, [26:41.400 --> 26:45.400] which I don't think are solved in either Yocto or Biltroot. [26:45.400 --> 26:48.400] The first one is that you actually, to do the downloads, [26:48.400 --> 26:51.400] you need some tools which you have to build. [26:51.400 --> 26:53.400] You need to do the cargo downloads, [26:53.400 --> 26:57.400] you have to build cargo first. [26:57.400 --> 27:02.400] Yeah, but that means that you don't completely separate your build, [27:02.400 --> 27:05.400] you can't completely separate your build in your downloads step, [27:05.400 --> 27:09.400] because you need to build something to download something. [27:09.400 --> 27:15.400] And the second issue, I forgot what the second issue was. [27:15.400 --> 27:21.400] Yeah, the built hermetic builds should be available for everybody. [27:21.400 --> 27:23.400] But we need the tools to support it. [27:23.400 --> 27:27.400] People don't realize that you need your tools to support that. [27:27.400 --> 27:33.400] Yeah, so you can maybe do something like a download step, [27:33.400 --> 27:35.400] a build step, a download step, a build step, [27:35.400 --> 27:36.400] but it's getting complicated. [27:36.400 --> 27:37.400] We're out of time. [27:37.400 --> 27:53.400] Thank you.