Transcript for "Learning Labs: Chainguard Libraries (May 2025)":
about to get started. I'll give it another minute. Welcome to everybody who's joining so far. I see we have Mexico, Los Angeles, San Francisco, Tennessee. Yeah. I guess people in Europe would be a bit later in the evening. So for them, it's like dinner time or something. So we'll see if we have someone joining from around the world. I guess Budapest is already there, so that's awesome. So we do have some European. So, yeah, for those of you who who it is late in the day, we will also be sharing a recording of this after we do this session. That will be that will be shared in the emails to folks who signed up, and, also, we'll have it on our YouTube in a few days after. Awesome. I think we could start getting started here. So thank you everybody so much for joining. I am Lisa, and, I'm here to introduce Manfred, who will be sharing the good word about Chainguard libraries, particularly on on the Java libraries. I wanted to also make sure people know that we also have Python libraries, which we just announced today. And I will put the link to that blog and the docs in the chat, when I'm once I'm done talking. So we're really excited about that. And for folks who may be joining, PyCon in person or online, we will be there to talk about, Python libraries too. And we will talk about, Python libraries in the next learning lab session on June 24. We will send out an email about that, but just mark your calendars if you're interested in Python. And I'm so excited for Manfred to talk to you all today about Java. This is really important, piece of the software supply chain ecosystem. And it's been a little while since I wrote anything in Java myself, but I'm a a fan of Java. I'm a fan of Manfred. So I'll hand you over to him. Alright. Thank you so much for that great introduction, Lisa. You already spread the news about Python. That's awesome. Don't get distracting reading those blog posts, everyone, because, like, first, we wanna learn about the fundamentals and so on. So, as Melissa mentioned, my name is Manfred Moser. I'm an open source hacker, writer, teacher, presenter in all sorts of ecosystems. As you can see here, I'm also a mountain biker all year round, including winter. I'm up here in Victoria, BC. And I hope to teach you a lot today about Chainguard libraries for Java. So what we'll do is we'll start with an introduction a little bit. We'll then talk about fundamental concepts in the sense of what the library even is, what's used, and then, bring the Changer context into play. And then we'll talk about the specifics for chain guard libraries for Java. And I'll give you all a demo, with Apache Maven and Sonatype Nexus as a repository manager. And, of course, anytime during the, event, please do use the chat system of Goldcast. If you have any questions, Lisa will potentially interrupt me or will also spend some time afterwards. So, bring your questions on. It should be a great fun ride to see what we are talking about. No. I don't know what this slide is doing. So we had a safe source for open source at Chainguard, and we are built from a big community of very good engineers, and, leaders that have a long experience in the open source system, and that has, resulted in many, many customers across the industries trusting us to secure their supply chain. Our main supply chain securing is our Chainguard containers. You see here there's many, many containers available. Cloud native running your applications is the default these days. Right? Like, you run your apps on some cloud provider on Kubernetes, and those containers are, very useful for that because they are built in our Chainguard factory, which is, salsa's, level two, certified, very secure, and, everything is built from source. And they are optimized for a much smaller attack surface than, the default containers that you typically get from the project or from Docker Hub. We also have a SLA for CVE media remediation and, typically, they contain zero CVs. But the main aspect is that we control the whole supply chain for those containers in our Chainguard factory. And that's a very complex infrastructure that we run-in the cloud where we build everything from source. So we take the upstream. We find out where the upstream code is. We monitor those codes. We build from scratch and make sure all the dependencies are updated. So our Chainguard containers are minimal in terms of footprint, what's on them, but also what's on them is constantly updated and secured. So, including having SLAs for security patches. So you can rely on a a stable build of your containers that have a much smaller attack surface and also are much smaller in terms of overall size. So you'll even get some performance benefits and, like, reduced costs because the containers that need to be provisioned are just generally smaller and, also then, therefore, ultimately start up faster in a big cluster and stuff like that. So, it's very good to use Chainguard containers in your infrastructure. And so secure containers are really awesome, but what's inside those containers is kind of like the next question. Hopefully, your containers are not like that, like a black void with nothing inside. Your containers are hopefully a bit more like that because your containers in your cloud environment probably run your own applications that you've custom written. Here are little cardboard boxes inside the container. But what's typically the case is that these custom applications that you write, they have more stuff inside. And those pieces that are inside are what we call libraries, and we'll talk about this more. Beyond the containers, however, you have to keep in mind that libraries are also used to write all sorts of other applications. Right? Like, no matter if this is like an on prem deployment or some embedded device or, whatever hardware or software this runs on, any application you build these days is probably taking advantage of all the work from the open source components, and community so that you can deliver the benefits for, like, you know, like a live UI or whatever much faster than you would if you had to rewrite everything from scratch all the time. So a library is kind of that those building blocks for your applications. They typically deliver a sort of narrower feature set. Some of them are, like, actually provide very large feature sets. But, typically, they're, like, they focus on one aspect such as, like, logging or telemetry or, like, maybe you have, like, like, a website and then it focuses on image generation or passing JSON files and so on. Right? So, there's many, many of those libraries around in the different ecosystems. That's actually a strength of those live of these, ecosystems that the more of those libraries are available, the more it is, easy to get started and deliver pretty significant, feature sets without having to sort of, like, reinvent the wheel and concentrate on low level, algorithms or anything like that. You can just focus on your business functionality. So in a typical application, well over 70% of your code base, so to speak, is actually like, the feature set is delivered by those libraries. And most of those libraries are open source because, there's not much business value, for an individual business to to, like, sell logging software or, like, telemetry. So, companies and then also individuals collaborate and distribute them as open source. There's also commercial libraries, but they are not by far not as well as widespread. The other thing I wanted to mention that's very important is library is just the name we chose for Chainguard libraries. But all the different ecosystems come up with different names for this sort of, like, same concept of having a, like, reduced specific functionalities yet available in a in a binary that's, available for you to use. And so what's other you otherwise often use as terms are things like component or package or even a framework. Framework often is also used for, like, a bunch of libraries together that deliver more functionality with cross cutting concerns, like maybe a web application framework that then has multiple libraries. Sometimes also a toolkit or a dependency, an artifact, a module. All these terms are kind of synonymous to a large degree and have a little like, if you go down in the deep deep technical aspects, the the meaning changes a little bit on each ecosystem. But in a nutshell, they all provide this kind of, like, a feature set that you can reuse. And they come in all shapes and sizes and all in the different ecosystems. Now today, we're gonna talk about the Java ecosystem as, Lisa mentioned in a month's time or so. We'll talk about the Python ecosystem. But they today, we talk about the Java ecosystem, which both of those ecosystems are actually very, very widely used. Java as such is a language and a run time. Typical terms that you might hear or know about are the JDK or Java Development Kit. So that's the kind of tooling to build these applications, including compiler and, class libraries and that kind of stuff. Then the Java runtime environment, and then importantly, the Java virtual machine. So that's the that's like sort of like a virtual mini computer that can run the code, on any operating system, typically on Linux, but, like, can also run on Windows or or Mac or so. Important for all these aspect is that the Java ecosystem is is very large and includes more languages than just Java. So there's also Scala, Groovy, Kotlin, and the whole bunch of other languages available. So the ecosystem is very big in terms of the language footprint and also in terms of the, like, libraries available from, like, old big libraries like Apache Hadoop or the Eclipse IDE or JetBrains IntelliJ IDEA and their Kotlin language. So there's lots and lots of open source communities available, and, around that provide libraries. There's also many vendors, obviously, that, distribute the Java run time, and JDK and Java virtual machine, but it is also available as open source. So you can learn something like Eclipse Tamarin or you can get Azul or, Amazon Coretto or so. So there's different runtimes available, but all of those are compatible with Java, the sort of run time. And so in this ecosystem, because there's so many libraries, we'll have lots of them to choose from. So these libraries provide functionality in Java that go beyond the default package space. So there's, like, these like, built into Java itself. There's things like java dot lang or java dot util. These are package spaces that provide a lot of functionality out of the box without any libraries. So that's actually one of the strengths of Java that, out of the box, it already has a very rich ecosystem of class libraries that are built into Java. But Java goes beyond that. It provides lots of dependence, lots of additional features in, typically, char files. So a char is a Java archive file. It's just a zip file that has metadata typically in it, that's required, then plus resources if if so desired, and then the compiled class file. So when you get HR file, that's just you can literally open up with a zip and look look inside, and then that's the files you'll find. There's also other file formats available in the char ecosystem like a war, which is a web application archive. But the most common one is the char file. That's what we'll typically focus on today now. How do you get this char? Well, you can build it and with your build tool, and you can then also potentially if it's a runable char, you can run it with the travel command, but all that's kind of hidden in, like, tools like Apache Maven or, other build tools. But the distribution of those JAR files as binaries is what we'll talk about some more. So these these libraries, they're typically generated from source code. Right? So you can do that yourself if you're on a project yourself or build. It will produce those jars, and I'll show you some later. And then they are however, from the open source projects, when they write these source code, projects with which implement a specific functionality, they are then typically consumed as binaries. So they are consumed as these JAR files. And in order to do that, you typically just declare them as a dependency. So you basically in your build tool, you say, hey. In addition to the normal Java stuff that you have, I also need this other thing, as a dependency. I'll show you later how that looks like. Depends a bit on the build tool. But, essentially, you just give it a unique identifier, and it then will know where to get it from. The complexity comes in place because, typically, dependency have other dependencies. And they, called transitive dependencies often. And then those transitive dependencies can also have dependencies which are further transitive dependencies. So what that often means is you end up in this kind of, like, dependency tree, or web or directed graph is what it's, like, technically really called. Can't have any cycle cycle dependencies. But, essentially, all these dependencies, are pretty easy to declare because you're like, I just need this and then the build tool will pull it in. But they need to be pulled in to your artifact and, then potentially needed at run time. So that makes it quite complex, to to look at in the end. And I'll show you with a pro example project how many that can potentially be. You might declare, like, one or two dependencies and find that well, actually, you end up with 30 or 40 being pulled in. So, you're potentially dealing with a lot of those libraries. And they all come, to your system sort of, like, transparently by just running a command. Long in the past, when Maven was the first tool, everyone was always complaining that it took so long because it downloaded the Internet. These days, no one complains about that anymore because tools like Python and JavaScript got worse. They they download even more than the old Internet, so to speak. But, our our performance on the computers in the network is also much faster. So not not as much as a problem as it used to be. So in a typical, like, life cycle of this package, let's see how this ends up with you as a developer. Right? Like, there's some distinct stages. Right? Like, here's the open source maintainer. Might be me or might be, like, many, many other people out there that write this open source project. They have source code on the computer and they, need to build this. Right? So they build it on their laptop or on GitHub actions or wherever. And then then those bills need to be they result in a binary, and that binary needs to then be transferred from, like, from that build artifact. It needs to be transferred over to an to a system that distributes it to developers in the Maven in the Java ecosystem that's Apache Maven's Maven central repository. And so once it's in that distribution channel, then you can consume it as a developer. And all these different phases have potential, attacks. Right? Like, someone could tamper with the source code, tamper with the build pipeline, with the build itself, with the CICD system on the way, or then with the distribution from the CICD system to the distribution library system, and then all the way over even to your consumption in your organization. Right? So there's a lot of potential phases in that software supply chain that are potentially, vulnerable. And in fact, all of these different, phases have been exploited and are being exploited by attacks. So what we do with Chainguard libraries is we cut a whole bunch of these things out. So all of these things, build distribution dependencies, are cut out and taken care of by Chainguard. Right? Like myself and and hopefully also Linky, will help, with the factory to build from source. So what we do is we take the source of the relevant open source projects, and then we completely handle the build of these artifacts in our Chainguard factory. And then we build the binaries. We augment them with further information. We sign them, and then we make them available as a distribution to you directly. So all the attacks that go on those different phases in between fall away, and become meaningless. They also, interestingly enough, also a lot of attacks, not so much in the Maven ecosystem, but especially as on the Python ecosystem and JavaScript ecosystem. There's a lot of attacks also on the source code itself. So people publish binaries that are, you know, to crypto mining or some, identity theft or whatever. They're also typically not published with source code. And if that's the case, and that's typically the case, these systems might bypass and get into the public distribution channels like here, but they won't get into the Chainguard fact in the Chainguard libraries because there's no source code. Right? Like, if you're, like, writing and exploit and stuff, you're not gonna put that as open source tool on on your public GitHub account or somewhere. You're gonna hide that away for sure, and point your deployment to some fake source code. And you can do that with these other publishing pipelines. But because we go and cut all this out and go directly to the source code, all these malware infestations and, like, typosquatting and stuff like that, they all disappear as well. So Chainguard libraries for Java provides a very secure distribution for the libraries directly from the open source project without all the flaws of the supply chain in the way. So in the Java world, we said we declare those dependencies and they have to come from somewhere. And that somewhere is called Maven Central. It's built into the Apache Maven build project, has been around for a long time now, well over a decade. And it allows you to define these dependencies, and then the build tools automatically retrieve them from repositories. And the the Maven central repository is actually built into Apache Maven. It's also built into other build tools like Gradle or SBT, and they all understand this format as well. There is other repositories you can also use, but the main one is Maven Central. It's available at repo.maven.org/maventwo. There's also search index and stuff for that available, and that's where those binaries come so from. So this distribution, library distribution in the Java ecosystem is Maven Central. And Maven Central is a repository. So what's a repository? We need to understand that because, that's where those binaries come from. So a repository is just the storage of libraries. It's really simple. It enables you to get binaries into that repository, and then other tools can get them out. It's like a storage system. For the Maven ecosystem, the Maven repository format is used so that these, identifiers called group by the artifact at the inversion that are basically establishing, like, a coordinate set. Group ID, you can think of that like the name of namespace for your organization or the package space in Java. Artifact ID is like the name of the artifact itself. And then version is well, the version, the release number. And that those three coordinates, we basically create a directory structure. And if you go to the Maven repository, and we see that later, you'll see it's just a directory structure with a bunch of files in it. Important to know in the larger context also is that a repository is is again, just like library, it's a name for this concept of storing a bunch of libraries. Well, other names are basically the same thing. So there's this name that often comes up as a registry, especially, like, for example, with Docker. It's a Docker registry. Well, guess what? It's the same thing just for Docker containers. So, it's ultimately very similar. There's also, like, if you go way in the past, there's something called an archive. So the comprehensive pearl artifact archive network and stuff like that. So there's these different terminology, but, ultimately, it all boils down to the concept of a repository. And I'll I'll show you in a sec why this is also important because, there's an application that helps you with them. But before we go there, we have to talk about how those dependencies get into Maven Central. So as I mentioned, the Java ecosystem is very, very vibrant. There's lots and lots of maintainers. I've been in this community a long time, And I still know, like, only a few stakeholders and the constant change as well. So there's the whole Apache software foundation, the Eclipse foundation. CNCF has lots of, Java based projects as well even. So there's lots of those and then there's many other stand alone projects as well. And all of those different maintainers sit all around the globe, have their own workstations, have the source code in various different places, build on CI servers in the cloud or not in whatever country they are at or somewhere else. They use different build tools. The common ones are Apache Maven and Gradle, but there's quite a few others just like there's more languages. There's also more build tools. No surprise there. Right? And there's different rules around those artifacts, how to get in, so you have to own the name space. And for Maven Central, it's also actually possible to publish proprietary, artifacts into it with no source code as long as you can distribute them. This is super useful for for binary distribution of, like, drivers to commercial software, but it's definitely not open source in that sense. So there's no source code available. So, Chainguard libraries for Java will not distribute those as well. So you don't accidentally fall into, like, a for pay kind of software need or so as well. So central Maven central is very large and has all these artifacts available. So what is Chainguard libraries for Java then? Well, like I mentioned, Chainguard libraries for Java is a rebuild of those packages from Maven Central. Some of them have been there a long, long time and, are dubious how they got there, but they are there. Right? Like, it's an it's immutable artifacts. So once that they are, they are there. We are rebuilding them from source, from scratch, basically, in our Jenga factory, secure infrastructure. So, all the old stuff that's necessary is available. Or if it's missing, it is being built on the fly automatically. So if there's something that's not yet available, we'll go back automatically and rebuild it, and publish it as well. And new releases are also constantly added. So we, monitor the feed of what's new in Maven Central, and we then build those and add them with our additional information, like where it was built and signed by us and so on. But it's only open source. There's no commercial code available. And also no malware, as I mentioned, because, well, there's no source code for the malware. So that's really awesome. So that's Chainguard libraries for Java, and it's been a rough a while. And, it's been working really well already. So so how do you use Chainguard libraries for Java? Well, you need what's called a repository manager. Anyone any organization that seriously is using, Java or languages out of the Java ecosystem in the organization really has to, should be using a repository manager just to manage their own binaries as well. So a repository manager is kind of like an application that allows you to operate multiple repositories. Right? So these buckets of multiple libraries for the different ecosystems and also for different use cases can all be managed in a repository manager. And if that's basically our best practice for any large organization. And these repository managers just have to support the Maven repository format, which they all do. And then there's kind of three different types of repositories that typically come into play that we'll be using. So one is the proxy repository, which is a repository that acts as a local cache for repositories elsewhere. So for example, for Maven Central, and we'll create one of those later. There's also what's called a hosted repository, which is like a permanent storage for private artifacts or, like, you know, like, artifacts that you build yourself. Right? Like, if you build an enterprise application yourself and you want other developers in your company to reuse the private library also, then you just have a hosted repository. You deploy your your private packages there, and then they can use them. Right? So it's just like Maven Central, but in your organ organization, you can have a hosted repository. And then there's a group repository or also sometimes called virtual repository that just combines them all under one URL so it's easier to use. So that's the repository manager basics. And, there's a couple of big players in this field. You probably saw or heard of them. Sunnatap Nexus has been around a long, long time, same as JFrog Artifactory. Both have very wide user bases. CloudSense is a bit of a newer entry, and Google Cloud also has the artifact registry. So those are the the main repository managers out there, and they all provide the functionality to do what I just mentioned before with the Maven format. In terms of the developer tools on the Java ecosystem, there's kind of two main ones. Apache Maven, I already mentioned. Gradle is also a big build tool. It's a bit different, has been very successful in the Android ecosystem from Google. But there's also a bunch of others. There's something called SPT or Scala or SimpleBuild tool depending on who you ask. It's out of the Scala ecosystem. There's Bazel out of the Google ecosystem. There's the old Apache Ant as well, and there's numerous others as well. But in a nutshell, it doesn't really matter too much. They differ a bit how they work. And as I always say, every build tool or any tool really is terrible once you know it better. So there's really no right or wrong choice. Personally, I would always choose Maven, but that's just me. Right? All of them understand the Apache Maven format, however. So you're good to run that format in your repository, and that's also what's Chainguard libraries for Java uses. So let's go and play around with this a little bit. So in our demo, I'll be using Apache Maven as a build tool. I'll be using Sono type Nexus, to, basically proxy the chain cut libraries for Java repository. And in order to access, I have to talk to Linky, with chain control to grant me access. So that's what we're gonna do. So let's go and get access first. So in order to get access, we can jump over here. I have to first, do my login. So what I'll do is I will go here. I can go and log in. So you have to have an account with, Chainguard, and luckily, I do. You see it will authenticate me if the Internet is willing. Woah. What's happening? Oh, come on. There you go. So I was successfully authenticated, and I got my token here. Now what I can do next is I can verify that my organization has the right entitlement. So, just like every custom every customer basically needs to have access to, that. And you can before you go ahead and try to set this up, you might as well verify it. So you use this command to look at the library's entitlement. And you see, I'm with the Chainguard e d u organization. So we our team, including Lisa and Patrick and Adrian and others, we're we all have access to the Java ecosystem under this identifier and also to the Python ecosystem under this identifier. So, we are good to go. Now in order to actually use this identifier, in the repository manager as an authentication, I have to get what's called a pool token. And I'm just gonna get this pool token here. You see, this pool token will only last one hour, and it only works for me anyway because, you have to also authenticate. So, you see, I'm authenticating to request a pull token for the Java ecosystem in the Chainguard EDU organization, and I just gonna get this valid for an hour. And then here's my super long username and password. And I will need that now in my setup. So what I have to do next is so you see we verified the account is good. We verified that the organization is entitled to use, the Chainguard libraries for Java. I have the example test here. In my case, I used our EDU organization. And then also the access token. You see here the access token, this is this value of 8,700 six hundred and seventy hours is one year. So if you wanna have it last longer, then you would wanna do something like that. Or you institute a process that updates the token regularly. You can look in the Chainguard console to see when it's expired and stuff like that. But, like, for the demo, I just set it to one one hour, and that should do. So now what we need to do is we need to configure the repository manager. And what we'll do is we'll configure one proxy repository for Chainguard libraries for Java, which is available under this URL. Oops. Sorry. Under this URL libraries.cgr.dev/java. Guess what the URL is for Python? It's slash Python. And then for, another proxy repository for Maven Central as back backfill. So any binaries not available will not fail my build. So for developers, it's gonna be very nice because they won't even notice a difference. They'll just suddenly get, more secure binaries. First and foremost, it's a, as a priority. And then last but not least, we'll create this ordered group repository that prioritizes the chain cut libraries for Java above Maven Central. Over time, we'll also be able to potentially get rid of Maven Central completely and just rely on Chainguard libraries for Java, but not yet today. So now let's do that in our repo managers. I'm gonna jump into my browser window here. Now this one. Where's my browser not gone? Alright. So we go here. I have Sono type Nexus running locally here. And you see this is the user interface for a non administrator. I have to sign in as administrator, and then I can see the repositories I set up here already, are, like, my testing repositories, but I'll set up new ones. So I'll go here to repositories, create a repository, and you see, SolnetApp Nexus supports lots of different formats. Next time when we do the Python demo, we'll use the PyPI format. Maybe sometime in the future, we'll use the NPM prop format. But today, we'll have to have a proxy repository in the Maven two format. And we'll call this central. So this is the one we set up for Maven central. By the way, I'll go here to the documentation, to Java, global configuration, Sono type Nexus, initial configuration. This has all the steps by steps right here. Super easy. So I can just be lazy and do a cut and paste instead of typing this out. Because if I type this out, what will happen? I will mess it up. So keep it easy. That's it, really. Right? Central, the repository for Maven central. Everything else is already, like, as we want in the default, so we can keep this super simple. So we have our central repository. Now remember, next step, we need to do the same for Chainguard library for Java. So create repository, proxy repository again here. Now this one we call Chainguard, and the remote storage will take over from here is, like I mentioned earlier, libraries.ggr.dev/java. So I'll copy this, put it in here. And, of course, remember, this is a private repository that not everyone has access to, so we need to go down here to HTTP, add authentication. And now I need to go and cut those cut and paste those long strings. So I can go here, paste the username, and paste this awfully long secure password. Don't try to remember that one. And I'm gonna create that repository. Now I have the two repositories here, central and Chainguard. Now I'm gonna create one that combines the two, which is that group repository. So maven group, and I'm gonna call this Chainguard dash Maven. And now I'm gonna just set this up to add chain cut first. Right? So that's the one I want artifacts to be retrieved from first and foremost as the main priority. And then second one, I'll add central, and upgrade this repository. Now we can go over to the user interface for normal users as well and see that currently, it's super empty in central. It's super empty in Saint Cloud, and also Chainguard Maven is super empty. So, how do we fill this? Well, it's a proxy repository, which means something needs to contact it to say, hey. Give me that that artifact x y zed. So, that's what we essentially need to do. And in order to do that, we need to go back here and do our next step. And that is on my workstation. I have to configure a file, in this case, for Maven, called settings dot XML, which basically tells Maven, hey. Don't use the default. Get it from over there. And it will point at that group repository. If Nexus were having authentication, it could also add authentication there, but I'm not. So what we can do is we can go and look at that file. So I'm going here to dot m two. Where am I? Sorry. Scroll down too much. Settings dot XML. And you see there's this XML file. It's a longer settings file, but basically it says, here's the mirror. And I'm just gonna change this to chain guard Maven. This is what I had earlier. This is the new one we created. And then what this does is, like, says get everything, every artifact from this mirror, which is that URL, and then there's a bunch of overrides so that Maven doesn't think it needs to get things from elsewhere. And here's also the authentication, which in my case is commented out because I I set an enabled anonymous access in my Nexus server. That's it. So that was already it in terms of setting up my build tool. And now that will work for every project I build locally. So let's go and look at the project. So I have a project called Twingo Gateway here, that, we can build. Before we do that, though, what we wanna do is we wanna wipe out what's called the Maven repository, the local repository. So if you look here, we wanna wipe that. This local repository is in a directory called dot m two, same where the settings file was, and it's called repository. And that's a big, big directory structure which has all the downloaded artifacts that were there from from my past use. And there is many of them. So I'm going to wipe that out so that we can trigger oops. No. I don't know why I did that. And this is completely harmless to do. It's just a cache. Right? So, it will, just wipe those files out, which then in turn will allow us to go and trigger a new build so I can go use this. So if you see here, we'll look at my directory structure. We have this palm dot XML file. And let's look at that palm dot XML file. But before we do that, I'm gonna kick off a bill because it's gonna take a while. So what we'll do is we'll kick off a bill without anything. And you see, it just kicks in, and then it starts downloading artifacts from Chainguard Maven. And it downloads all the dependencies it needs, including, like, plugins and dependencies off dependencies and so on. And that's gonna run for a while now. So we'll let that run while we go over here into my IDE here and inspect this a little bit. So this palm dot XML file here defines a a whole bunch of dependencies here. Right? So there's airlift, j d b I, test containers, airlift glass switch. So these are the dependencies that are declared. And then in the sub module gateway h a, there's another POM file that defines more, right, like this, or zero, Jackson for adjacent parsing. There's Google error prone, Guava for dependency injection. That's there's a whole bunch of dependencies. Right? So this is like a semi complex application. It's not that complex, but you see it already has a bunch of dependencies. And so here, the download is basically going crazy. Downloading a whole lot of artifacts and building and building and building. And then next time, it won't have to download them. But we triggered this now because if I go over to my repository manager now, if I find it, you can see, chain got libraries for Java in action, because I can go here. And now if I browse here and I go to Chainguard, you see, these are the artifacts that got downloaded. So, you see, it's downloaded. Say here, for example, the Java x inject jar file. So the individual, artifacts that got downloaded are all jar files or palm files, which are these palm dot XML files with the different, like, renamed, following the Maven repository formats, definition. But those depend those define the dependencies of the dependencies. So that's how Maven and other tools know what to download, and it's just busy doing that. Right? So you see here lots of Apache ones. And you see this is the dependency description that you would use in your palm file. And then also for interest, by the way, if you look at other build tools here, there's a whole bunch of them that you can see the same definition for the same artifact but in a different, like, build tool language. Right? Like, they all ultimately use those identifiers, and that those are, as I mentioned, group ID, artifact ID, or name and version. So those group name and version are the, like, identifiers for it. You see there's, like, lining and event and stuff. So lots lots of different build tools, and they're slowly for flowing up. You can also see that some artifacts got download from Maven central because we don't have them yet slash we are in the process or, more importantly, also the source code might not be available. It might be so old that it's not there or, anything that fail, like, is not being retrieved will automatically be rebuilt in our infrastructure shortly. And like this keeps going now, what I'm gonna do is I'm gonna cheat a little bit because this will take too long. So what I'm gonna do is I'm gonna go and in order to show you, I'm just copying my old repository back in place. Because what I wanna show you is we wanna go and look another command that's called Maven repos dependency list. This lists all the dependencies. So here you see all the dependencies that were defined in this project. Right? Like, there's a whole lot of them, and it's pretty complex. But that's a whole lot more than was defined in the palm because this is the list of dependencies that were declared and then the transitive dependencies. If you wanna see the transitive dependencies, we can use dependency three. Oops. That was the wrong command. So we use dependency three. And you see this shows you the definitive dependency tree. So you see here, there's a declared dependency for testing necessary test containers, and that one in turn depends on comments, Apache comments, compress, then this duct tape. But duct tape then depends on the chatbot annotations, or there's the GitHub, Docker, Java container, which contains on depends on the transport, depends on the Docker, Java transport, and then on JNA. So and we see there's a whole tree of those. So the transit depends dependencies really come in to make this much more than you initially think you'll get, and we even sorts out all the duplicates and stuff for that. But nevertheless, you end up with a lot. So libraries are very, very crucial for your application. So you see, how we got those chain cut libraries for Java. And, on the client side tool, this is the kind of accumulated Chainguard Maven that has everything in it that we loaded. So we built successfully. How good is that? So we built with Maven install. It was everything was defined in the palm dot XML, and then we did the dependency list entry, with the Maven command line tool. So as a result, we have all the libraries in the local in the local repository, that cache, but also Nexus. And I saw, the differentiation. Right? Like, you can look in the Chainguard library to see everything that was retrieved from Chainguard, And in the central one, everything that was received from from central, and the accumulation is that group repository. Those artifacts can also be verified. So if you download all the necessary files, and I've I've done that prepared that already for you. So we can go can go to this directory. I'm cheating here. So this is like a download of all the checks and annotations to seventeen one file. So that's the the JAR file. But you see in the remote repositories, we also have, like, certificates, signatures, and stuff for that. So this validate that that jar came from here, and you can use the cosign command line tool to verify that. So this is the command for that. You see I'm using the verify blob command, to verify this jackson jar dot bond. Like, basically, verify with this bundle information that file and then the links to the certificate enforces, identifiers and issuers. So we see here it verified okay. So you can verify each artifact if you download the relevant files, to annotate like, to basically confirm that, yes, this was built in the Chainguard factory. So pretty sweet how you can basically know what came from Chainguard and you can trust. No problem. Versus, oh, you might have to look a bit closer where this is coming from and also what it's doing, and you have a nice clean separation. And those libraries then, of course, will be used in your application. So when you run a build, like, I haven't done that now, but in this directory, the output directory would be a target directory, and that would be the jar that is the application. Right? And inside that would be the jars that are all the declared dependencies. So typically, it gets pretty big pretty quickly. And then we would have a little summary. And the summary is, you see that Chainguard libraries for Java is like a trusted provider of these open source library binaries. Right? The source code, you trust the developers. They make it publicly available. You can inspect the source code anytime on the source code URLs. And now we provide you those binaries where you can be assured that we built them from source and we got it all the way to you without any problems on between that you might, not wanna have to deal with because it's ultimately very complex. And, believe me, building those, all these packages from source is is not an easy feat. We have some really, really good developers that working with us on this. It's been quite amazing to see. And as you also saw, it works completely seamlessly with the repo management, the build tools. In the documentation, we also have the content for JFrog Artifactory and, Cloudsmith and the others and also different build tools. It's all there. You just follow the steps on whatever build tool is your favorite tool. You can use that just fine. So as I click pick out, you you are point one what's next? Build receipts are coming next. So there'll be a full file that details when this was built, where, obviously, in the chain cut factory, but on what machine and all, like, further details where the exact point that to the source code is. Right? Like, there's all sorts of weird funny things happening where when when we look back at the content of Mainland Central, like, it's the metadata says it's from one commit, but, actually, it's kind of not. And there's, like, off by one errors in the commit history. We'd have to deal with all sorts of weird version control systems from way back when or even code hosting systems that don't exist anymore like Google Code or so. So there's a lot of complex things we have to do. And I'm I'm writing a blog post about this with the developers that will talk about how complex it actually is building the Java libraries in the Jingle factory. Super interesting. And, ultimately, it's not something you wanna do. It's interesting if you are a nerd, in this, like, sort of supply chain and building tools thing. And, like, myself and others have been interested on this for a long time. So it's cool for us to do, but as a developer in an in an enterprise, you probably don't wanna deal with that. It's it's it's not fun if you're not into that. We're also gonna supply more documentation. And then, of course, we announced today, as Lisa already mentioned, Python and PyPI support. So Python package index, the PyPI or PyPI is also supported now. And you can join us for early access or beta usage anytime now. Contact us and see how it goes with you, and we would love for you to test it out and hopefully then be able to sleep well and forget about all the worries about what's coming in the supply chain because, you know, you can trust us. And, you can then use those applications on your containers or wherever else you use them. Maybe you're building a car or a robot or some embedded device. Doesn't matter. The libraries are there. It will be helping you to keep them secure. And so now I'm open for question. I was open for questions this whole time, but, I guess I talked too much or too fast. Here are the resources. E.10card.f10cardlibraries, and I used it already. You saw it here. You see it right here on the left. There's libraries, the overview, access. We also have an FAQ about it, and then the configuration for the global configuration here for all the different repository managers and then also build tool configuration for the different build tools. And if they have any specific wishes there, we can add more. Alright. Let's look in this in the chat if there's any questions from anyone in the audience. Questions in the chat. I was talking about distribution, but maybe you could add some more color here. Ken's question about the about security flaws and open source packages, and I think there was a recent PR merge and then a follow-up question about publishing open source libraries. And then there was, one other question about the repository manager. Okay. So let's talk about the publishing. So the publishing and the restrictions on how you can publish differ for every ecosystem. In some, like, Maven is a bit strict in the sense that you have to, prove ownership of the domain name for the reverse package namespace. Python doesn't have a namespace. NPMGS also doesn't have a namespace. They are working towards that. Some of those systems, like, they typically put a focus on making publishing easy for the open source committers and maintainers. And that's great if you're a maintainer, but it's also great if you're an attacker that wants to, like, do some type of squatting, and we see all sorts of things like that happening where nowadays even, like, AI kind of squatting is happening or, like, packages are being imagined by people doing by coding and then somebody finds that out and publishes a malicious, a malicious missing package. So there's all sorts of things going on there. And then, of course, you also can't necessarily trust that the maintainer who builds the library doesn't mess up and has a wrong like, that's literally what we found. Right? Like, some release artifacts, the binary is actually not from the commit that it says it's coming from. And while that's, honest mistake on the maintain and in some cases, in others, it could also be a malicious thing where, the metadata is not verified. Right? Like, these all these repositories don't build from source. They just take what the maintainers provide or the authors of the malware or the commercial providers, and it's not verified. Right? So they can totally publish an artifact that says it does one thing but does something completely different, and there's no guardrails around this. All these organizations also have a lot of work. Right? Like, as you can imagine, it's a pretty big surface to, deal with that. Now I don't know what the question was about repository managers. Well, good. Yeah. My let me just scroll up here a bit. Or, actually, I can scroll up. Oh, that's weird. Maybe, Lisa Lisa, if you don't remember what the question was about repository managers, you can repeat that. Otherwise, there's a question about CVE remediation. Currently, we are focused on providing you the original source code from upstream and not remediate CVEs just yet because, well, once you remediate CVS, you're basically changing the source code. And, typically, those libraries need a lot of testing and a lot of verification. For some very prominent ones, we'll probably end up figuring out how to patch. But what that then means is that you as a as a developer will have to update your dependency declarations. Right? Because it's ultimately a different thing. Or if we don't change it, that might also be possible, then you need to be aware that it's potentially different. So there's there's still discussions going on and, like, luckily, we have lots of, like, very helpful beta testers, and we hear both stories. Right? Some of them don't wanna actually have to deal with changing versions. Other actually potentially want to. And that's that. So let's see. I see the question now from the repository manager. Let me see if I may claim right. So, yes, repository managers can have all sorts of policies and can also verify checksums and stuff. And we're working on getting that automated also with the Chainguard libraries. But, ultimately, the checksum doesn't really say anything. It just says that, you know, like, if you run a checksum algorithm on this binary, it is that that binary. And that's fine, but it doesn't say anything about what's inside it. Right? Like, you can still have a a perfectly valid checksum of a malware artifact as you can have a a valid artifact for another one. Although, typically, the checksum validation is actually not switched on. So it's it's like your mileage may be right, essentially. But, that that's also one of the things that's that that we find is, like, the the way to, like, deal with these dependencies and figure out sort of which ones you want to use and don't want to use is very complex. As you saw, like, there's, like, we probably dealt in the simple tuning gateway, but we dealt with, like, well over a hundred. Now imagine you use a bigger application. There's just many, many. And then if you deal with many, many of those applications in a larger enterprise, it just becomes unwieldy to deal with the whole, like, when is what allowed, where, and try to make policies around it, it becomes increasingly painful. So with chain cut libraries, you don't have to worry about that. You're just like, well, no. We're just gonna trust those libraries only, and at least we're eliminating all the supply chain attacks out of the box. And then that allows you to focus on the other things some more where you then need to. Right? Like, at least you have a separation of the ones you can trust from Chainguard and then, like, less. Right? Like, say, 70% come from you can you know that all those are good, and then you can deal with the other 30% and pay more attention. You'll be actually have more time available for that. Alright. I think that was the questions. Let me see. Are there any plans for Chainguard NPM registry? Yes. We're already working on it. Python is already out there. We'd literally announced it today. Internally, we have NPM going, but it's gonna take us a while. As you can imagine, the Java ecosystem, it has been around a long time and is quite active. The Python ecosystem is probably even more active, and the JavaScript script is even more wild wild west. So there's a lot of fun to be had. I very much recommend you to read the blog post about the Python ecosystem launch because there's some surprising, let's say, results what we found when looking into these binaries, those Python wheels. There's, like, stuff inside that you didn't necessarily want to have inside. That's also related to the CVE remediation, by the way. CVE mediation becomes a bit tricky on the library level than on the lower level c level because these libraries basically break the API all the time. Like, even though the semantic versioning in place is not necessarily always true. So you can kind of consider every, like, new release of breaking change and then making that work is very complicated. Alright. I hope my demo worked, and everyone learned something today. And I'll see you next time in whatever learning lab we're doing on Python and other topics.