The last presentation that's not listed for the day, generating for build stream projects
yet another ecosystem by Abdrahim and the guest.
Don't move your ears.
Okay.
There you are.
So, hello everyone.
I'm Abdrahim.
I work at Co-Think.
And this is Dom Michaelig.
So, he worked with me on this project.
So, who am I?
I'm making of the Apache build stream project.
The project management committee member and I've been a PMC the chair of the PMC since December.
And I work at Co-Think.
So, what is build stream?
Some of you might not be aware of build stream.
So, it's a powerful software integration tool that allows you to automate the integration of software components, including anything you want,
from operating systems to a small application.
I test the following advantages.
Again, that's from the website.
So, it has a declarative build instruction definition.
In Neamo, it supports both the developer and integrative workflow.
So, we will do the same.
We will use the same tool for developers.
You can open our workspace.
That's what build stream does to work on the project.
And then you can build the whole operating system.
Imagine with it.
It's fast and predictable.
Especially because it isn't affected by what you have installed on your system.
Everything is in a sandbox.
It's extensible.
You can write plugins for anything you want.
We discuss the two kinds of plugins.
And we can use it to bootstrap tool chains and operating systems.
There's this project called free desktop SDK binary seed, which uses the live bootstrap.
To bootstrap from a very small binary all the way to a whole tool chain.
So, what does a minimal?
I'll go ahead and explain a bit about the build stream concepts.
Because I will need them because like when the previous presenter was talking about Swift product.
And the package is.
So, if you don't know the concept, it will be hard to follow.
So, as a minimal build stream project, we'll have one or more import elements to import the base tools.
So, that you have at least something in your sandbox.
Because by default there's nothing.
One or more build elements.
So, using whatever build tool you want.
So, there are plugins for auto tools, meson, cmake.
And you could write things for plugins for any other build system.
Then you have the compose element which takes multiple elements and puts them together.
And excludes allows you to exclude files you don't need.
For example, debug information or development files and headers.
And then we have an element to package them all, depending on what you want to do.
So, what you want to produce and always image the Docker image for whatever you want.
I flatback for a flatback application if you're on Linux.
And then we have a project you need a project that can file at the root of the directory.
So, we'll try to, well, not a whole project, but at least an idea of how that would work.
So, here we have the base image.
I am importing a Docker image from the free desktop SDK project, which is a project build with build stream.
And if you are building your thing with build stream, you generally use free desktop SDK.
You could use it at the build stream level.
This is what we call a junction.
But here for simplicity, I'm just using the Docker image that's produced by free desktop SDK.
So, the first line, the kind of the element.
So, this is an import element, which just takes its sources and puts them as is into the artifact.
Then we have the list of sources, and we have one single source of kind Docker, which downloads the Docker image.
In this case, free desktop SDK slash SDK.
We haven't specified the URL and so it's from Docker Hub.
And then the graph here is the manifest digest of the image.
So, it is exactly the image that you, you have to specify the image exactly.
You can just give it a tag and ask it to pull whatever is the latest image in that tag.
So, you have to use the exact shaft to 56 manifest digest.
So, here is an example where I use the Docker image, but it could be a tarboard, a root FS tarboard,
generated by the bootstrap or anything.
It doesn't really depend on Docker on it.
So, we can do the same thing with platform.bst.
So, for free desktop SDK platform, which is, these are used at the flatback manifest.
So, the SDK contains the compilers and things like that, and the platform only contains the runtime.
Then we have built elements.
For each element, we have, again, the kind, auto tools in this case.
So, that's the plugin, in question.
So, here we have the auto tools plugin.
If we'd have Mason, C, Mac, water.
The sources here I'm using GNU hello.
So, it's a tarboard.
So, kind of tar, the URL and the share to 56 of the tarboard.
And I have built dependencies and runtime dependencies.
Here, I'm using the platform and SDK that we imported before, but you could depend on other build elements that you have built it.
Then the compose element.
In this case, it's not really useful.
GNU hello doesn't really have much tons of development files.
And we didn't add instructions on how to split the debugging formation.
So, it won't be excluded because it's integrated in the binary.
But this is how you would do it in general.
And then we can have another element to package the result in whatever you want.
And OCI image, this image, flat back, whatever.
Yeah, this is something that I said.
But there is an OCI plugin that is unmaintained.
But there is script element, which is a core plugin in build stream, which allows you to run any command you want.
So as long as you have a tool that can generate OCI images that doesn't require privileges,
so it can run in the sandbox, you can use it.
And then the project.com, not much to see here.
The name of the project, the minimum build stream version needed and the plugins.
In this case, we've used O2 tools and Docker, which are part of the build stream plugins collection, which is a collection of plugins,
made by the build stream project.
We haven't, you may notice that we haven't declared all other plugins, like the tar, the import, the script we haven't released it.
And these are core plugins. They are part of build stream, then we have build stream plugins, which is a collection of plugins,
made by the build stream team.
Then we have another project build stream plugins community, which contains community plugins.
So what we can see here is that build stream should know everything about all the sources that get into the construction of whatever artifact we have.
So there is no, nothing on the system that build stream doesn't know it, that affects the artifact.
So it should be able to generate a complete as one, right?
So there are a few challenges here.
So the first one, just knowing all the tar balls, the Docker images and the Git repository,
commit that get into the build isn't enough, because people expect more information of the BS1.
For example, version numbers, dependencies between various components, licenses, and many other things.
Some of them, most of them are considered optional, but...
But later, someone may consider something to be very important.
For example, the license is sometimes very important.
So we can't really say that optional.
So the solution you have implemented with build stream 2.5 is to allow the source plugins,
so like the Docker and tar in these examples, there are other source plugins for Git for things like that.
We asked them to provide this information about sources, rather than having a single tool that tries to know everything every possible plugin.
So build stream can also ask the plugins for this information, and we can display it as Yamu, which can be consumed by other tools.
So here's an example. So this is coming from the Git repo plugin, so that's the kind.
It gives us the URL, the medium, it says that it's a Git repository, and this version is a commit, so the commit hash.
Then it has a version guess, 2.42, and it's allowed to give more information.
And in this case, it gave us that it guessed the version from the tag that's called GLipC2.42.
But there are 48 commits ahead of that tag.
That's some information that the plugin can give us, we can try to make it into an aspa.
So this is using this, where we developed a tool called build stream aspa, that you're on inside your build stream project, and that can generate an SPDX format aspa using that information.
Something to add here is that the dependency information is was already available from build stream, so this is more information that we can get, and that we can use to generate an aspa.
Another thing that's, I'd say in progress, we allow the author of the build stream project to add more information to the sources.
So whenever we have with the clear source, like Git repository or a tarball, we can add some more information here.
For now there is this homepage and issue tracker, but because that's something that came up, but we are working on making this more generic and allowing a lot more information to be added by the project author.
We can come back to it.
So this comes into the, this gets added to the source information.
That's another example, but yeah.
Another challenge we faced is marking the build stream concepts of elements and sources to SPDX.
So SPDX has packages files and snippets, I'm not sure exactly what snippets are, but at least we have packages and files.
It looks, yeah, and build stream is not a package manager, so we don't really have packages.
So what we could do, the closest I could come up with is mapping elements and sources to packages.
So each source is a package, each element is a package, and then we add the relationships generated from to link elements to their sources and the depends on to link the dependencies between the elements.
Yeah, but not all sources are packages.
We have sources, anything that gets into the build has to come in via a source and even things like patches.
I take this star ball and I patch it, that both of these are a tar source and then a patch source.
And this is something we hit recently is that these patches, they're not really packages.
Yeah, I don't know, they should be.
Yeah, it's a single file, this case.
Yeah.
Yeah, that's all, thank you for.
And yeah, I would like to open the floor for comments, suggestions, questions, whatever you may.
It's a good lab, yeah.
It's a good lab, it's a good lab, so good lab dot com, build slash build stream, slash build stream as well.
Thank you, thank you, great.
So basically what you're doing, there is similar, just take little line in the clear and get it like fish.
So the data that you're collecting there is essentially what goes into us as a
statistician to generate real provenance.
Do you support that? Have you planned on doing that?
We don't have a plan to do that, but...
Yeah, exactly.
Yeah, so because the data is the real data station, it's exactly what it does.
All of the inputs, and then the formula that you applied to them, which you've already
had them as well.
Can you go back a couple slides to when I was sort of about to say something?
So if you go back to that one.
Yeah.
Are there things that you think we should make sure we can capture for the provenance?
Like, I'm sort of wondering, like, vulnerability, notifications, things that so they can get populated and
instantiated into these S-bombs for contacts and things like that as part of the agent stuff.
Yeah, the security, like, the security relevant information.
Yeah.
So one thing that we definitely want to have regarding security is the ability to map this source
to a P-O-R-L or a C-P-E.
Yeah.
So that we can use the output S-bombs to pass it to another tool to extract vulnerabilities,
which currently working on using, on making sure that our S-bombs can be consumed by C-B binary tool.
Okay.
And that's, that is our plan regarding that.
Okay.
Yeah.
I'm just sort of thinking that since you're actually taking in might, pulling in some of the data,
there may be some things to enrich the quality of the final S-bombs that you've
been captured in a standard way and then set up a precedent for other projects to do.
Yeah.
We are both C-B's.
Yeah.
What's the motivation for doing this?
Never, I'm not know what build stream is.
Yeah.
But what's the motivation?
What's the motivation of having S-bombs anyway?
Yeah.
I'm fine.
I've got some pain.
That's absolutely amazing.
Okay.
That's as important as it is.
Yeah.
Thank you.
I think.
I was just wanting to reply to the answer to that in terms of both spaces.
So actually, I mean, I'm in the middle, but I also think that using those three,
I mean, I do some of these and all of these for our customers.
So what we're doing is, is we're then embedded devices where we might be using
courses of images for these and we need and not customers.
Yeah.
We need to have all these information, but doing this is such a way that they can do this
of a single Python.
So in build stream, essentially, as I'm there again, as a speaker, laid out this,
you can put all your sources in that.
And you can use all your videos using a single system image of single source of truth.
So that for this tool, it can be very important because ultimately, you can also
just take that files and to use high quality assformers.
You know, I was, I had a player being in the track earlier.
Today, here I'll be added to that.
This is one.
What do you summarize that for the mic?
Yeah.
That's a good thing long.
Okay.
So the comment was that, yeah, people actually use that to actually produce images.
And having a single whole build set up that can also generate complete
as an accurate response, it's definitely a plus, right?
All right.
Let's thank again.
The speakers.
Thank you.