 Thanks everyone. Yet another talk. There's a lot going on today, isn't there? It's just from one thing to another. This one is on Persia. So quick show of hands. Who has heard of Persia before? Yeah, there we go. Okay, cool. So trusted open source artifacts on the blockchain hands-on introduction by me. So first of all, who am I? Now I've got two photos up there, frankly, because I haven't got round to updating all of the slacks and all of the different things. So that's my face. And then if you find me on Slack, I'm the guy scuba diving. Work and advocacy. I am a CD foundation and CNCF ambassador. I have an observability background. So I'm a dev rel art, a company called Dynatrace. I obviously have an observability background primarily with a bit of security thrown in there. And obviously, as you can see from the t-shirt, progressive delivery, continuous delivery is a real interest of mine as well. So any of those topics, feel free to come and grab me in the hall and speak to me. Outside work, of course, you might have guessed from the photo, I love all things scuba diving, anything about the ocean. If it's got the sea or a boat involved in it, get me there. Although those mountains over there do look pretty good for skiing. So by the end of today, what will we do? You'll hear about what Persia is. Where does it fit in the life cycle and all of the other tools? Because all morning I've been hearing about tools and capabilities. So where does Persia actually fit in? Why is it actually necessary in the first place? Why do we need another thing? Talk a little bit about trust or lack thereof. Trust, I'll talk about why that's important. I'm actually going to show you Persia in action. And then I'm going to show you how and where you can experiment with Persia as well. So what is Persia? Apart from being one of the newest projects into the CD Foundation, it is a decentralized package network. And I know some of the talks I've been to this morning have been leaving the screens not long enough. So if you want screenshots or photos, I'll try and leave these on a little bit longer. But what is a decentralized package network? It's useful to think of it where it fits into the life cycle. So we're not thinking delivery life cycle here. We're thinking developer workflow. And I'm never going to win any awards for my slides. But here is an actor developing some software. He, she, they build a container image and then push it to a container registry. And then obviously I'm abstracting a lot here. But ultimately that gets running in production. So where does Persia fit into this flow? And why? Well, as you've heard all morning and will continue here the rest of the afternoon and tomorrow, there's a myriad of different tools, the SAST, IAS, DAS tools, there's quality gate tools within the pipeline like Captain. There are S bombs and I bombs and APSEC tools that run all the way right in production. So that's things like, you know, continuous scanning of what's going on at a trace level and runtime blocking. So yeah, where does Persia fit in? Logically, Persia is fitting into this container registry part here. So why, why does Persia need to exist in the first place? Why another tool? Well, this actually is Google, Google Chrome's advice to new would be chromium developers. And this is all about trust. So they call it the rule of two. The code which processes untrustworthy inputs, code which is written in an unsafe language, and then code which runs with no sandbox. And they've actually, that isn't me writing that, that they have written doom, do not do this if you pick more than two. So trust at the boundaries of what you control is critical. That's really what I want you to take away from this and the next diagram, which is OWASPs, sort of similar diagram talking about trust boundaries. Now here they're talking about an application and where data flows from one part of an application to another. You need to understand your trust boundaries and where they live. So let's have a look at conceptually what Persia does. Well, what happens if the container registry changes something? I'm not picking on Docker Hub here, but whether you're running on premise, you're paying for a service, if they change something, if you hit rate limiting, whatever the case might be, there's just something that you aren't comfortable with in that registry. What happens if the registry or the repository, if it's NPM, for example, just goes down for a day or two? How many of you, actually just a quick show of hands, how many of you are pushing to multiple container registries? No one. Maybe? Kind of? Okay. So, yeah, yeah. So we've all got a single point of failure and our entire software lives say don't have a single point of failure. It's a bit of a contradiction. But anyway, also, we're assuming that that's you or that's the person you trust. If you're depending upon Nginx or some package, let's say, that might not be you. How many of you are, every time you build a new version, you're continuously pushing the old versions as well, because if someone gets into your container registry, what then? So there's all sorts of cases where Persia comes into it. So how does Persia actually help? Well, Persia says, okay, you've got a container registry, but no, I don't really care about that. I'm going to go to the source of truth, git, and I'm going to build it for myself. Then I'm going to take that build spec, that build definition, and push it to the Persia network. So what that is is a network of independent build nodes that will independently go and build that software artifact, container or whatever it may be. When each of these build nodes has come to or has built the software, are they in agreement? Is each of the builds identical? And if they're not, then of course, throw it away. Someone has done something in transit between git, the source of truth, and that build. So effectively, it's a man in the middle for your container. Someone has tampered with that on one of those nodes or all of them will throw it away. If they come to an agreement, then that is written to the transparency log on the blockchain. Now, as you probably know, the blockchain is an immutable source of truth. So once your code or your image is there, that's it. It's not changing. And you, there we go, there's me on the bottom corner. I know I can trust that because of Persia's build network, because I've had a consensus across those build nodes that it was true and it was the case. So demo time. If this is too small, yes it is, too big. Okay, so we've installed Persia on this Ubuntu machine. Not much to it. And yeah, we can start the tutorial. Now, the first command I'm going to run is Persia ping. And it says command successful. What does that actually mean? Well, we've installed Persia as a demon on this Ubuntu machine, and I'm now part of the Persia network. So I can ping the network, I can see what's going on, and I can use it. Now, when I installed Persia, we made a change to our Docker demon file. And all we did was change the registry mirror, zoom in a little bit, to pull from local host. So now I can, as a developer, I interact with Docker exactly as I would. Nothing has changed there. But we're actually pulling from the Persia network now. So if I just show you that I've got nothing in the cache, no such image for Alpine. And I'm going to pull Alpine. And there we are. Alpine's pulled. So as a developer, it's completely transparent, really, to me, that I'm even using Persia. But everything is written into syslog on Linux. So if I cat the syslog and do a bit of fancy grepping, you can see this is the proof that I actually pulled from the network. We can see artifact service storage. There are zero stored artifacts. I'm going out to fetch the manifest. An artifact is being pulled from the manager with these IDs. So this to me is the power of Persia. I'm not having to change the way I work. It's just kind of slotting into my workload and my way of working. Now that that image is in the, in my, I've pulled it, it's in a local cache. What does that mean? Well, obviously, I'm not going to go and pull it every single time. But also, remember, I'm part of the network now. So I am able to distribute this image to other people on the Persia network. Because that's the other element to this. It's a peer to peer network. So that's the other powerful part. We're not relying for distribution on centralized nodes. There are the build nodes, which are a network that have to come to a consensus. But then I can distribute this image. Now, what stops me from poisoning my local copy and sending it out to someone else? Well, the blockchain. Because everything is verified. If I try and send you a broken copy or a poisoned copy, it just won't work. You will get the proper copy. Simple as that. Now, I talked earlier about the transparency log of the blockchain. That's the you trust but verify. You don't have to trust anything. You can actually see what's going on, what decisions were made, what was built, who built it, when it was built, et cetera. And you can have a look at the transparency log or the blockchain for this alpine image. And when you do an inspect log docker for that image, you get a JSON blob effectively with all of the decisions, all of the meta information about what you received when you did that docker pull, what was built, by who, the node IDs, the package, et cetera, et cetera. So everything is transparent. Now, of course, you can use this information however you like. So you don't even need to trust the Persian network necessarily. You can verify that it is doing its job. So everything is very transparent. So of course, the next question you've got is, well, that all sounds great. But who runs the build nodes? Who's behind this network? And that's a fair question because if I'm going to trust a network to pull my images from, I need to trust that network. And as you can see, there are some fairly big names on that list. And actually, anyone can opt to build, be a build node. Obviously, there is a process involved there that you need to commit to certain agreements and things because we can't let anyone be a build node because then what happens? But yeah, docker hub, deploy hub, Huawei, Oracle, big, JFrog, big, big names in the industry with, of course, is the entire idea is to build this network out for more companies so it becomes even more decentralized and reliant on 100 companies, not just 6 or 7 or 10. So that's the other key thing about it being a peer-to-peer system is that more power is better. So a couple of takeaways. Know your trust boundaries. This is just in general when you're developing software. Your inputs and outputs, obviously this is just software development 101. Your system boundaries and your dependencies. So it's not just about the code you write, it's about the code you depend upon. Trust but verifying. Persia makes that very, very easy to do. Supply chain security is very hard. No one's saying that this is going to solve every problem. No one's saying it's going to be easy, but Persia does help. Persia, as I've said at length, is a peer-to-peer network. The more users we have on this network, the more power the network has and the more decentralized it becomes. And lastly, Persia's new. So if you have ideas, if this talk has sparked any interest or you think, well, wouldn't it be cool if it did X, Y, Z? Get involved. Raise an issue. Have that conversation. So you can reach out Persia on the CD Foundation Slack. Persia.io is the website. And I promised you that you could find out how to run the demo. I just did killercoder.com forward slash Persia. It's where you'll find the demo that I just run. And if you go onto Scared or Shed, you'll be able, I'll upload these slides and there's a lot of links there to everything I've put the rule of two, the OWASP threat modeling, the official website and a link to the demo. So with that, I'm honored to have the man and lady themselves, the team Persia are in the room. So if you have any questions, I'm a fan, but the technical people are here. So any questions on Persia? Not a single one. I did the job. Well done. Ha, ha, ha, ha. Awesome.