WEBVTT 00:00.000 --> 00:10.400 All right, packed room. People are excited by S-bombs. That's good. We're getting there. 00:10.400 --> 00:17.880 Let me as pre-fix this entire conversation with I am Neuloyer. Speak to you earlier. We're 00:17.880 --> 00:25.440 going to talk about CRI, so there is legal implications. I'm wasn't going to say before I 00:25.440 --> 00:32.200 David's Dr. Talk. I'm going to do what the talk is not about. This is not a complete 00:32.200 --> 00:36.960 CRA compliance guide. That's a lot more complicated than you could post to squeeze into 00:36.960 --> 00:42.800 30 minutes. The second thing is, this is not going to be a theoretical exercise. I think 00:42.800 --> 00:47.440 a lot of talks and it's good that we talk about a theoretical thing. What can be done 00:47.440 --> 00:51.880 and cannot be done. But this talk is not about that. This is actual action of all what 00:51.960 --> 00:59.480 you can do today using existing tools. It's not about achieving perfection. It's achieving 00:59.480 --> 01:05.320 something from nothing. I think that's an important distinction. We don't try to overwhelm 01:05.320 --> 01:11.480 users coming into this thinking about CRI or trying to be a CRA compliance. A lot of talks 01:11.480 --> 01:18.440 have been about perfection achieving everything. This is not for that audience. This is for 01:18.600 --> 01:25.720 99% of all the users out there that are going to be compliant or need to be compliant 01:25.720 --> 01:32.200 with CRA. This is for them. We like to talk about S-bombs and intricate deeds of S-bombs. 01:32.200 --> 01:36.040 And that's great. We need to have those conversations. That's perfect. That's what a lot of 01:36.040 --> 01:41.640 us in this room are really excited about. But let's be real. The vast majority of customers 01:41.640 --> 01:46.440 or people that need to be compliant with CRA, they don't care. They have this is need 01:46.440 --> 01:52.360 and they absorb it. That's what this talk is about. Zero to something. What we look at the 01:52.360 --> 02:00.760 areas, what's that easy button? How do you go from nothing to something that is getting in 02:00.760 --> 02:08.360 the right direction? We get assume that the vast majority of these users don't care about S-bombs. 02:08.360 --> 02:14.040 They don't care about the intricate details about the various details in S-bombs. We might 02:14.040 --> 02:18.520 find super exciting and super interesting if we're attacking the exercise. But the reality is, 02:18.520 --> 02:24.680 most users will not care about that. And like Anthony spoke this morning, it's really good about 02:24.680 --> 02:30.520 diving into the exact perfect, perfect, perfect run by S-bombs. That's great. We need that too. 02:30.520 --> 02:35.800 But let's not lose track of that. The vast majority of users just want this tick box. 02:35.800 --> 02:44.120 I'm going to paraphrase S-bombs who was born on the CRA Technical Committee. When you talk 02:44.120 --> 02:52.520 what I talked to her about S-bombs, her point was, it's about showing effort. It's not about 02:52.520 --> 02:57.960 perfect. I think that's an important sentiment going into this. We don't need the perfect 02:57.960 --> 03:03.000 S-bombs, the capitalist, everything. It would be fantastic if we could get it up. We shouldn't 03:03.080 --> 03:08.840 lose track of trying to get that. But we need to go from zero to something. I think that's 03:08.840 --> 03:15.080 really thing. So I'm fully cognizant that this is the board proof and there are a lot of variables 03:15.080 --> 03:22.600 in there that are complicated. But let's just focus on getting you something from nothing. 03:23.960 --> 03:31.000 Now we talk about CRA, reading legislation, that's a bit theoretical. The most practical 03:31.000 --> 03:38.280 implementation of or interpretation of the CRA is to be a side. They publish the documentation 03:38.280 --> 03:44.440 there's now the 2.1, which is relatively recently. It talks about what they expect from 03:44.440 --> 03:50.280 S-bombs. I'm sure you can barely read this if you can. But a lot of this is simple. It talks 03:50.280 --> 03:56.680 about it's your machine readable. It's your using certain formats. It should be using what 03:56.760 --> 04:01.240 else that they have in there. It depends on the graphs of all those things. But they're one 04:01.240 --> 04:08.200 thing that is somewhat problematic. One of the things they say is you should have sure 5 or 2 04:08.200 --> 04:15.880 hashes or your components. Well, no package voucher out there to my knowledge. It does that. 04:17.480 --> 04:25.240 Maybe something. But it's very, very rare. You still see MD5s, right? So yeah, you have any comments? 04:27.160 --> 04:37.880 Okay. So there's maybe one, but I would say that it's a very much an edge case, right? 04:37.880 --> 04:41.640 The vast mirrors will not do that. That's what you're going to have hashes if you look at 04:41.640 --> 04:52.120 the lock files, right? So most of this stuff is not crazy complicated. But this is the exact 04:52.200 --> 04:57.720 definition they have. Again, this is probably not readable. But this is kind of a way in 04:57.720 --> 05:02.600 me for, right? We aim for like a depends on the graph. Good port S-bombs, really, right? So 05:04.200 --> 05:10.280 how did I even get into this? So two years ago, I was in a company who was doing 05:10.280 --> 05:14.680 security design, security design, managed S-bombs, so we can't get into this curve. 05:15.320 --> 05:19.720 Me going into this assume that S-bombs generation was going to solve problem two years ago. 05:20.680 --> 05:26.520 Well, turns out it really wasn't. You can generate an S-bombs really easily. That's not hard. 05:26.520 --> 05:31.640 The plenty of tools out there with General S-bombs generate high-quality S-bombs that meets 05:31.640 --> 05:39.560 entire minimum elements back then is a lot more difficult. So I did something about that. I joined 05:39.560 --> 05:47.400 S-is working group and we create this group about S-bombs generation. And we worked for six or eight 05:47.800 --> 05:53.320 months on developing a blueprint for how you generate high-quality S-bombs. So we came up with 05:53.320 --> 05:59.880 this blueprint, which is a four-step process for how you bake a good port S-bombs. And the first 05:59.880 --> 06:03.960 one is creation, so there are plenty of tools out there to do creation, usually from the 06:03.960 --> 06:09.720 lock far, but it can be food, Docker, imagery, etc. But that part is kind of the most solved problem 06:09.720 --> 06:17.080 generating S-bombs, right? The plenty of tools out there. The next part, we call the augmentation 06:17.720 --> 06:22.120 phase. And the augmentation phase where you take that S-bombs that you generated. But you 06:22.120 --> 06:27.240 ejected it then with relevant information that you as a company would only have. What's the 06:27.240 --> 06:32.920 life cycle this? Who are you as a company? What's the supplier? All these things that anti-minimelments 06:32.920 --> 06:38.600 require. That essentially none of the S-bombs generators will actually do for you because they 06:38.600 --> 06:42.840 don't have the information simply. The information is not your lock far, therefore they can't do it. 06:42.840 --> 06:48.760 The next phase we did then was the enrichment. That's when you look at S-bombs and the core of the 06:48.760 --> 06:53.320 core of the S-bombs directly correlates to the core of the lock far, which is that's usually 06:53.320 --> 06:58.680 a source here. So then you take the lock far, and then you try to take that information and 06:58.680 --> 07:04.440 make it better by enriching it using ecosystem data. Back then, we were using parlay from 07:04.440 --> 07:10.280 the sneak. That was kind of the best tool by the time. Which in turn is really if the thin layer 07:10.280 --> 07:15.240 in front of ecosystem.ms. So it takes that data and enrich it and tries to produce a better 07:15.240 --> 07:22.440 port S-bombs and then the last phase is designing. So like this runs your CI, you should 07:22.440 --> 07:29.720 sign it to your CI and that's your sort of truth. So those were the building blocks that would 07:29.720 --> 07:36.440 be designed. And when we did this work, it was kind of hack-ish. A lot of it was like you 07:36.440 --> 07:42.120 had to parse your S-bombs using JQ and inject data and it was really, really like hack-ish. 07:43.640 --> 07:51.080 So why do I bring this up in a CRA discussion? Well, if you're looking at the CRA and you 07:51.080 --> 07:57.000 look at the NTA or a system now in a moment, it kind of shift the Venn diagram. They asked for 07:57.000 --> 08:02.600 slightly different things, but there's a lot of overlap, right? But if they can generate a good 08:02.600 --> 08:08.840 port S-bombs, we can kind of knock both out in the same gap. But again, the constraint is, 08:09.560 --> 08:13.960 we need to make this easy for users because we have to assume that users, they do not care 08:13.960 --> 08:18.840 about intricate details of the various formats. They just want something like, they can solve the 08:18.840 --> 08:22.200 problem. They're a business problem. They were solved for it and therefore then they want to move on, 08:22.200 --> 08:29.000 right? So we're aiming for solving both these problems in one gap. So pretty ball, I would say. 08:29.960 --> 08:37.480 And then I think to make it with no complicated, Martha's sort of, because morning can't 08:37.480 --> 08:44.200 outline this, right? S-bombs are not one thing. S-bombs are complicated, because the real 08:44.200 --> 08:49.400 world is complicated. Yes, in a small open-source project, it's kind of simple because your 08:49.400 --> 08:54.920 scope is kind of narrow. The real world is a lot more complicated than that. You have, you're 08:54.920 --> 09:00.520 smart thermostat, has maybe like a back-in component, it has a firmware, it gets complicated 09:00.520 --> 09:05.960 so you need to release like a management for all of that. And we need to remind of that when we 09:05.960 --> 09:11.160 talk about this debate as far as when does end of life and all that stuff affect, because these 09:11.160 --> 09:15.720 components are probably shared across other products, which makes it even more complicated. Right? 09:16.280 --> 09:20.600 And then I'm going to add one more constraint, which is, we're going to do all of this in CI. 09:21.400 --> 09:29.000 And that's really, really important, because if you got trust S-bombs for like legal reasons, 09:29.000 --> 09:33.800 you need to have a station back to S, but to CI pipeline, so you get your trust what's going 09:33.800 --> 09:43.000 in there. Right? So here's desperation. Can we, with five lines? Well, I guess seven. 09:43.800 --> 09:50.440 Lines of YAML, saw this problem. That's the thesis. Can we do this? Because it's actually 09:50.520 --> 09:57.000 not trivial. And when we come up with this, it's probably called Spomive Action. And it's 09:57.000 --> 10:02.840 open source, and I would say it's more glue than tool. Yes, there's some tooling in there, 10:02.840 --> 10:09.160 but it's more glue. And it's opinionated tool that is format agnostic. And we try to be full agnostic, 10:09.160 --> 10:13.880 so that use can build whether I need to build. Right? So essentially, we try to build a unicorn here. 10:13.880 --> 10:20.280 Right? It's not, it's, we try to take away all the complicated stuff from the user and just 10:20.440 --> 10:25.640 do it for them. Right? So what does that look like? So in the generation face, 10:26.920 --> 10:31.000 we have the usual suspects. All right? So we pack a job, actually, 10:31.640 --> 10:38.360 safe, see the x-gen, all these tools we have out there, and we cut Packers them into one container, 10:39.320 --> 10:46.680 so that when the user presents an unlock file, which is often time is, we pick the best tool for the job. 10:47.400 --> 10:54.600 Right? So from a core to perspective, the native tools, such as cycling the x-pipe of the 10:54.600 --> 11:00.040 library, tend to generate a lot better S-bombs or high-court S-bombs than to say the generic tools 11:00.040 --> 11:04.520 like Sift. So we pick that. So it's an opinionated piece of software that we make the decisions 11:04.520 --> 11:09.960 on the off the user to optimize for the best core of the output. And this is an ongoing thing. 11:09.960 --> 11:15.160 If we find tools to score better and do better S-bombs, we can just default about. It's, it's 11:15.160 --> 11:21.160 a volume evolution really, right? And a bit nudged to the S-bodex community, the 11:21.160 --> 11:27.560 cyclone tools are a lot better. So there are very few S-bodex tools out there for actually 11:27.560 --> 11:33.080 generating S-bombs from lock files, where the cyclone has a lot of tools for that. 11:33.640 --> 11:39.240 For S-bodex, tend to have to go for the generic tools. So just, that'll be good to see more tools for that. 11:39.720 --> 11:47.000 All right, so the next phase, the next phase is enrichment. So we start out using just parlay. 11:47.000 --> 11:51.400 That's what we started with. It's just a working group. We use parlay. Quickly realize that 11:51.400 --> 11:57.800 ecosystem is really good, but we can do better. So now we have native integrations with 11:58.600 --> 12:05.640 crates, darts, rapporty, clear define. We basically try to do the best integrations we can to 12:05.640 --> 12:11.000 pry the best output as possible, which usually means going directly to a database as originally. 12:11.000 --> 12:15.800 We also have added some stuff like native integration for licensees. We parse all like a 12:15.800 --> 12:20.920 dabbing and Python and few other distros licensees so we can kind of do license parsing 12:20.920 --> 12:25.880 of that, so the bills are called license DB, and then we do life cycle database as well. So 12:25.880 --> 12:30.920 a major framework and upper insistence, we can enrich this automatically to give the user a really 12:30.920 --> 12:38.520 good high quality. S-bomb, rather than even know what's going on. Show, don't tell. Let's see how 12:38.520 --> 12:46.920 this actually goes. So in order to start, we need to gather information that we caught in fair. 12:47.880 --> 12:54.600 So we've prayed this little tool that in this example, we're using a Python log file as the 12:54.600 --> 13:01.640 PyProtiq file, right? So we're using UV and PyProtiq as a sample example, but we're not in the 13:01.640 --> 13:07.320 gather information that we can't actually infer at all. So we're written this all tool. Let's 13:07.320 --> 13:12.200 spot the Sponeman Faction module, which is available as a Docker image, or as a Python package, 13:12.920 --> 13:17.480 or Docker image is usually the best way, because then you can get what's with package. 13:17.480 --> 13:21.800 But we need to fill our information like, who's the supplier? What's the supplier you're 13:22.280 --> 13:27.000 out? So this is kind of anti-menom element things that we need to get in there. Again, we 13:27.000 --> 13:31.000 aim for the Vendai program to cover both, right? Conflict information, component emails, 13:32.680 --> 13:37.480 this fills you out, then you need to fill out the manufacturer, another requirement, 13:38.520 --> 13:44.840 oftentimes the manufacturer is the same as the supplier, but not always. So we need to consider 13:44.920 --> 13:51.560 both environment, right? So then we need to add the manufacturer, and then, oops, got some 13:51.560 --> 14:00.760 type as in there, sorry. Yeah, you get an idea, though. So we now fill out the organization, 14:00.760 --> 14:04.280 now we fill out, now we need to fill out the author, which is another example of some of the 14:04.280 --> 14:10.360 required anti-menom element framework, right? So we're filling out the author, and then now we 14:10.360 --> 14:14.280 need to add license information, sometimes you can further that, some of those you can not, right? 14:14.280 --> 14:19.320 So let's ask. So in this case, we used to have a drop down, so you use to like, it's a patchy to cool. 14:19.320 --> 14:24.680 Let's take that in. Now we need to inform about security. This is something that's CRA requires. 14:24.680 --> 14:30.680 How do you contact the vendor about security issue? Well, in this example, we is going to use a 14:30.680 --> 14:35.480 requirement of security or texty file. We take that data that we ask to use a kennel to be person. 14:36.440 --> 14:41.320 To your point down to me about build cycles, here we ask the people about the build cycle, 14:41.320 --> 14:47.320 you also ask about life cycle phases, sorry, life cycle phase rules, but release dates, and all those things, 14:47.320 --> 14:52.600 when is the whole thing in the life, right? These are things we can't infer at all. We need 14:52.600 --> 14:56.440 to ask to use about these things because you can't figure it out, like there's literally no 14:56.440 --> 15:03.560 way to automatically figure this out, right? So now we've done, we take all the data, 15:03.640 --> 15:10.440 we stack the JSON file, call this one file JSON. Now, we've done use this information 15:10.440 --> 15:15.400 in the further build steps, and you can either commit this file to your repo. You can also use 15:15.400 --> 15:19.320 our API, you can build that there, so you can have the same thing that shared across multiple 15:19.320 --> 15:23.480 projects, but for the sake of this demo, I'm going to use it in the JSON file, right? 15:24.280 --> 15:31.960 So again, we had a basic Python package, we used a spun of action module to build this JSON file 15:32.040 --> 15:36.440 by just looking through a wizard, and then we had a life cycle data and so forth, right? 15:37.480 --> 15:45.080 Great, so far so good, now we've added the generation. So, in the generation, let me see the 15:45.080 --> 15:50.360 Python example here, right? I have the Python library installed, I'm running it, and I'm just 15:50.360 --> 15:54.120 pointing to the left file, and you can see a bunch of information here, right? So not only did 15:54.120 --> 15:58.680 run the tool, we all just started doing other things, so what we realized when we started doing this, 15:58.680 --> 16:05.880 that most of the generators will not write hatches to your smart. Now that's a requirement, 16:05.880 --> 16:12.760 right? So we need to have hatches. So we take that, we enrich it with hatches, because we have to 16:12.760 --> 16:17.160 assume that we don't know, in this phase, we don't know how it was generated, right? Because we 16:17.160 --> 16:22.520 use multiple tools, we can't make assumptions about that, so we need to validate. So if using 16:22.520 --> 16:26.520 sifter-trivial, you may not have all the information that a native tool would give you, right? 16:26.520 --> 16:33.160 So we make, we make some assumptions there, we chuck the data in there, and I'm not sure you're 16:33.160 --> 16:39.080 still about the very end, but I used, just to be independent, I used smqs to be scoring that 16:39.640 --> 16:45.000 s-mo. So we've got a score of 6.3, okay, not terrible, but we're not done yet, right? 16:46.920 --> 16:54.040 Now augmentation. Remember that JSON file we created? This is where that comes into play. So it takes 16:54.520 --> 16:59.000 the s-spawn that we generated in step one, and just for clarity. In the real world, 16:59.000 --> 17:03.400 you wouldn't use smqss, you would do all in one go, right? It would take the entire all three steps 17:03.400 --> 17:09.080 that we have here, and do them in one go. But just for illustrative purposes, I broke in them up to 17:09.080 --> 17:15.000 really show what each phase does, right? So as you can see here, it adds a bunch of data, like, 17:15.000 --> 17:21.320 for instance, we know the author, we supply a real life cycle, and we know all this information 17:21.320 --> 17:28.200 now, because we built s-pum with that tool, right? So augmentation, rather that, right? All the 17:28.200 --> 17:33.000 data we have from the wizard. This would get interesting. This is the enrichment part. This is where 17:33.000 --> 17:40.280 the interesting data happens, right? So we can now look at that s-pum, and let me go in the 17:40.280 --> 17:47.640 ecosystem and look to fill in all the blanks that are missing, right? So we are, in this example, 17:47.720 --> 17:54.440 operating the Python work as the Django package. So we are now looking at Python. What they 17:54.440 --> 18:01.800 does is Python, right? So we pull in all the Python data, we are pulling in life cycle data from 18:01.800 --> 18:05.640 our database, so we know it's Django, we know the version of Django. Well, because we know the 18:05.640 --> 18:10.840 version of Django, we also know in that version of Django we see well. So we have a life cycle 18:10.840 --> 18:17.080 database, we just chucked it in there. So that when you inspect the s-pum, you can see exactly 18:17.080 --> 18:22.040 when this particular component is end of life. The same goes for an off-brain system, and for 18:22.040 --> 18:27.720 a lot of various packages that we have. So you can see from the audit trail here is doing a lot of 18:27.720 --> 18:34.040 things. It also adds description, homepage, all these things that CRA requires you to have, 18:34.040 --> 18:39.800 what all your packages, it kind of fetches that from Python is example. We then do some other 18:39.800 --> 18:45.400 nice things like we normalize the data and so forth. And then, one interesting thing we discovered 18:45.400 --> 18:49.400 and we saw looking at the data scale was there's a lot of normalization needs to happen because 18:49.400 --> 18:56.600 you pull in data from across ecosystems and various data sources, things like URL structures 18:56.600 --> 19:00.760 are very inconsistent, right? Because we try to populate things like where the source code from 19:00.760 --> 19:06.440 this package form, that is all parsed and normalized. And then we clean up all the pearls and 19:06.440 --> 19:12.440 all that stuff to make it really good for this one. So this is essentially what we did in this 19:12.440 --> 19:19.160 fix, right? And again, bear in mind, several lines of the animal in your Docker hub, in your Docker, 19:19.160 --> 19:25.080 sorry, in your GitHub action pipeline. So this does not require you to be an export S-bomb, 19:25.080 --> 19:35.320 which generates a high-port S-bomb, right? So when from 6.2 to 8.5, which I think is a pretty good jump 19:35.320 --> 19:41.160 into terms of completeness. And if you're going to compare that to what actually CRA requires, 19:41.720 --> 19:48.040 we've ticked most of the boxes here. We haven't ticked the Shaw 512 box because Python doesn't 19:48.040 --> 19:53.080 do that or UV doesn't do that. So unless we're going to go re-back and re-calculate those hatches, 19:53.080 --> 19:57.800 we can't quite do that. But again, we can't want to raise the bar and we want to do 19:58.840 --> 20:05.960 one of the show effort. The goal is not perfect. The goal is zero to high-quality with minimum 20:05.960 --> 20:11.880 left work. So they work. Well, this is the output from S-bomb QS. If you're scoring the input 20:11.880 --> 20:19.960 with the output here, and I'd say we've done pretty well, given that again, set the lines of 20:19.960 --> 20:26.840 the animal in your GitHub action pipeline or rather pipeline using, we have built essentially 20:26.840 --> 20:35.160 high-port S-bomb from a loop file and I think the reality is that's what 99% of the users 20:35.160 --> 20:45.400 out there will be looking for when they need to look into CRA. So I hope that's helpful and that's 20:45.400 --> 20:50.520 essentially my talk. I'm very happy to take it a question. If you go army, that's the link to the, 20:50.520 --> 20:55.720 well, I'll put a link to the talk later, but that's the GitHub action module on GitHub. And yeah, 20:55.720 --> 21:01.880 now questions. First of all, hey, so you talk about the manual, the movement of data like 21:01.880 --> 21:07.240 manufacturers, if you're concerned with it, that is part of the context of this, the programming 21:07.240 --> 21:13.400 content. They have no idea on what's the idea of what the JSON UI looks like, of course they're 21:13.400 --> 21:19.000 in there. My engineers know that, not those things are, but they don't know what they're 21:19.160 --> 21:26.040 talking about. So you're talking about commercial projects, more than open source projects. 21:26.040 --> 21:33.080 So the question is, when you do all this stuff and not so much for open source, but when you're 21:33.080 --> 21:37.960 talking about commercial items, I think that's a lies in unsolved problems, right? Now how you 21:39.000 --> 21:43.800 the format's supported, both cyclone and in aspects they support it, right? But I think it's large, 21:43.800 --> 21:47.800 like, I haven't seen any large-scale implementation that, I'm sure other people have, 21:47.800 --> 21:51.400 but I haven't actually seen that because most of the things I've been exposed to has been 21:51.400 --> 21:56.440 commercial project built on top of open source, and that's kind of like what's in scope there. 21:56.440 --> 22:00.440 I'm sure other people have, but I don't have a good opinion about that, if I'm being honest, 22:00.440 --> 22:05.960 I know it can be done, but I haven't seen much about around that. Yes, question back. 22:13.800 --> 22:19.000 Would your output into that format more like open authentication or not? 22:19.000 --> 22:25.240 So S1QS does BSI 2.0? Typical one I haven't seen anyone yet, because I was relatively 22:25.240 --> 22:30.920 recent report. We are probably going to write one. So we have automated checks on our 22:30.920 --> 22:35.880 back end. So when you push that to this one of our platform, which is also available, you can 22:35.880 --> 22:41.560 run yourself and self-asself as then you can then be write plugins to check that. So the idea is to 22:41.560 --> 22:46.600 have a plugin for BSI 2, but one, where you do that, not being in say thumbs up, you 22:46.600 --> 22:51.400 pass all the checks, but you have to be written yet. This is more about the generation piece, 22:51.400 --> 22:55.000 not to what the validation piece yet. I'll get there. Anthony? 22:55.000 --> 22:58.360 I have a tool to take back, because both that do a HTML and page. 22:58.360 --> 23:02.120 Oh nice, nice. Yes. Mr. Tools himself, got a tool. 23:02.200 --> 23:07.160 Can you ask me how many HTML questions? Yeah, one here. 23:07.160 --> 23:12.520 Whenever people produce their S-bombs, like where do they typically store them? 23:12.520 --> 23:14.920 Hmm. I like people produce them. 23:14.920 --> 23:18.120 Love that question, because there's something that we never really talk about. 23:18.120 --> 23:23.080 The question is, you've generated your S-bombs. What do you store it? 23:23.080 --> 23:28.520 Literally the reason why I got excited about this space in the first place. Because a lot of people 23:28.600 --> 23:32.600 come from a resource angle, let's say chuck and get up, and that's part of the release. 23:33.320 --> 23:36.680 Great. Works great for an open source project, not for the real world. 23:36.680 --> 23:41.480 That is literally what the back end component is does. It shipped S-bombs to the back end. 23:41.480 --> 23:45.720 You could do release management across, I mean, if you go back to the slide with the tree, 23:46.440 --> 23:49.960 that you could do release on top of the level, the points store that are hard. 23:49.960 --> 23:54.520 So grab me afterwards, I can explain that in details, but that's literally the other piece to the 23:54.520 --> 23:58.440 puzzle that I haven't even talked about in this talk, because too much ground to cover. 23:59.480 --> 24:03.160 But yes. So, sorry, we're after that. 24:03.160 --> 24:06.520 Well, it's time for it. Thanks so much. Thanks very much. Thanks very much.