[00:00.000 --> 00:20.000]  All right, so first of all, thanks for staying with us on Sunday, and for sending the SOMROM of it as part of their organizers, I'm really happy to see this move.
[00:20.000 --> 00:40.000]  And so we have been going through all of those cool use cases and complex, like really complex and complex tools to generate lessons and analyzing how companies, big companies have been doing it, and like going deep into the research of how SOMROMs are composed.
[00:40.000 --> 00:56.000]  So I was thinking that I wanted to do like my talk as a kind of pivot as we are shifting towards the more discussion part of the bedroom.
[00:56.000 --> 01:10.000]  And so as you have been hearing from folks right now, a lot of folks working on SOMROMs are starting to get concerned about what's actually in those documents.
[01:10.000 --> 01:22.000]  And I think when Thomas opened the bedroom today, the first thing he said was, well, those dependencies that you're getting, they may not be correct, right?
[01:22.000 --> 01:33.000]  So I thought that it would be, as we move to the latest part of the conference, it would be cool if we could get a few talking points just to see the conversation that's about to happen.
[01:33.000 --> 01:49.000]  So my name is Lofa Garcia, and I am part of the SBDX community. I am a contributor to SBDX and some of the tools. I maintain a bunch of open source tools that generate and consume SOMROMs, and that help visualize them.
[01:49.000 --> 02:04.000]  I am also part of the Kubernetes project. I am part of Kubernetes to Release, and I work there mostly on the supply chain security of the project. And yeah, I like riding my bike.
[02:04.000 --> 02:15.000]  I'm based in Mexico City, and I am a staff engineer with Chinger, which is a company devoted to supply chain security.
[02:15.000 --> 02:26.000]  So as you heard from probably every speaker today, the goal of having an SOMROM is getting a document which you can actually use for something.
[02:26.000 --> 02:44.000]  And there are many concerns about SOMROMs flying around in the world today, because there are particular use cases, and some people will argue that SOMROMs may not be necessarily incomplete if they're not suitable for one case or the other.
[02:44.000 --> 02:59.000]  And this is true, but instead of trying to picture ourselves like generating a next one from the position of like a large company or whatever, I felt that it was more appropriate to discuss today that how...
[02:59.000 --> 03:11.000]  I mean, I am assuming a lot of people here are maintainers of open source projects, and sometimes very small open source projects like one maintainer small.
[03:11.000 --> 03:24.000]  And I think it's important to start considering that when those large companies are going to use your projects, your library, important in that model that you write,
[03:24.000 --> 03:29.000]  the SOM that you give them can really make a difference in several areas.
[03:29.000 --> 03:37.000]  Like first, you can make their life easier because you're handing them more complete information which they can act on.
[03:37.000 --> 03:53.000]  And the other one is we as the open source community become better citizens of the supply chain, like generating the information that pertains to us is a much more responsible thing to do.
[03:53.000 --> 03:58.000]  So what happens when you open a next one?
[03:58.000 --> 04:01.000]  Well, today you can get all sorts of surprises.
[04:01.000 --> 04:03.000]  Sometimes there's nothing in there.
[04:03.000 --> 04:05.000]  You open the SOM and it's empty.
[04:05.000 --> 04:13.000]  Sometimes you don't have absolutely any information that lets you determine what that SOM is describing.
[04:13.000 --> 04:18.000]  So it's simply just pointing to the same black box that you can look from the outside.
[04:18.000 --> 04:30.000]  Or the other is what happens if are you sure that the SOM is really describing what you're expecting to and you're not getting caught by someone?
[04:30.000 --> 04:40.000]  Well, that information needs to be in the SOM in order to ensure that importance.
[04:40.000 --> 04:47.000]  It needs to be in the SOM in order to ensure that it's actually describing that piece of software that you're distributing.
[04:47.000 --> 04:51.000]  So I'm going to give you a few examples.
[04:51.000 --> 04:59.000]  I'm not trying to name names and that's why I chose projects that I'm involved with.
[04:59.000 --> 05:01.000]  Both good and bad.
[05:01.000 --> 05:03.000]  So this is the first one.
[05:03.000 --> 05:11.000]  This is our company has a Linux distribution which is already shipping with S-bombs built in.
[05:11.000 --> 05:16.000]  And we generate those S-bombs at build time for all of the packages.
[05:16.000 --> 05:20.000]  And you can see the structure here of one of the S-bombs.
[05:20.000 --> 05:30.000]  This is like a visualization of the S-bombs using the Kubernetes BOMB tool which lets you ingest SPDX documents and see how they're structured inside.
[05:30.000 --> 05:46.000]  And as you can see, we try to, in the Linux distribution, add a lot of detail to the S-bombs as much as we can to just guide whoever is using those S-bombs to do smart decisions with the information they have in them.
[05:46.000 --> 05:50.000]  So if you look at some of, this is a fragment of the S-bombs.
[05:50.000 --> 05:54.000]  And I mean, some information is there.
[05:54.000 --> 06:02.000]  Some information is, for example, the licenses, the license concluded fields.
[06:02.000 --> 06:06.000]  They are marked as no assertion, but you can omit those, for example, if you want.
[06:06.000 --> 06:12.000]  But we have the license from the project, from the actual operating system package.
[06:12.000 --> 06:17.000]  We have some identifiers, things like that, so it's pretty complete.
[06:17.000 --> 06:23.000]  It's obviously not perfect, but we try, and we try to add as much information as we can.
[06:23.000 --> 06:31.000]  But then, let me show you another S-bomb from another popular open source project.
[06:31.000 --> 06:35.000]  This is part of the Kubernetes S-bomb.
[06:35.000 --> 06:42.000]  This is part of the S-bomb, like the structure, a little fragment of the structure of the S-bomb
[06:42.000 --> 06:46.000]  that we generate when we put out a new Kubernetes release.
[06:46.000 --> 06:54.000]  And this is describing, for example, the tables which we put out with every release.
[06:54.000 --> 06:58.000]  One of the tables of the Qube API server, the list of files.
[06:58.000 --> 07:01.000]  So we also try to add information.
[07:01.000 --> 07:05.000]  Two S-bombs with Kubernetes, one with the artifacts, one with the source code,
[07:05.000 --> 07:07.000]  which are linked one to each other.
[07:07.000 --> 07:12.000]  And so we also think that those are fairly complete S-bombs.
[07:12.000 --> 07:18.000]  But now, I opened an S-bomb in a popular open source project
[07:18.000 --> 07:22.000]  and tried to generate the structure like this.
[07:22.000 --> 07:25.000]  I'm not going to say which project it is.
[07:25.000 --> 07:31.000]  It's just one I'm involved with and we should be doing a better job there.
[07:31.000 --> 07:40.000]  And you can guess many reasons of why this is showing zero things, but we can go over this.
[07:40.000 --> 07:48.000]  So as you can see, you can really enrich an S-bomb with a lot of information,
[07:48.000 --> 07:51.000]  and some of it can be more important than other things.
[07:51.000 --> 07:56.000]  But I've been thinking, well, what's the most important details that you can add to the S-bomb?
[07:56.000 --> 08:02.000]  So the first one is, and by the way, most of this, you already heard it through the day
[08:02.000 --> 08:04.000]  if you've been sitting in most of the conferences.
[08:04.000 --> 08:06.000]  So we're going to go one by one.
[08:06.000 --> 08:09.000]  So the first one is syntactic correctness.
[08:09.000 --> 08:16.000]  You would expect that most tools generating S-bdx or cyclone DX S-bombs
[08:16.000 --> 08:20.000]  do the basic job of just making a compliant document.
[08:20.000 --> 08:24.000]  Well, the reality is that they're not so.
[08:24.000 --> 08:33.000]  I picture this guy from Apollo 13 that tries to fit the square peg in the round hole or the other way around.
[08:33.000 --> 08:38.000]  Because if you cannot ingest an S-bomb, so what's the point, right?
[08:38.000 --> 08:45.000]  And even if you have tried to somehow hack the document or ingest it somehow,
[08:45.000 --> 08:54.000]  the reality is that most tools that consume S-bombs today do not have a clear strategy of deprecating the documents.
[08:54.000 --> 08:59.000]  And most importantly, not clear and also not predictable.
[08:59.000 --> 09:06.000]  So if a tool tries to somehow ignore errors or whatever, the behavior may not be consistent.
[09:06.000 --> 09:16.000]  So ensure that any S-bomb that you're producing or requesting at least complies with syntactic rules of the standard you're using.
[09:16.000 --> 09:18.000]  The second one, dependency data.
[09:18.000 --> 09:22.000]  And this is a little bit related to the first one.
[09:22.000 --> 09:24.000]  I've seen S-bombs.
[09:24.000 --> 09:28.000]  So since I work with a lot of open source tools and my job also has to do with S-bombs,
[09:28.000 --> 09:31.000]  I've seen a lot of tools producing S-bombs.
[09:31.000 --> 09:40.000]  And so for example, one variant of the bad S-bomb is, well, we'll just list like a table.
[09:40.000 --> 09:43.000]  And that's your S-bomb, nothing else.
[09:43.000 --> 09:49.000]  Or the obvious case of this S-bomb contains one thing, an RPM.
[09:49.000 --> 09:53.000]  No dependency on nothing.
[09:53.000 --> 10:00.000]  So we often use the analogy of the S-bomb being the nutritional label of software.
[10:00.000 --> 10:05.000]  But without the dependency list, well, it's really worthless.
[10:05.000 --> 10:10.000]  You can still use your S-bomb as the old checksum.txt if you want it.
[10:10.000 --> 10:13.000]  But S-bomb's going to provide a lot more value than that.
[10:13.000 --> 10:16.000]  Then the second one, licensing information.
[10:16.000 --> 10:24.000]  We've heard a ton of talks today about licensing and why it may be important.
[10:24.000 --> 10:31.000]  So the truth is, if you are publishing software, you're the most qualified person
[10:31.000 --> 10:36.000]  to do the assessment of what the license to your software should be using.
[10:36.000 --> 10:41.000]  And this applies both to the dependencies that you're pulling in.
[10:41.000 --> 10:44.000]  And if you're redistributing any information,
[10:44.000 --> 10:49.000]  ensure that the information about the licensing is going down the stream.
[10:49.000 --> 10:54.000]  Because the tools that we've been seeing today try to do a good job
[10:54.000 --> 10:58.000]  on helping people understand the licensing situation.
[10:58.000 --> 11:07.000]  So I picture checking the passport as an example of the license.
[11:07.000 --> 11:12.000]  The next one, semantic structure in the S-bomb.
[11:12.000 --> 11:15.000]  This one also came during the discussion today.
[11:15.000 --> 11:24.000]  So there are folks that think that S-bombs can be just the list of dependencies.
[11:24.000 --> 11:29.000]  And it may be true, but then you start losing context on where those things fit.
[11:29.000 --> 11:33.000]  For example, if you have just a list of dependencies,
[11:33.000 --> 11:38.000]  and especially if they're not related to an artifact at the top of the S-bomb,
[11:38.000 --> 11:45.000]  if you picture, so the S-bomb can be this beautiful graph of one node that spreads out
[11:45.000 --> 11:49.000]  to lots of relationships in nodes.
[11:49.000 --> 11:53.000]  So sometimes you'll see S-bombs that only have the list of dependencies,
[11:53.000 --> 11:57.000]  and they don't talk about where those dependencies fit
[11:57.000 --> 12:01.000]  if they're describing a concerning image, a binary, nothing.
[12:01.000 --> 12:06.000]  So if you try to do something more sophisticated with that data,
[12:06.000 --> 12:08.000]  you simply can't.
[12:08.000 --> 12:15.000]  If you remember the S-bomb that I showed in the beginning that we built
[12:15.000 --> 12:20.000]  with the Linux distribution, this is how we structure the container images
[12:20.000 --> 12:22.000]  built from our Linux distribution.
[12:22.000 --> 12:27.000]  So you have the container, the layers, and the packages,
[12:27.000 --> 12:32.000]  like the OS packages, and then all of the files in its proper place.
[12:32.000 --> 12:38.000]  And this information is actually coming from smaller S-bombs that get compiled
[12:38.000 --> 12:40.000]  when we build the Linux distribution.
[12:40.000 --> 12:45.000]  So each of the APKs of the distro have their own S-bomb describing that package.
[12:45.000 --> 12:48.000]  And then when we build an image, we take all of those S-bombs
[12:48.000 --> 12:52.000]  and give you one single S-bomb with a lot of that information
[12:52.000 --> 12:54.000]  composed where it's supposed to be.
[12:54.000 --> 12:57.000]  And without structure, you simply cannot do this.
[12:57.000 --> 13:02.000]  And this is one image, but then if you go and make it more complex,
[13:02.000 --> 13:06.000]  you can start thinking about multi-arch images, right?
[13:06.000 --> 13:10.000]  And those need to have this information for each of the images
[13:10.000 --> 13:16.000]  so the relationships start to become more complex.
[13:16.000 --> 13:21.000]  And the way I try to picture is this, right?
[13:21.000 --> 13:25.000]  So they give you a box of Legos without any instructions or anything.
[13:25.000 --> 13:28.000]  If you use your imagination, probably you're going to build
[13:28.000 --> 13:31.000]  something really beautiful, most likely not,
[13:31.000 --> 13:36.000]  especially not the thing pictured in the box, right?
[13:36.000 --> 13:39.000]  And so these are some of the reasons that I was thinking,
[13:39.000 --> 13:44.000]  like if you have structure, then it's a guarantee at least
[13:44.000 --> 13:47.000]  that the tool at least is looking at how the thing is composed
[13:47.000 --> 13:50.000]  and where the information is flowing from
[13:50.000 --> 13:57.000]  and lets you do more complex use cases for the documents.
[13:57.000 --> 14:00.000]  Now, the next one.
[14:00.000 --> 14:06.000]  This also has come two, three times today, software identifiers.
[14:06.000 --> 14:14.000]  S-bombs need to be defining and naming the piece of software
[14:14.000 --> 14:16.000]  as close as possible.
[14:16.000 --> 14:19.000]  And software identifiers are one of the schemes
[14:19.000 --> 14:22.000]  that you need in the document
[14:22.000 --> 14:25.000]  in order to ensure that the piece of software
[14:25.000 --> 14:28.000]  that S-bombs is describing is clearly identified.
[14:28.000 --> 14:32.000]  And all of them have their problems,
[14:32.000 --> 14:34.000]  especially CPE for example,
[14:34.000 --> 14:37.000]  it's like really complex to get it right.
[14:37.000 --> 14:44.000]  But the idea is there's going to be a tool down the stream
[14:44.000 --> 14:46.000]  that it's going to benefit from that information.
[14:46.000 --> 14:51.000]  So if you can add it, you're making sure that the S-bombs
[14:51.000 --> 14:53.000]  can work well with those tools.
[14:53.000 --> 14:57.000]  And this is kind of the idea of that.
[14:57.000 --> 15:01.000]  So how many packages in the world named log, right?
[15:01.000 --> 15:03.000]  So okay, log, but what's log?
[15:03.000 --> 15:05.000]  There are thousands in every language,
[15:05.000 --> 15:09.000]  like operating system packages, libraries named log.
[15:09.000 --> 15:14.000]  So if you can have like a properly specified PURL,
[15:14.000 --> 15:21.000]  CPE, both, that clearly define the piece of software
[15:21.000 --> 15:23.000]  that the S-bombs is talking about,
[15:23.000 --> 15:28.000]  then it can be better referenced and used by tools on the stream.
[15:28.000 --> 15:33.000]  Now the supplier data, this is like a contentious one.
[15:33.000 --> 15:37.000]  Then the reason why I added the supplier data
[15:37.000 --> 15:41.000]  is because as software authors
[15:41.000 --> 15:46.000]  sometimes we don't think that it's like an important field.
[15:46.000 --> 15:50.000]  We simply, I mean, in most large open source projects
[15:50.000 --> 15:54.000]  we just like copyright the project authors, right?
[15:54.000 --> 15:56.000]  Like the editorial.
[15:56.000 --> 15:59.000]  But the reality is that if you jump into any of the S-bombs
[15:59.000 --> 16:02.000]  meetings that go on regularly,
[16:02.000 --> 16:06.000]  you're going to hear all of the compliance folks
[16:06.000 --> 16:09.000]  like I need a name to sue or, I don't know,
[16:09.000 --> 16:12.000]  a different mentality than ours, but people need it.
[16:12.000 --> 16:17.000]  And in fact, it's one of the requirements from MTA
[16:17.000 --> 16:20.000]  as the minimum elements of S-bombs.
[16:20.000 --> 16:27.000]  And this is a weird field because if you deal in
[16:27.000 --> 16:32.000]  kind of more into security of the documents
[16:32.000 --> 16:36.000]  that should be generated during the supply chain
[16:36.000 --> 16:39.000]  and the software lifecycle.
[16:39.000 --> 16:42.000]  This information is kind of, I don't know,
[16:42.000 --> 16:45.000]  not really very useful because it can be forged
[16:45.000 --> 16:47.000]  and you cannot trust it.
[16:47.000 --> 16:50.000]  And so just having a name and an email,
[16:50.000 --> 16:53.000]  well, like it serves compliance folks,
[16:53.000 --> 16:58.000]  but to us it's kind of, well,
[16:58.000 --> 17:01.000]  worthless really for security purposes, right?
[17:01.000 --> 17:04.000]  But then you start thinking about what's
[17:04.000 --> 17:07.000]  a supplier? Is it the author, the company right holder?
[17:07.000 --> 17:09.000]  Is it the tool that compiles the thing,
[17:09.000 --> 17:12.000]  the people who are distributing it?
[17:12.000 --> 17:17.000]  And so, well, at least ensure that you're providing
[17:17.000 --> 17:19.000]  some kind of information.
[17:19.000 --> 17:23.000]  And the idea is know who's selling you your things, right?
[17:23.000 --> 17:28.000]  Buy candy from that guy, probably not.
[17:28.000 --> 17:31.000]  Yeah, exactly.
[17:31.000 --> 17:35.000]  And get him from us.
[17:35.000 --> 17:36.000]  Supplier data.
[17:36.000 --> 17:38.000]  Oh, okay.
[17:38.000 --> 17:41.000]  I messed up this slide.
[17:41.000 --> 17:44.000]  So this one was supposed to be integrity data,
[17:44.000 --> 17:47.000]  integrity data to prevent this kind of thing.
[17:47.000 --> 17:51.000]  So when you, as you heard today also,
[17:51.000 --> 17:54.000]  so S-bombs should be properly hashed,
[17:54.000 --> 17:58.000]  like hashing as much as you can inside of the document,
[17:58.000 --> 18:00.000]  when possible, when it makes sense,
[18:00.000 --> 18:02.000]  especially when it can be verified.
[18:02.000 --> 18:07.000]  So the idea is, is this piece of software that I'm naming
[18:07.000 --> 18:10.000]  in the S-bomb the real deal?
[18:10.000 --> 18:12.000]  Has it been corrupted or not?
[18:12.000 --> 18:17.000]  But more importantly, having hashes lets you deal
[18:17.000 --> 18:20.000]  the problem of the latest, right?
[18:20.000 --> 18:22.000]  So sometimes you will not have a version,
[18:22.000 --> 18:25.000]  but you can still reference that software artifact
[18:25.000 --> 18:28.000]  inside of the S-bomb and other documents,
[18:28.000 --> 18:31.000]  like Bex, for example, via the hashes.
[18:31.000 --> 18:36.000]  So you can think about the versioning system
[18:36.000 --> 18:41.000]  and the software identifiers as links to external systems
[18:41.000 --> 18:45.000]  outside of the S-bomb, like vulnerability databases,
[18:45.000 --> 18:50.000]  like, for example, package repositories.
[18:50.000 --> 18:53.000]  But internally, everything should be addressed
[18:53.000 --> 18:55.000]  via the hash if possible.
[18:55.000 --> 19:01.000]  So if I'm telling you this is the vulnerability document
[19:01.000 --> 19:06.000]  for a piece of software, it should match with the hashes somehow.
[19:06.000 --> 19:11.000]  And the idea is, well, once you start content addressing
[19:11.000 --> 19:16.000]  the piece of software in the S-bomb, you cannot go wrong.
[19:16.000 --> 19:22.000]  And, well, that's basically what I have.
[19:22.000 --> 19:27.000]  And so I just wanted to let this open, you know,
[19:27.000 --> 19:30.000]  kick the conversations that are about to happen
[19:30.000 --> 19:33.000]  about this kind of thing inside of the documents.
[19:33.000 --> 19:36.000]  And if there are any questions or whatever,
[19:36.000 --> 19:38.000]  happy to take them.
[19:38.000 --> 19:44.000]  And if not, you can reach me as Puerco in most systems
[19:44.000 --> 19:46.000]  and Twitter, whatever.
[19:46.000 --> 19:48.000]  So thank you.
[19:48.000 --> 19:58.000]  Thank you.
[19:58.000 --> 19:59.000]  Questions?
[19:59.000 --> 20:00.000]  Questions.
[20:00.000 --> 20:04.000]  Oh.
[20:04.000 --> 20:07.000]  So I was going to ask about the supply and data.
[20:07.000 --> 20:12.000]  And how much is that seen as the individual who wrote something
[20:12.000 --> 20:18.000]  that is maybe an entity who is distributing it as an organization
[20:18.000 --> 20:19.000]  or a software foundation?
[20:19.000 --> 20:22.000]  Well, I would like to hear the opinions of the supplier
[20:22.000 --> 20:23.000]  for another.
[20:23.000 --> 20:25.000]  Yeah.
[20:25.000 --> 20:29.000]  So what's basically, what's the role of the supplier data?
[20:29.000 --> 20:31.000]  So what's the use of that field?
[20:31.000 --> 20:32.000]  Yeah.
[20:32.000 --> 20:34.000]  What should be filled in?
[20:34.000 --> 20:35.000]  Is it an entity?
[20:35.000 --> 20:36.000]  Yeah.
[20:36.000 --> 20:42.000]  Should they feel like a person or an entity or a tool?
[20:42.000 --> 20:43.000]  Yep.
[20:43.000 --> 20:44.000]  Or?
[20:44.000 --> 20:45.000]  Yeah.
[20:45.000 --> 20:48.000]  So I have a question about the last ingredient that you mentioned.
[20:48.000 --> 20:49.000]  So the integrity.
[20:49.000 --> 20:52.000]  In your definition, does that also include signing
[20:52.000 --> 20:55.000]  on the actual as well as itself?
[20:55.000 --> 20:56.000]  Not really.
[20:56.000 --> 20:57.000]  Rip in?
[20:57.000 --> 20:58.000]  No, no.
[20:58.000 --> 21:00.000]  I was going to go to that question before.
[21:00.000 --> 21:04.000]  But if anybody has insights about how supplier data
[21:04.000 --> 21:10.000]  is used in the organizations, now's the time to discuss it.
[21:10.000 --> 21:11.000]  All right.
[21:11.000 --> 21:12.000]  Yeah.
[21:12.000 --> 21:13.000]  No.
[21:13.000 --> 21:19.000]  So the way I've seen it required is, no, no.
[21:19.000 --> 21:23.000]  This is the first one.
[21:23.000 --> 21:25.000]  So the first one is, how is the supplier used?
[21:25.000 --> 21:29.000]  And the way I've seen it is mostly from procurement people,
[21:29.000 --> 21:34.000]  like asking for that information, and lawyers.
[21:34.000 --> 21:38.000]  So that's the model, the two that I've seen asking
[21:38.000 --> 21:40.000]  for the information more.
[21:40.000 --> 21:45.000]  I'm coming from the security side of Hezbollah more,
[21:45.000 --> 21:48.000]  so compliance is not my strong side.
[21:48.000 --> 21:51.000]  But that's why I'm suggesting it.
[21:51.000 --> 21:53.000]  At one point, sorry.
[21:53.000 --> 22:02.000]  Yeah, as one data point, the way that we are using supplier data
[22:02.000 --> 22:07.000]  is actually recording who supplies the software.
[22:07.000 --> 22:14.000]  So not who wrote it, not who created or something like that.
[22:14.000 --> 22:19.000]  If we got it from an upstream distribution repo,
[22:19.000 --> 22:22.000]  we put the upstream distribution repo for that.
[22:22.000 --> 22:26.000]  Again, record what we know, that's the only thing that I know.
[22:26.000 --> 22:32.000]  And so the other question is, so does the integrity point
[22:32.000 --> 22:34.000]  consider also signing of the S1?
[22:34.000 --> 22:37.000]  And yes, but not in this case.
[22:37.000 --> 22:42.000]  So integrity, like signing of the S1 is mostly done
[22:42.000 --> 22:43.000]  outside of the S1.
[22:43.000 --> 22:50.000]  And that touches on trusting the S1, which is a whole other kind
[22:50.000 --> 22:52.000]  of worms.
[22:52.000 --> 22:58.000]  But I mean, it is, but not in the contents of the documents.
[22:58.000 --> 23:02.000]  How can I make sure an S1 tiers to these principles?
[23:02.000 --> 23:08.000]  Is there something like benchmarks?
[23:08.000 --> 23:12.000]  Or I give it a score of 8.0 from 10.
[23:12.000 --> 23:14.000]  That's a good S1.
[23:14.000 --> 23:17.000]  Well, there are tools then.
[23:17.000 --> 23:18.000]  Yeah, I repeat the question.
[23:18.000 --> 23:20.000]  So how can I know?
[23:20.000 --> 23:22.000]  Sorry, I didn't get a lot of sleep.
[23:22.000 --> 23:27.000]  How can I make sure that the S1 really complies to these things
[23:27.000 --> 23:29.000]  here?
[23:29.000 --> 23:33.000]  So there are a couple of tools that do a validation of the S1,
[23:33.000 --> 23:36.000]  like scoring, try to do the scoring.
[23:36.000 --> 23:44.000]  So eBay has a tool called S1 Scorecard.
[23:44.000 --> 23:55.000]  Then there's the NTIA compliance checker from SPDX.
[23:55.000 --> 23:58.000]  I'm not sure.
[23:58.000 --> 23:59.000]  I don't know.
[23:59.000 --> 24:02.000]  Are the ender folks here still?
[24:02.000 --> 24:06.000]  OK, so I seem to remember that they were handling some of that
[24:06.000 --> 24:07.000]  as well.
[24:07.000 --> 24:10.000]  But there are a couple of tools out there.
[24:10.000 --> 24:14.000]  It's more like a remark, but it's a bit surprising to mention
[24:14.000 --> 24:15.000]  Open Chain that much.
[24:15.000 --> 24:20.000]  Open Chain, the goal is to trust from the suppliers
[24:20.000 --> 24:24.000]  so you can trust the S1's from the suppliers.
[24:24.000 --> 24:32.000]  So yeah, what Nico said is that Open Chain has touches on the idea
[24:32.000 --> 24:39.000]  of trusting the S1 on the supplier and those sorts.
[24:39.000 --> 24:42.000]  And in observation, this is having looked at Python,
[24:42.000 --> 24:45.000]  and the metadata that goes with Python packaging
[24:45.000 --> 24:47.000]  is really inconsistent.
[24:47.000 --> 24:49.000]  So how do you spell Apache 2?
[24:49.000 --> 24:55.000]  How many different ways of putting Apache 2 license is amazing.
[24:55.000 --> 25:00.000]  And actually, between releases, information disappears.
[25:00.000 --> 25:04.000]  So this is really a message for the ones who are in the ecosystem,
[25:04.000 --> 25:06.000]  put as much data in the ecosystem,
[25:06.000 --> 25:11.000]  and the metadata that you can, because this is going to support...
[25:11.000 --> 25:12.000]  Yeah, exactly.
[25:12.000 --> 25:14.000]  Yeah, the comment is...
[25:14.000 --> 25:16.000]  Because we were looking at a difference,
[25:16.000 --> 25:18.000]  and we've got a new release of a package,
[25:18.000 --> 25:20.000]  but there was one where there's a supplier gone.
[25:20.000 --> 25:21.000]  Right, exactly.
[25:21.000 --> 25:23.000]  And actually, the question is,
[25:23.000 --> 25:26.000]  do we just use that on your matter?
[25:26.000 --> 25:28.000]  Because we don't know where it's come from.
[25:28.000 --> 25:30.000]  Yeah, the comment is that in Python,
[25:30.000 --> 25:32.000]  sometimes between releases, information changes,
[25:32.000 --> 25:33.000]  or disappears, or whatever.
[25:33.000 --> 25:38.000]  So this is actually one of the things
[25:38.000 --> 25:40.000]  that some of us would like to see happening,
[25:40.000 --> 25:43.000]  like people working on packaging systems,
[25:43.000 --> 25:46.000]  on language ecosystems, to start,
[25:46.000 --> 25:51.000]  if not adding S-Bomb generation straight away in their tooling,
[25:51.000 --> 25:53.000]  at least expose the information so that we,
[25:53.000 --> 25:56.000]  S-Bomb toolmakers, can go in and extract them
[25:56.000 --> 26:02.000]  from more trustable sources.
[26:02.000 --> 26:04.000]  And...
[26:04.000 --> 26:06.000]  Okay.
[26:06.000 --> 26:07.000]  In regards to hashing,
[26:07.000 --> 26:09.000]  how are you dealing with custom patches
[26:09.000 --> 26:12.000]  when you apply to your live software?
[26:12.000 --> 26:13.000]  Can you repeat it?
[26:13.000 --> 26:15.000]  In regards to hashing,
[26:15.000 --> 26:18.000]  how are you dealing with custom patches when you apply it?
[26:18.000 --> 26:20.000]  So if you need to patch software you're using,
[26:20.000 --> 26:23.000]  but you can't apply the patch upstream?
[26:23.000 --> 26:26.000]  In the case of the...
[26:26.000 --> 26:29.000]  Yeah, just in the case of the distro, or...?
[26:29.000 --> 26:31.000]  It has a distro and a general response.
[26:31.000 --> 26:33.000]  Well, yeah, the question is,
[26:33.000 --> 26:35.000]  how do you deal with patched software, right,
[26:35.000 --> 26:37.000]  when you apply a patch?
[26:37.000 --> 26:40.000]  So...
[26:40.000 --> 26:44.000]  But, I mean, you still have that hash, right?
[26:44.000 --> 26:47.000]  Or is the question about naming...
[26:47.000 --> 26:49.000]  So what's the best practice, I suppose?
[26:49.000 --> 26:54.000]  Yeah, so if you're describing a patched artifact,
[26:54.000 --> 26:56.000]  I mean, the hash, simply hash the thing
[26:56.000 --> 26:58.000]  and you can use that downstream.
[26:58.000 --> 27:01.000]  The problem comes when you're trying to define,
[27:01.000 --> 27:03.000]  well, I'm using curl,
[27:03.000 --> 27:06.000]  but I applied a few custom patches myself.
[27:06.000 --> 27:07.000]  How do you name that?
[27:07.000 --> 27:10.000]  And that becomes, like, a more complex question.
[27:10.000 --> 27:13.000]  So internally, as I was saying with the integrity thing,
[27:13.000 --> 27:16.000]  is you can still reference everything with the hashes, right?
[27:16.000 --> 27:20.000]  Like, I'm talking about binary, this hash,
[27:20.000 --> 27:22.000]  all down the stream.
[27:22.000 --> 27:24.000]  But when you want to express it externally,
[27:24.000 --> 27:26.000]  well, I guess that falls into the naming problem
[27:26.000 --> 27:29.000]  and you have to think about where that thing is going to be used.
[27:29.000 --> 27:32.000]  So if that is going to be a package part of a distribution
[27:32.000 --> 27:34.000]  that you're doing,
[27:34.000 --> 27:38.000]  you may define your own set of package URLs, for example.
[27:38.000 --> 27:42.000]  Or if it's not going to be, you can make up the license,
[27:42.000 --> 27:45.000]  but it falls more into the use case
[27:45.000 --> 27:50.000]  of what you're trying to do with distributing the patched software.
[27:50.000 --> 27:52.000]  So that's it. All right. Thank you.
[27:52.000 --> 27:54.000]  Thank you very much.
[27:54.000 --> 27:56.000]  Thank you.