 All right, thank you very much. Yeah, so my name is Mathias Cook and I'm going to present about AMALANIX support in, sorry, ASPOM support in AMALANIX. And so first of all, a little bit about myself. So yeah, this is me and I, so I come from embedded, I have an embedded background, kernel development and in 2020 I joined Cybertrust. And at first I was working in the AMALANIX, Miracle Linux team. And since my company joined AMALANIX Foundation in, well this year and early this year and ever since then I've been working on AMALANIX and in particular on ASPOM support. And so I think there are probably no German speakers here. So like in my free time I also do work on, well, some open source projects, but also like I used to write some like on shell scripting. So if you read German, maybe you can read some of my articles, that would be nice. Used to work right for this Linux magazine anyways. So yeah, so what I'm going to talk about today and like what you're probably hopefully remember at the end of this talk is first of all, like how ASPOMs are generated in AMALANIX and why we generate ASPOMs in AMALANIX. And second is what sort of contents of our ASPOMs in AMALANIX, so what information is in our ASPOMs. And at the same time I also want to talk about the information that we could put into our ASPOMs that we don't put into them right now and how we're going to address that and yeah. So like at the end of the talk you will have an idea where ASPOM support in AMALANIX is going to be by the end of the year probably. So first of all, let's talk about the why and this is, so in the United States in 2021, the US president signed the executive order 14.08 which basically says that if you deal with a federal agency, you need to provide ASPOMs to well to your customer, which is like the federal agency. And so the requirements for ASPOMs are defined in NTIA minimum elements. And essentially it says that the ASPOM has to state, well first of all, who created the ASPOM itself but also like who created the software component that is described in the ASPOM and what else? Oh yeah, then the software component itself like the name version, et cetera. But this ASPOM also has to contain the dependencies that are, so the software component, the dependencies that it includes that need to be stated in the ASPOM. And on the other side of the Atlantic and in the European Union, there's the Cyber Resilience Act which has not been signed into law yet or it's not become a law yet. Well, I mean technically both are not laws but so the Cyber Resilience Act says that ASPOMs need to be provided but it's less clear about the contents of the ASPOM but it still says that there need to be the dependencies and also it doesn't specify which kind of dependencies so it's a bit more vague. So anyway, so the way we generate ASPOMs in Almolynux is so there's the backend side and the user side and so during the build process we have the sources and git.almolynux.org and the build system will take the sources and well build RPM packages because we're RPM based Linux distribution and during the build process meta data is generated well like the package name like the obvious information that you would expect and this information is stored in a component called immuDb which is as the name indicates immutable database and so actually that means on the we don't provide ASPOMs as like we don't provide ASPOMs but we provide the data that goes into ASPOMs and so when you generate an ASPOM for an Almolynux package what you do is on the user side you use the ASPOM generator and tell it which package you would like to have an ASPOM for and then this ASPOM generator goes to the immuDb queries the metadata for this package and creates the ASPOM for you and so this is generally how it works and so the reason why I'm talking about this is because after my company joined the Almolynux Foundation I was the one who implemented SPDX support for this ASPOM generation so that means the first of all so if you generate an ASPOM on your side so the steps are relatively simple first you would download the package or I mean if you know the hash you don't need to download it you can skip steps one and two but generally you would get the package that you want the ASPOM for calculate the hash of the package and then run the ASPOM generator telling it like this is the hash of the package that I want to have the ASPOM for and then you can tell it that you could tell it for example you want the SPDX ASPOM in JSON format or you could have SPDX in XML or tech value or whatever and you can also if you could tell it that you want to cycle on the ASPOM but yeah this is basically how it works and so the information that is included in these ASPOMs is as I said the ASPOM refers or it contains information about first the process that created the ASPOM so which is as Almolynux ASPOM and the timestamp when the ASPOM was created but then it's also like the information about the RPM and the SRPM which is the source package that was used for in the build process but also unique identifiers for the packages like a CPE and what's the other thing, PURL, so package URL and then there's information about the host that built the package and the build job that was created so like some maintainer creates a build job in the build system and then you can use the ASPOM also to trace back like who created the build job and like what's the build job, the build number, et cetera and yeah of course most importantly you can also see on the right side there's git.almolynux.org and so the ASPOM contains the URL of the source repository and the hash of the commit that was used during the build so you can use the ASPOM to trace a package back to the source that the package was created from so yeah but actually, it's first NTIE, NTIA Minimum Elements sorry, so these are the eight pieces of information that need to be in an ASPOM according to the NTIA Minimum Elements and so there's like a name of the author and supplier which in both cases would be Almolynux Foundation and the component name whilst the name of the package the version would be so in RPMs versions contain up three parts, the epoch, the version and the release all of that information goes into the version string and then you have the hash, the unique identifiers, et cetera the interesting thing here is the relationships so we don't have any relationships in our ASPOMs and it's still NTIA Minimum Elements compliant and that's because minimum elements say that these need to be the included dependencies and in RPMs usually like one RPM package if it depends on another package it usually doesn't include it so if you install package A which depends on package B the package manager will first install B and then A but like package A does not include package B and this is why we don't need to have this relationship in the ASPOM at least from the NTIA perspective which might not be very satisfying because as a distribution we actually there's a lot more information in an RPM that could be used and that could be put into ASPOMs so especially I mean so on the build side there's not just the build host and the repository there's also the build tools that were used so like a mock et cetera and then we have so package belongs to a distribution but it also belongs to a certain version of the distribution this kind of information could be included in the ASPOM and then on the bottom left side you have lots of other like change logs files in the packages license which is more or less interesting but then you have also like the so in SRPM there's a package in the patches that are included in the SRPM which might be interesting for ASPOM generation and what's most interesting is on the right side the dependencies so like the dependencies that are not include dependencies but just when package depends on other packages like this information would be very interesting for an ASPOM and yeah so this could be like strong dependencies like a package needs another package to be installed to run but there is also weak dependencies which is like it suggests like a package A suggests that you have package to be installed because it might be useful but it's not necessary to use A like these kinds of information could also be in there but there is also dependencies can also be encoded as capabilities which basically says like this package provides a certain functionality and then other packages can depend on this functionality but it's not the package name itself like this functionality can be provided by different packages so for example, well I don't know what's a good example but for example if you depend on grep like you can have grep like the new implementation or the VST implementation or whatever so it could be different packages but the capability would be grep. Yeah anyway so there's a lots of information that we as a distribution have that we could possibly put into ASPOMs that we don't put into ASPOMs right now and so I thought this is where we need to work on. So yeah right so there's sorry the graphics are not terribly good but I don't want to like distract from the content. So yeah there's a low hanging fruit would basically like the changes that we need to because you've seen how the architecture kind of works so we have the ASPOM generator that runs on the user side and changes to the ASPOM generator itself are relatively simple. It gets more complicated when we want to change the backend side because there might be changes to the database and getting the changes here is more time consuming and more effort also because it affects other parts of the build system. So for changing the ASPOM generators on the client side we can get the license information or like modularity streams and capabilities like all this information that we can read right from the RPM file. This could be added relatively simply and then there's stuff like the patches which like here's a bit more complicated so doing this on the build server side makes a lot more sense and also like a build tool so which is something that is you cannot get this information from RPM so this would need to change on the build system side and then actually the dependencies are a bit more complicated for a reason that I'm going to explain right now and so because I usually mostly worked with SPDX file so this is going to be a bit SPDX heavy but it's actually, it works something like this in Cycle on the X as well. So here you have two ASPOMs, it's not very accurate but generally speaking when you have ASPOM that like two packages and because of the way we generate our ASPOMs we have one ASPOM per package. Now if one package depends on another package it would need to refer to a package that is in another ASPOM and the way you do that in an SPDX file is that the ASPOM includes a external document reference and this external document reference says like this is URL of the ASPOM that I'm including and then the other one is the hash of the ASPOM. So yeah, if you know the exact name of the exact name and the exact version of the package you're including and it's like a situation like this, it's no problem but it gets more interesting when we look at our so in RPM packages usually the dependency version is like sometimes it's encoded in the package sometimes it's not, mostly it's not. So we have situations where we know for example we depend on grep but we don't know which version. So the question is when we build the ASPOM like what do we put into the external document reference which ASPOM do we refer to? So it could be different versions and depending on what the user uses in their environment they would need different ASPOMs so like we cannot deliver the same ASPOM to the users in this case. And so yeah, this is one of the problems. The other problem is when we think about so in Alma Linux or well any Red Hat based Linux there are cyclic dependencies. So like package A depends on B and B depends on A which I mean it might be direct, it's usually not it's sometimes like the cycles are a lot larger like it's 10 packages that create a cycle and then you have cyclic dependencies. And so now because in the ASPOM to depend or to include another ASPOM sort of you need to have the hash and if the ASPOMs depend on each other you need to have the, well you cannot add the hash but let me start another way around. So you create the first ASPOM and you need to add the hash of the other ASPOM which you then generate and you need to add the hash of the first ASPOM to the second ASPOM and then you would need to regenerate the first ASPOM and then the other so it's like because it's like it doesn't work with the hashes in the ASPOM so yeah because so we needed to work around this and yeah so the solution to work around this is we actually leave the ASPOMs the way that we provide them right now as is or well actually we could like pick some low-hanging fruit and add them to the build ASPOMs and introduce a new ASPOM type AS which is called a deployment or deployed ASPOM and this deployed ASPOM would first it would be one ASPOM for the entire system so there are no external dependencies and because of this cyclic dependencies can be in and because all the packages are in the same ASPOM you don't need the external package reps and so we can like have all the dependencies that we want in our ASPOM and the other thing is that because we generate the ASPOM represents exactly what's deployed in the system so we only have like these crisps crisps dependencies where you can say it's exactly this version and exactly this release, et cetera so yeah this way the problem is solved and yeah so the benefit of doing it in this way or well having this deployment ASPOM it allows you to well you can because the ASPOMs can contain the CPEs you can like how do you say it like you use the ASPOM data and for example overall SCAP data and like edit and like use the two data together and you use the scan systems and you can use it to do like offline scans of systems and yeah so the other benefit that I see in this kind of approach is that you could also use it to generate ASPOMs for example of Docker containers or well Docker, Podman, whatever you use and yeah this way you have an ASPOM that represents exactly what's in your Docker containers and yeah so I was planning to have a proof of concept done until today which well I didn't get it done and because like a lot of this dependency issue is something that I found out while I was trying to add dependencies to the original build ASPOMs so I cannot demo the stuff that I was trying to show also, hold on a sec, interesting. Yeah I shouldn't have done package update before I came here. So my virtual machine doesn't start which is not helpful but I can still show you, actually I'm not sure if you're gonna be able to read this. So for example this is what the current build ASPOM in this case it's for a bash package. This is what an ASPOM current looks like. I was going to show the entire process of generating it but yeah sorry my virtual machine doesn't start. So yeah in the beginning who created the ASPOM which is like well Alma Linux Foundation and then the tools that were used to generate the ASPOM itself and like a license of the ASPOM and then you have a package and the version of the SPDX document and the document namespace and then here you see like in the packages section there's SPDX rev zero which is I'm not sure. Can you read that in the back of the room? Nobody's complaining. I'm sorry it's a bit small. Let's see huge is invisible. Or maybe yeah I guess that's a bit better. So yeah there's this SPDX rev refers to the package that's in the ASPOM and then you have annotations. So epoch version release like oh sorry. Like these three are the version of the package which is like epoch zero version five one eight and then release is six point EL Q under bar one. And yeah architecture source Rfm. Well actually the most interesting stuff is probably further down CPE PURL. No but actually oh where was it? Oh so this is the name of the branch that the package was built from and a bit further up. Here you have the hash of the Git source or the commit and the source repository and a bit higher up is the URL of the source repository. So yeah this is to show that like you can use SPOMs to figure out which exact source was used to build a certain package. And yeah so like this does not include dependencies yet but so I'm working on this and I'm hoping to have this done by the end of the year and yeah. So yeah so if you found any of this interesting so you can get in touch with us on, well actually the source code for this is on GitHub. So github.com slash almalinux slash Alma hyphen SPOM is where the source is located. There's the almalinux chat. If you're interested in SPOMs and if you want to like get in touch with us and like influence the way SPOM support and almalinux develops in the future just join the chat and talk to us and then there's also like you can connect on LinkedIn. Yep and that is it. It's a bit shorter than I expected. I'm sorry. Okay questions? Yeah okay so as I have a. I'll say it can be repeated. Yeah. Okay so cyclic dependencies and things like this. Why you put that into the dependency resolution process is because maybe somebody already has a version of a pretty good package installed and so they don't want everything to be exactly the same version of the exactly the same thing. Like you want the ability to have a slightly older slightly different version of one of the packages and to work with the others. Right and so one thing that I'm like finding kind of like a little bit of cognitive mismatch here is on when you're thinking about SPOMs in terms of a specific package. I think the reason why that self-referential problem is hard is because intentionally the package manager is trying to have latitude in what it can choose to fulfill a specific dependency. Like which version of a package you can use. And so I think your deployment thing solves that problem in a nice way. But what are your thoughts about how dependency resolution is a list into SPOM creation process. Is it important to have those hashes in there or should there be more flexibility? So your question is what my thoughts are about like how dependency should be added to build SPOMs. Do I understand that right? So yeah, let me see, you just have to find it. Yes. So rather than the usually that isn't done or at least it's not usually done in a single way otherwise you just bundle all that stuff together. Yes. So yeah. I mean if I bundle everything together then I would have the situation where it's actually in the package I know what I'm providing so it's very easy to create an SPOM. So the issue that we're having is actually that because we don't know which version of a package the user will be installing. So we cannot generate any reasonable meaningful SPOM and on our side and we would have to like the user needs to create well deploy SPOM on their side. And so for the build SPOM I don't see a way that we could provide meaningful SPOM because we just don't know which version of a package is going to be installed. I mean we can make guesses and yeah. But at the end of the day it sits up to the user what they're going to install. Right, it's the dependency when I capture not the specific version in that case though. Yeah. Yeah, I mean of course you could also add all possible like because we know which packages we have so we could theoretically add all of them but the question, that is true but the SPOM create contains a timestamp so you could, I don't know. Yeah, so I think so the way I understand the SPDX standard is that there are no wild card dependencies. And this makes it complicated to correctly model this with a build SPOM. Thank you. Any other questions? Yes. Is this only for Fedora or? Oh, this is for Almalinix and because it uses metadata from our build system and this only works for packages on Almalinix. I see. Oh, sorry, I think it was supposed to repeat the question. So the question was if this is only for Almalinix or other distributions and yeah, so. Only for Almalinix. Yeah, this is only for Almalinix. If you, so because we, so this depends on our build system and so if you ported the part of our build system that generates the metadata and puts it into MUDB if you added that part to the Fedora build system then you would be able to use it. Any other questions? Still got time left. Okay, in the back of the room. Test, okay. What are your thoughts on the author of the S-Bomb being the person who runs the generator not just Almalinix because that's where the data comes from? That's an extra question. And I actually, before I created the presentation I thought the same thing. It's actually because we're, right. We're just providing the generator. We're not providing the S-Bomb. Well, we provide the metadata that goes into the S-Bomb. So my thought was probably because the user is using our data to generate an S-Bomb. So like from the build of the package to the generation of the S-Bomb there's actually no way the user could modify the S-Bomb unless they modify the S-Bomb generator of course. So you could argue that the user if they generate an S-Bomb it's still sort of generated by us because we control the generation process. And then the user if they customize it they would have to change the name of the author in the S-Bomb. But I think this is a discussion that we still need to have on our side too. Because yeah, I think there's a good argument to be made that this should be the name of the person actually running the S-Bomb generator. Thank you. Thanks. All right, anyone else? Thank you very much. Thank you.