 So, hello people interested in an exciting topic of software identification. So the question that should be waking you up now is, what software do I have on that machine? What software do I have on my laptop? What software is running in my containers? And for me, the answer is sort of clear, I am clear with you and I know everything, right? Except not always because I may be running some containers from some images that I don't know it from, well, Docker knows where. And I might be running some scripts that I just clone from some computer. So who is asking the question, right? That might be sort of interesting. When I am to troubleshoot or debug a problem, I might be interested in the particular versions of libraries, whether they are available or whether they are installed or not. I might be scanning for vulnerabilities, so I might be looking for a fix for a particular or I might not necessarily be interested in the list of RPG packages or the packages on the lowest level because if my goal is to just charge a customer for running my product in some cloud somewhere for two hours, the fact that it's the product, whatever the product is, might be the important part. So RPM-Q might not be enough, unfortunately, I mean our lives would be much easier, but there are people and systems or there are people using systems that use different packaging formats even on Linux. There are people who deploy their applications just by dropping a zip file somewhere and their application server will just by managing start to do something. And of course we might want to or need to be able to account for something on higher level than just packages. So when things don't seem to be easy and you have multiple standards, what you do, well you come up with another standard. So it stands for software identification and it's ISO standard and we'll be talking about the one which has 2015 in the name. You might see 2009 mentioned somewhere that was an older version, not compatible, and I sort of don't care about that. So if you came specifically because what makes you up at night is that you have something to do with 2009 standard, I probably won't be helpful at all. So it's an ISO standard so you cannot read it unless you pay, but you're not missing much because what the text of the standard mostly does is describe an XML schema definition. So SWIT is all about XML files within or in a bunch of XML main space. The definition of the main space is this one, so people who are primarily with XML, where will you go to look for the schema definition if I tell you that this is the main space. But you might have experienced that when you look at something looks like URL, you go there and there might be something there or there is not. And especially when it has that extension it looks like there should be something there and there is. So it is good because on the URL there is schema definition but it's for a completely different main space. This is a new standard so you need to be prepared and this is like the entrance level of your ability to do SWIT at all. So when you want to see the definition of the schema you have to append the current to URL to actually get the definition for the main space that we've been talking about. And it's a nice main space definition. It has documentation in it and the documentation in this XML which defines the other XML files that we'll be talking about is sort of mirroring what is in the standard text. So that's why my feeling is that you don't need to pay ISO. So this is the way how you sort of tell the XML tools that even if the first one looks like URL, when it is interested about schema definition it should go to the other URL to fetch it. So the object that we are interested in is a SWIT tag and SWIT tag is nothing but a XML file with root elements of the identity in the XML name space of the SWIT. Well, that the SWIT defines. By the way if you have any questions and you're feeling lost try to shout or get my attention because the more you are lost the happier you will be and that's not my intention. So don't hold your questions until the end. So the primary goal or purpose of the SWIT tag is to describe install software. It might also describe relationship between software product packages components and it might also be used to describe like installation media so if you have some distribution ISO. But primarily it is about what software is installed on this particular machine. So you would like to see a SWIT tag, right? So I have a good news. So if you have a Fedora 29, let's try it here Fedora 29. In user-leap SWIT tag, Fedora project org, we have a SWIT tag actually. Is it big enough for you or do you want the font bigger? I can show off to make it bigger. So it's an XML, it's in the name space I promise, it has the root element that I promise and you know when when you start to look at XML you might not necessarily immediately see what is important. So one of the important things is the tag ID which should be uniquely or generally universally unique identifier of the SWIT tag. The standard sort of assumes that you might be using your ID but I like to look at a string and have some clue about what it's about. So SWIT tags that I create have some meaning even if you are not supposed to parse that string. You are not supposed to like you know write tools that will split the tag ID itself and say well this is Fedora. You are supposed to look at the other attributes in the SWIT tag. Another interesting or important thing in and you have things like name and version in the SWIT tag but a fairly important thing is a entity tag creator and software creator. So you might be creating SWIT tags, identifying software for software that you did not write or ship. You are just creating SWIT tags for something that maybe you found laying around on your system. So there's a way to either identify that Fedora project might be both creating and creating the software and tag or there might be multiple entities that that do that. And there's a bunch of other interesting entries here. So one thing that you might notice is that there's nothing about files in this or about content right. So if we look at another example let me make this a little bit smaller so that I can make it a little bit bigger so you see the bottom. So this might be an example SWIT tag for for bash and I gave it this tag ID. So you see a pattern it's like the Fedora project or just reversed and then dot and then never out of the RPM package and it has some some information general information I can say that Fedora project created both the package and the tag and there can be an evidence of what was maybe found on the disk with a list of files and directories and checksums. So now we are getting somewhere right now we are describing not just all this is bash but the content of the package is something of an interest. So what are the XML namespaces you might encounter when you look at SWIT tags? Obviously checksums there is also an extension for the NIST internal report 8060 which is sort of a guideline for implementing SWIT. So if you want to read some piece of literature I might recommend the internal report from NIST. Obviously NIST is down because of shutdown so this page loads but the links to the actual PDF date no longer load so you'll need to fiddle with archive.org or something or ask me because I have the PDF downloaded right because I'm coming prepared. So it talks about well the guidelines talk about creating tags creating authoritative and non-authoritative tags how links should work so what how how you are supposed to maybe link things among other and so on. So the next thing that you might encounter are XML signatures so the standard sort of comes and assumes that the content of the SWIT tag will be signed when needed. If you look at the XML SWIT tag you might be disappointed to not find any signature there and but if you look at beta that I have here as well in user lips with tag and now where would you expect the next path it would be redhead.com right because it's not Fedora. You might find a file which at the bottom has an XML signature and the certificate chain. So we shipped a SWIT tag identifying distribution for both Fedora unsigned and rather a 0 signed. So if you want to look at some examples of SWIT tags that's that's where you might want to start but what if you want to create some SWIT tag like for yourself. So we have a tool in a copper repo copper enable an auto SWIT yes and if this takes too long I have another container where it is already installed so I'm coming prepared. I've called it RPM to SWIT tag so you see I've started this RPM because if you ask me what I've been told my machine it's RPM-Q right. So I started with RPM just to oh it's already installed sorry I need to go to this one to have the experience for you fully. Fully matching what you will see and then it'll probably take a little while. So we have a tool called RPM to SWIT tag which can take either installed RPM in RPM database or RPM file a package and generate a SWIT tag for you. So which okay let's let's make it let's live on the edge. For which of these packages would you like would you like me to create a SWIT tag for you? Sorry oh hit this one got it RPM to SWIT tag so we have something it has a tag ID as I said it's fairly important. We have entity where I'm saying well I have no idea who created the SWIT tag so the standard or the NIST internal airport 8060 I'm not sure says that's invalid unavailable is what we probably want there and we have a list of directories and files and the checksums so this is pretty cool right. There's another SWIT tag creeping here so but we'll come to it later. So we can also look at the SWIT tags that we have on our system so if you've installed RPM to SWIT tag it also comes with SWIT Q it will only find two SWIT tags because that's what we have and it's interesting I didn't tell you that I have the second one here because well I don't need to tell you everything right away but we have many more packages installed on in that container right so if I run the NF RPM to SWIT tag regenerate what I should get is a list of SWIT tags for all the packages I have so and it will store it in one of the SWIT tag whatever pass. You can also generate SWIT tags for if you have a YAM repository if you just created one using create people you can also generate that and then the DNF plugin can pull it from from the repository for you so if you don't fancy looking at XML it is also possible to so we now have many of them and I can say this RPM what was the name SQL light lights I don't know the name I'm doing something wrong what happened somebody what happened yes the name of the package is frozen out so with this I I can display the content of the SWIT tag in a more readable form and I can also I think I also have dump which dumps it because if when you are working with new standard you come up with a new format right as well so this is my my way of displaying XML but you can also say I say XML so one of the things that you might know notice is that there might be multiple SWIT tags for a package and it's because you can describe links or relationships and one of the relationships is supplemental so you can have a sweet which comes afterwards and says well I know there is already a sweet that this time for example Fedora but I'm telling you that this Fedora also has a component SQL light leads or something like that and the sweet tag dash I will display it so if I look at Fedora right now so what SWITQ does it doesn't just display things you know in text text format but it also resolves the supplemental tags and the value that came from this marker or the marker is plus and if you're interested in what the differences we can talk about it about it later so basically to know everything about a particular sweet tag you need to look at all of them resolve the supplemental tags and only then you know like what the content of the of the sweet that actually is for for a given set of installed packages or software products on a system there are some other interesting things about sweet tag well the standard is very lax the 8060 next report is more specific sometimes it's not very exact and it does not touch some of the issues that or some of the situations that you might encounter so for example you probably want to have a way to encode architecture right for for your package you want to know whether it is x86 for x86 64 or whether it's no arc so we used the arc attribute which the standard allows but the validation to provide it by or that the schema allows because basically any but the validation to that miss provides does not accept so that there are a little confusions in there so when you want let's say that you have a system let's say you have sweet how do you find a sweet like what was the location of a sweet tax the standard seems to assume that you basically scan the whole day and then when you find a sweet tag what is next to it is is the package that you're looking for to be reasonably efficient we came up with a plan so we are men with span and in sweet sweet tax dash D we propose similar to basically locations that hold sweet tax so that for maybe fedora or rather than placement of the way and the standard allows us to do it a standard allows us to define a vendor specific or platform specific way of finding sweet tax so it would be the same links in this directory things can be time so and I have an option in our PMP to sweet tax to call XMO sex line the guidelines around signatures are a little bit confusing they expect trust it understand but they don't really say how the chain of trust should should work so we just ignore that part so what's what's the plans I want to be able to finalize the XML namespace used in the DNF repository because sweet tax defines namespace for a single pair for a collection of tax that I want to basically produce for young repository and then make available I want to basically create a report which would serve as a place for people to for basically me and us are publishing what our recommendations or best practices or decisions design decisions have been and for other people to maybe comment on it via poor request issues or so we hope that next would serve as that place or tech world would serve as you know that that place for people to show what they have and maybe discuss what their next step should be but it did not happen so I'll create a report there my biggest problem is that I don't know what the name of the report should be so you know naming is hard and I made a decision about the tech IDs using never but for this one it needs a little bit of time we have a DNF plug-in I need to write a little DNF plug-in because apparently having well you need to implement things twice in DNF world I'd like to get the tools that you just thought to Fedora 30 and I probably need to add signature validation and having a way to show not just the tree of supplemental text but also you know other relationships like components but the problem is that to show you components of Fedora I first need to resolve the supplemental text to find the final information about what the components of Fedora actually are so it's like multi multi-stage process and I also want to make it possible to update sweet-text from the YANA repository if you already have the packages installed not just during installation we welcome people who have any opinion about this because you know we try to read the standard we try to read the documentation we try to implement something but you know other people I have other use cases if you feel like coding or you have a student who feels like coding definitely adding something like depth to sweet-text or zip to sweet-text or directly to sweet-text might be useful I might get to doing it eventually anyway but I'll be happy to review a page here's a list of some of the places you might want to check out and we don't have time for any questions but I take three so yes it seems to be used mostly in a supply chain scenario where you deal with trusted data it has been used with untrusted material such as for purposes of category I don't know viruses malware oh well if you don't care about trusted you don't sign it so if it's not signed if you you are okay about the evidence you can generate the sweet-text on the machine not have it signed by the lander by redhead of the project or anybody and you can use it by other tools that might want to look at that information life or form like and you can counter-sign yourself the tabs you care about in your environment and have your own application so you have a lot of options for going down that out goes because you want or if you just hear about having a label you don't have to have any sign at all depending on what you're going to use it for you don't need to have anything hard to get something out of it so that came in as two questions so the survey was one are there any plans for having a profaned IPI or the modules, detection and computational specs? we're hoping that the OpenSCAP team will be implementing basically processing of sweet-text because the SCAP of R3 sort of either requires or asks or strongly asks them to do so okay thank you I'll be around if you have any more questions but I don't want to hold you up