So, this is it, this is the final talk. It seems like it's a long day and you've been all waiting for this talk now. Okay. So, your ID cards might not have my name because I'm a last-minute replacement. Actually, this talk was going to be presented by Samir Fegel, he's the founder of R2, the company where I work, and I'm a full-stack engineer over there. We are JavaScript everything, server, backend, database, everywhere. So, we are a company who's building cool products in the financial inclusion space, that is a CRM and a landing platform for microfinance companies, NBFCs, and small banks. Okay. So, we have cool stuff like Aadhaar and going on stuff. And, yeah. So, we use Ember heavily for our client-side applications. And so, I'm going to tell you about using Ember to build a real ambitious application. Yeah. Okay. So, what is this? If you go to the Ember.js website, it will tell you that it's a framework for building ambitious applications. What is ambitious? Okay. So, you want to learn any new framework, new NBFC framework.  But I'm sure it doesn't get you any far than just explaining what is views, routers, controllers, etc. Okay. But let's look at some of the applications that are built using Ember. So, it's Zendesk, Travis CI, Discourse, Heroku dashboard, Vine. And they're all huge, massive client-side applications. So, all the crying about client-side single-page applications don't work for public-facing websites. That's not true. Let's see how we can try to build something similar. Okay. So, let's try an intermediate example. So, what gives us the credibility to do this talk? So, our platform has just on the client-side, just on the Ember side of things, R has all these numbers, so many files, so many routes, so many adapters. Okay. And we have like five big applications which are wired together, and they run as one application. Okay. So, what are the important elements if you want to build a big Matthew application? So, one is modules, and then second is you need to have real data. You can use mock-up data, you can use client-side, JSON files, but it will only get you so far. And the third is you need to have custom views, because you will have components which are repeated everywhere. You need to build components which you can reuse with minimal amount of coding, and for this, obviously testing, and unit testing by what I mean. So, let's do a demo first. So, there's a disclaimer. It might be not safe for work because we are using 9GAC to build this demo. So, let's go to the demo. Okay. So, what we have done is, it looks like a fairly simple demo. So, what I have done is, so last night I used 9GAC API, pulled some data, so about 100 posts. I don't know what are all there in the post. And I'm showing some of them, the top 10 of the trending posts here. And I have a search feature which will do a loose-in search. That is a full-text search. Okay. So, let's see. If I go here, it shows me some picture. It shows me some picture. It's like the usual ones. Then I do, okay, I do Batman. It gives me something. And I do something. Maybe I will do Apple. Okay. So, I'm getting, so all these data, they are not local. They are in a live database. Not in a live database. They are in my local database. But this application can go into production right now with minimal effort. I can just say Ember build and it can be pushed to Amazon or whatever. Okay. So, how do I go about it? Okay. So, this thing, Ember CLI. Abhimanyu already gave a great talk about Ember in the morning and he explained really well what Ember is, Ember data is, why it's useful. So, this is one step ahead of that. So, Ember CLI is the best thing that has ever happened to Ember since Ember, Ember data, Ember runtime, Ember metal. There are so many things, but it has combined all of those nice things and it's a utility. It has Ember and Ember data internally. Okay. So, let's look at some of the features that we already know as JavaScript developers that they are not necessarily related to Ember. So, as it's compilation, this term might be familiar to people who are coming from the Rails background. So, it's basically what your grunt or gulp or all these things do. So, every JavaScript project you have to do, minification, concatenation, what else. So, then you might be using libraries like CoffeeScript, Handlebars, less as, stylus. So, you have grunt test to run all of them and then you have test which you, again, which are part of the grunt test. But Ember CLI has all of these out of the box.  Then modules. So, Ember CLI internally uses something called as ES6 module transpiler. It's an open source project built by square payments and the good thing about this is you don't need to use require or AMD. It's not that these things are bad, but it's following the same syntax that is specified by ES6. So, tomorrow when browsers implement ES6 features, you just have to remove this library and everything will work as it is. So, you can just say import, controller, name, export, controller, name, that's all. And you can write your code for each separate section. You can write them in separate files. They will all be modules. And Ember is already very heavily convention over configuration.  It knows which controller to go. It knows which module to pick up. So, Ember has already these features and ES6 module transpiler gives you the ability to write all these components in separate files and all the wiring will be done by Ember CLI. You don't have to worry about the wiring. So, as a developer you would want that your code is separate and it is in modules, which this gives you. Okay. And so, another thing about modules is you always have a case where you have built some feature, say suppose, like I showed you the search box, and you have three, four projects going on, three, four applications going on, and you want that component to be shared by all of them. So, what is the thing you do? You just copy that code to each of your projects. And if you make a change in one, you have to make the changes in all of them. So, or else you push it to GitHub and you lower it and you can still use it. But the easier way here is Ember CLI gives you the ability to create applications, like all these applications and add-ons as separate Ember projects. So, I just say Ember new app one, it creates a new Ember project. I say Ember new app two, it creates a new project. I say Ember add-ons components, it creates a new project. And I can say, okay, app one needs some component, app two needs some adapters by specifying just in the package.json. I have to just give that relative path and these projects will take the components that are necessary from the add-ons project. And you have to understand that all of these are separate Ember projects, they can run independently. So, you can test them independently, you can build them independently, but when you're building the first project, you will get whatever is dependent built into the first project. And when you build the second project, whatever is dependent on the second project, from the add-ons module, that will get built. So, development is independent of the add-ons. Like when you build them, the add-ons things won't be built again. Because they are already tested and running independently, you don't have to worry about them. But when you're building for production, you will get whatever you need exactly as it should be. Okay. So, let's go back to our demo and see how this is done using Ember CLI. So, this was the code that I... It's a simple node script which used 9gags API and pullData and what I did was I just pushed all of those to CouchDB. Okay. So, let's go and see how it looks in CouchDB. So, CouchDB, if you're not aware, CouchDB is a document store database and it's pure JSON. Beeson or what else? I don't know. It's pure JavaScript. It's pure JSON. And it has HTTP APIs. You can call this document directly by calling... by doing curl get of this ID. Okay. So, if I just give this... If I do just a get on this, you're already getting it on the browser. You can get it on the command line or in any program. Okay. So, I pushed each post to separate document in CouchDB. Okay. And CouchDB has something called as design documents. So, what design documents will give me is I can have views and I can have separate functions to do my full-text search. So, I'm using something called as CouchDB Lucene which allows me to do the full-text search without having to worry about the coding of it. And views will give me aggregate of... I can write some conditions which will run through all the documents. It will do a map reduce and it will give me a set of documents that I'm interested in. So, right now I'm saying... So, right now I'm saying by-votes get me all the documents and sort it by... Not sort it by, but I'm saying... I'm calling a view which tells me give me all the documents which are by-votes. So, I'm getting this document. This is document one. This is document two. Document three. And I want to show this data like Abhimanyu showed you in the morning. Ember wants data which is... Okay, I'll come to that. So, this is basically all the data in CouchDB. So, this is what I was talking about. So, this is the data that we have. We have one... This is one document, not the entire result of the view. This is one document. It has an ID, caption something and it has an images array. It will tell me, okay, this is the normal image, and it will give me a link and this is a hugely nested... not that huge, but it's a nested JSON document. So, this is document that I have. Just focus on the images array. And this is the array that Ember expects. Till before Ember beta 10 Ember data beta 10 it was expecting all the IDs in the parent document and just the document separately again side loaded. So, this is called a side loaded JSON. It wanted an ID for each of the nested documents. But now with Ember data beta 10 it's supposed Ember JSON also, but still it needs an ID. So, how do we get from here to here? And the thing about Ember is because it's convention based you don't... You shouldn't fight it. If you fight it, it will give you more pain. So, what do we do about it then? So, the answer is you have to write your own custom adapters. So, you once write the adapter and I'll show you just how the adapter is done. So, one thing you might not have noticed. We are not having a back end language anywhere. We are not having node or Java or Ruby or whatever on the back end. We are directly pulling it out. We are doing this same in our application. We are just having a node back end for security purpose. We authenticate each URL and then we forward the request to CowsDB and whatever CowsDB gives back, we just use it as it is. Okay. So, Ember... So, the default rest adapter that Ember has, that doesn't support that won't understand this result that the view is giving us. The hugely nested JSON document. In my controller, I am saying whenever I do a query, I am specifying some parameters, some path parameters, some query parameters that CowsDB is accepting. CowsDB is saying if you go back to this, if you look at this URL it's saying underscore view sorry, underscore design slash list, underscore view by words. So, all these parameters that whatever CowsDB expects we specify in this component, in this controller and then we say, okay find do a store.find instead of saying just post, I say I am giving it a different name, I am calling it as post-lucy or whatever. And that is some adapter. So, if I just look at that so just the post one it's saying it's not extending the rest adapter the default rest adapter, it's extending a data adapter and post-lucy it's extending a lucy adapter lucy, we are calling it for the lucy adapter. So, now whenever I use these models in my application, they will be following these adapters. So, someone asked the question in the morning what will happen if I am having two or three different services. So, it's easy, you have to just create different adapters but just specifying this won't work you have to actually define what the adapters will do. So, let's take a look at what the adapter is. So, the adapter is extending the rest adapter as it is but it is just overriding a few functions that we need. So, if you remember from Abhimanyu's talk in the morning, adapter looks for the URL and here serializer transforms your JSON string into ember model format. Okay. So, my data adapter is extending the rest adapter and I am saying over at the build URL so whatever parameters I passed in my controller those parameters I am constructing the URL. Okay. So, I am saying if it is just an ID, if I am saying store.find post, comma ID then it will be this URL because it is cos db flash document ID but if it is a view, view is a map reduce output then it will require a design document URL. So, I am getting that from the first line or if it is just an ID this thing or else so we are overriding all the minimum modifications to all the default functions. So, this is the build URL but for every CRUD operation function that you can do you can do find, create, record, update, delete. We are doing all the minimum modifications that are required and the output you get so I am calling this URL so when I do a refresh it is going to the post route and it says that it has to fetch the post model which is in the data adapter. So, this URL is constructed instead of just if the rest adapter would have called the localhost slash js foo slash directly the document ID but here it is constructing this entire URL and then I get back my response so this is my response now it is and the serializer takes care of converting the JSON string into my ember model format so let us take a look at the serializer once so what the serializer will do is it will do the same thing it will just do the minimum modification that we need to do on the default functions so it has something called as find query I am going through if I look at the JSON again I am just interested in the rows not the entire document I am just interested in this arrays and I need IDs in each of my nested JSONs so what I will do here is I will go through all of them here and for each of them each of the rows I am saying get me just the row.doc and I am calling an add ID function to that and in the add ID function I will look at the parent if the parent has an ID I will pick that ID add some count to it and then return the document so however deep nesting I have I will always have a unique ID and then my ember will be happy so let us go back to the demo so this was the default view I am doing a search in this but when I do a search again so I am doing this search this time it is calling a slightly different url earlier it was called as underscore design something underscore list underscore view because I was interested in the view output but this time I am interested in the because I am doing a search I want I am interested in the Lucene output the CowsDB Lucene output and the CowsDB Lucene output looks like this but now I am having a separate adapter for Lucene so when I am doing the search it is doing a store.find on the model which is extending the Lucie Lucie adapter that is what I am calling it and I get the response in a similar way and I just have to create these adapters and serialize this once and then I need to forget about them whether it is coming from Lucene or whether it is coming from view and I should just keep on writing my ember code as it is so one more thing I mentioned about custom views in a Matthew application so ember has a very nice feature called as components Angular has directives I guess so components we are already using a library that is called as Twitter to type ahead it is available but you cannot use it directly because it has to be emberified you need to have it as a component so that you can just use it anywhere as you want you should just give the input and it would give you the output and you can pass it like a regular ember function so what we did was so this is the component class we specify what class names it should have what are the default values and whenever some action happens on it this portion did insert this portion is the default code that the Twitter type ahead expects it is the default jQuery input output I am just monitoring for this when content changes if someone else changes the content then it should load again I am observing it all the time and then I say whenever it is selected just send an action and the component will get it back so I should just go back here if you look at this part this is all I need to do once I have the component ready it has a lot of parameters but it is most of the time it is always the same it has class names and the placeholders but apart from that the content you can see that it has content called as search results and the query what I type that is a query so every time I enter a key the action in the component is triggered it will do all that the Twitter type library expects it to do but because it is extending a model that is sorry it is working on a model that is extending the loosing adapter it will do a back end call it will do a loosing search on CouchDB and then get the results and the search results will be populated over here and then everything is just like a normal table nothing else and testing for the last two days we have heard many times how unit testing is important so I am not going to repeat on that but Ember CLI already has a testing framework so it has a qunit version of it it is called as Ember qunit you don't need to worry about how to configure those tests where to write it it already gives you a folder I will just quickly show you so these are the three modules that I have data, app and addons app and addons were just created by saying Ember new you can just say Ember new app1 addons and all of these got created and app again has something called as test already inside it in the unit folder you just need to write your test cases and when you run them you will know whether all of them are passing or not so that's it any questions I have uploaded this entire demo in github you can download it the adapters and serializers which I showed you was just a part of the entire thing that we are using in our company we are looking to open source it if you are interested you should get in touch we can help you


Prevent is part of the UK government's counter-terrorism strategy. Basically the government says we need to kind of find these people before they become violent. So suddenly the workplaces became potential areas for identifying people and children as well. I think Prevent when it came to the fore, we started worrying quite a few of our teachers. Prevent was, it's fair to say, poisoning the relationship between tutors and students but also it was targeting in particular Muslim students. The school missed my son's need. He needed support and the school failed to give him that support. In fact they failed to even recognise that need because there was so how bent on, this is a brown Muslim boy, he must be a terrorist. He was profiled. The evidence shows that a British Muslim is eight times more likely to be referred to the channel programme under Prevent. That show is clearly discriminatory. If the political will was there, the actual research could be done to identify what are the risk factors that lead someone to committing a terrorist act, rather than simply having this scattergun approach where you refer essentially anyone you're a bit worried about. And that's what's happening. This policy is problematic for all of us as citizens because it is actually creating a them and us binary. It's also restricting freedom of speech and thought for everybody. It starts now with people of the Muslim faith but that extends.


Hello and welcome to the session. Let us discuss the following question. It says, write the contra-positive and converse of the following statements. Let us first learn the concept of the contra-positive and the converse statements. The contra-positive of the statement, if p then q is if not q then not p. That is if we are given a statement in the form if p then q then its contra-positive is given by if not q then not p. For example, I see a statement that if you get more than 85% you will get a price. So the contra-positive of the statement will be if you don't get more than 85% you will not get a price. So this is what we mean by the contra-positive. If not q then not p. And the converse of the statement if p then q is if q then p. Let us now see the first statement. It says if x is a prime number then x is odd. Now here we are given a statement in the form if p then q. Where p is the statement x is a prime number and q is the statement which says x is odd. Now we have to write the contra-positive of the statement. So the contra-positive is now we know that the contra-positive is of the form if not q then not p. So this is not an odd number then x is not a prime number. So we write the contra-positive of the statement if a number x is not odd not a prime number. Now we have to write the converse of the statement. That means we have to write the converse of the statement if x is prime then x is odd. And the converse of the statement is if q then p. So the converse will be if x is odd. Now the second statement is if the two lines are parallel then they do not intersect in the same plane. So we have to write the contra-positive of the statement where the statement p two lines are parallel and the statement q is the two lines do not intersect in the same plane and the contra-positive is given by if not q then not p. So statement q is the two lines do not intersect in the same plane. So not q will be the negative of the statement that is they intersect in the same plane right not p the lines are not parallel. So the contra-positive is intersect in the same plane they are not parallel. Now we have to write the converse of the statement that means we have to write the converse of the statement if p then q and its converse is given by if q then p. So here q is the two lines do not intersect in the same plane. So the converse is two lines do not intersect in the same plane then they are parallel. So this is the converse of the second statement. Let's now see the third statement it says something is cold implies that it has low temperature. That is the statement says if something is cold then it is at low temperature. We have to write the contra-positive. The contra-positive is if not q then not p. So if something is not at low temperature it is not cold right. So the contra-positive is if something is not at low temperature then it is not cold. Now we have to write the converse the converse of the statement if p then q is if q then p. Here the statement q is something is it is at the low temperature and statement p is something is cold. So if something is at low temperature then that thing is cold. So the converse is if something is at low temperature then it is cold. Now see the fourth statement it says you cannot comprehend geometry if you do not know how to reason deductively. Here the statement p is you cannot comprehend geometry and the statement q is you do not know how to reason deductively. And the state of the form if p then q has the contra-positive as if not q then not p. So the statement q is you do not know how to reason deductively. Not q means you know how to reason deductively and not p is you can comprehend geometry because p is you cannot comprehend geometry not p is you can comprehend the geometry. So the contra-positive is so the contra-positive is if you know how to reason deductively then you can comprehend the geometry. Now we have to write the converse of the statement and the converse of the statement if p then q is given by if q then p. So here q is this you do not know how to reason deductively and p is you cannot comprehend geometry. So the converse is if you do not know how to reason deductively then you cannot comprehend geometry. Let's now see the fifth statement it says x is an even number implies that x is divisible by four. So here the statement p is x is an even number and the statement q is x is divisible by four. So the contra-positive of the statement if p then q is given by if not q then not p. So if a number is not divisible by four then it is not an even number. This is the contra-positive. So the contra-positive of the statement if x is an even number then x is divisible by four is if x is not divisible by four then x is not an even number. Now we have to write the converse of the statement the converse of the statement if p then q is if q then p. So the converse of the statement is if this is divisible by four then x is an even number. This completes the question. Bye for now. Take care. Have a good day.


Hi everyone, this is Ziyue Yang. It is a great honor to present our topic in Open Source Summit Japan. Today, my colleague Haokun Shin and I will present our topic. Our topic is improving a boot-up performance of container with overlay images in TE environment. This page shows the agenda of this presentation. In the first part, we will introduce the background and the motivation. We know that containers are largely deployed by users in both public and private cloud. If the containers are running in the public cloud, then there are strong requirements on the data integrity and data security of users' workloads. There is an open-source project named as Confidential Containers, and the data is very active. It will mostly rely on hardware-trusted execution technologies to protect the containers. If the data is protected, customers still have strong requirements on the performance if their workloads are deployed in those containers. In our presentation, we would like to address performance issues when customers' workloads are deployed with confidential containers protection. In the second part, we will introduce the status of the current Confidential Containers project. In the third section, we will introduce our optimization work. It is related to how to accelerate the container boot-up, which includes accelerating the mod key, retrieving if there are multiple image layers of a container. We will also introduce how to use some hardware-accelerated technologies to accelerate decryption operations on the container images. In the last part, we will summarize what we present in this topic. The first part will be the background and motivation. This page shows the background and motivation. Customers who run containers on public clouds have strong security requirements on workloads in the following three situations. That is, data-arrest means that data is stored in the external storage space, and data is transferred in the network, and the last part is data-in-use. Currently, there is an open-source project named as Confidential Containers. It is designed to address such requirements in three dimensions. Confidential Containers will mainly rely on some hardware-trusted execution environment techniques to protect their containers. There are some well-known TE techniques such as Intel's SGX Secure Guard Extensions techniques, Intel's TDX Trusted Domain Extensions techniques, AMD's SEV Secure Encrypted Virtualization techniques, and also ANS CCA Confidential Compute Architecture. So with this project, customers' requirements on data security can be satisfied gradually. However, another issue is not well-addressed. That is the performance of the workloads, because even the data of customers' workloads are protected. Customers still want their performance of the workloads with little impact. They do not want that the workloads will run slowly compared with the normal solutions. Actually, besides of the hardware TE solutions, there are other solutions like homomorphic encryption techniques compared with those techniques. The hardware TE solution impacts the performance of workloads in containers less than other techniques. It is much better. However, customers still have strong desire for good performance of the workloads deployed with the trusted solution provided by confidential containers. So in this presentation, we propose some techniques to address the performance issues. It is mostly related with how to quickly start customers' containers. We provide the following two approaches. When the containers are deployed in competition containers, the first approach is that we would like to accelerate the retrieval of multiple keys for overlay images. During the user attestation with the key broker service or attestation service. Secondly, we would like to accelerate the decryption of image layers through hardware offloading techniques. For example, we can use Intel's quick-assisted technology. In this part, we will introduce the background of the confidential containers. Usually, we call it by Coco. In this page, we introduce the characteristics, course, and core projects of the Coco. The Coco has three key characteristics. The first one is the data confidentiality. Guaranteed unauthorized entities cannot view data. The second one is data integrity. Guaranteed unauthorized entities cannot aid removal or update. The third one is code integrity. Guaranteed unauthorized entities cannot aid removal or update code execution. The project has five goals. Firstly, it helps along cloud-native application owners to enforce application security requirements. Secondly, it wants the development of unmodified counters as transparent to the customers. Thirdly, it supports multi-TE and hardware platforms. Fourthly, it proposes a trust mode, which spares cloud service provider from guest applications. The last one is the list privilege principle for the Kubernetes cluster. Currently, Coco has two implemented projects, including Carter, Contents, and Enclave-CC. The Carter Contents is a VM-based content. The content process runs inside an independent VM. The VM will be protected by hardware such as TDX or SEV. The Enclave-CC is a process-based content. The memory of the content is encrypted by Intel SGX. In one word, Coco aims at providing a secreted environment for the content. The Coco wants to invent the confidential containers into current Kubernetes ecosystem. This page displays an overview of the key components. Firstly, the blue components include hardware and hypervisors that support the confidential container. They provide the fundamental capabilities to launch a security container. We call the confidential container by CC in the following parts. Secondly, the Coco relies on some service. They are colored by pink. The image build service helps to convert a plantax image into an encrypted image, or build an encrypted image from scratch. The image registry stones encrypted images. The key management service manages the encryption keys. A test station service validates the CC running in validTE. KeyBlockService is an intermediate service helping validate the CCs and transforming the decryption key. We will call it by KPC in the following parts. The first part of our work is helping the CCs to communicate with KPC to accelerate the decryption key retrieve. The second part of our work is accelerating image decryption inside the CCs with hardware. Our optimization is implemented in the agent of card contents or inclusive CC. The left three pictures show the modes of left hand. The left one, TDX or SEV creates a secured VM. The VM's memory and the file system is encrypted. The agent and the real application containers run inside the guest machine. In the middle one, an agent and application run on the host machine, but their memories are encrypted by SGX. And some lab OACs will help us to run the container with modified images such as framing or occult. In the red one, a normal VM is created firstly. The agent and the application run inside a guest machine and are protected by VSGX. The VSGX is the SGX device that is passed into the VM. At the last, the right laser shows the task of the agent need to do. The agent need to download, decrypt, decryption and store image. Our improvement is inside step 1 and step 3. In this part, we will briefly introduce some concepts in the encrypted images to help understand our optimization or image decryption. Firstly, one symmetry key encrypts one image layer and the symmetry key will be encrypted by another wrap key. The encryption information is drawn in the annotations entry in the manifest file as the top picture shows. The key information is colored by yellow. The public options contains layer encryption algorithm of the symmetry key and the digest of layer at the middle picture shows. The private options is shown in the bottom picture. The private dot attestation agent indicates the symmetry key encrypted by a service called attestation agent. The private options will be sent to the service attestation agent to retrieve the real symmetry key. The software of the attestation agent is got from a config file. In the private options, the real wrap key is represented by the key ID. The IV and wrap type indicates the encryption parameters of the wrap key. The wrapped date is an encrypted symmetry key. In one word, the agent need to send the private options to the service for every encrypted layer and retrieve the symmetry keys. Obviously, the network communication is too frequent. As a previous description, we have found the overhead on the encrypted images in CCs. The first is network delay on symmetry key retrieve. We know multiple layers send a multiple request and a wait for response and the network delay blocks image unpacking. The second one is extra decryptions on encrypted image layer. The correction options make a desperate delay on image unpacking and delegates extra workload to the service queue. Given this overhead optimization on image unpacking and boot deserves to be pre-oritized to improve confidentiality and performance. In this section, we will introduce our optimization work. Generally, we propose to accelerate the boot up of containers with multiple overlay image layers. Firstly, we would like to seek the potential optimization point in current confidential container solution. The first part will be the multiple keys retrieving for different overlay image layers in one round during attenuation process. The second part will be the parallel download of image layers and leveraging hardware-based accelerators such as Intel QoT as an example. This page shows the original diagram of container boot up in CC VZelo with Intel TDX Technic. And the original diagram is from page 18 in SAMU stack. From this diagram, we can see that there is a confidential computing process. Then users can leverage Kublate and invoke ContainerD and invoke CataCentVersion2 and talk with the Cata agent inside the confidential virtual machine. In this diagram, we can see that users can leverage Kublate and invoke ContainerD and invoke CataCentVersion2 and talk with Cata agent inside the confidential virtual machine. And we can see there is about 11 steps to boot up the containers. We can see that in the fourth and fifth steps, Cata agent were communicated with container image registry to download the images. Definitely, the image is already encrypted, so the Cata agent were communicated with key broker service and attenuation service to get the keys related with the layer. We can see there will be a step from 7 to 10. And we see that there are still some optimization spaces. For example, maybe we can parallel download the images from the container image registry. And also in the diagram, we just get the key for each layer in one round. And this is not the optimal solution. We would like to download the images together. Then the Cata agent will talk with key broker service and attenuation service to retrieve the key list. Then we think it can save some times if the container has multiple images, multiple image layers. And this diagram shows our optimization approach in the fourth step. And the fifth step, we would like to pull different layers of the image together. Then in the fifth step, the Cata agent will download all the layers of the image in parallel way. After that, Cata agents were still communicated with key broker service and attenuation service. But the Cata agents were sent a request to get the key list. It means all the keys related with the downloaded layers. And the key broker service should send all the key list in one round. And we think this optimization is feasible and will also be efficient. This page shows that in Confidential Container's project, it leverages image IS on container image operations. In the left diagram, it is original usage inside Cata agent. There will be the OCI Crypto module in image management. And it leverages scoping to download the container images from the image registry. And use the UMC tool to do the image-impact-related operations. And the right diagram, we can see that Confidential Container leverages image IS in image management module. And image IS is written by Rust language. So, in the next page, we will propose the solutions to leverage QAT to accelerate the image operations written by Rust language. This page shows our contributions to improve key retrieve procedure. The agent use create image IS to be the image management module. The left figure indicates that currently the agent will handle layers in parallel. And every layer will send a key retrieve request to the key provider. Multiple communications increase the network delay. The right figure shows our design. We will retrieve all keys in one shoot before the layer is processed. To implement the design, we need to add a bench to retrieve API between the provider and these clients. And make sure the symmetric key can be mapped to corresponding image layer. The page shows the other part of work. That is to balance decryption procedures between CPU and accelerators. The left diagram shows that currently all decryption procedures are carried by the creator or CI-Crypt IS. It dedicates all of them to CPU. It makes the CPU busy and may occupy time slice of other tasks. The right diagrams shows our design. We design a balancer. It will delegate the decryption procedures to CPU on accelerators according to the attributions of the tasks. The accelerators can share the pressure with the CPU. And furthermore, it can handle a part of the decryption tasks faster than the CPU do. Our design will decrease workload on the CPU and accelerators' decryption. Accelerators can help decryption. Most of them provide C or CPP labs. But NCLAB agent is written in raster. There is a language gap between scene and raster. This page shows our contributions on wrapping the hardware C labs for the raster applications. Currently, the rubber creator would provide three kinds of functionalities, encryption, decryption, compression, decryption, and digest. It is supported by QET. In the future, we plan to wrap more hardware to support more operations. The creator explores low-level APIs and the advanced users can use all the APIs provided by the C labs. And we also code some high-level abstract functions and expose their APIs. The high-level APIs handle all low-level details to use the hardware and only consume necessary inputs. For example, if we want to encrypt a field with AES algorithm, we only need to provide the key, IV, and field data. Different accelerators can be optimized by tuning on use case. Our RAP create tries to enable more features. For example, our RAP creator leverages a synchronous operation feature of the QET. The right diagram shows the synchronous operation workflow of the QET. In step one, the application calls the performance operation. The step two and step three, step four, delegates the operation to a QET device. Then in step four, five, the control is written to the application immediately. The application and QT will work in parallel. Once the operation completes, the QT will inform the application by call back functions. If we can take full advantages or features of this hardware, such as synchronous operation of QT, we can furthermore improve the agent performance. The page shows the workflow of decryption in image eyes if we combine it with the QT. The procedure has four kinds of thread. The image eyes mind thread is responsible for scheduling operations and other threads. The demo thread in its QET and the pulling thread pulling results and invoke call back functions. Every layer will have a layer X-ray thread. Interprepare the layer data and send it to the demo thread. Let us go through the procedure. Step one, image eyes launch the demo thread. Step two, demonstrate in its QET device. Step three, the demo thread launches the pulling thread. Step four, pulling thread and into a loop to pulling and invoke callbacks. Step four, the demonstrator waiting for layer data and submit it to the QT device. Step six, all keys is retrieved. Step seven, image eyes launches the thread for every layer. Step eight, every layer sends its data to the demonstrator. Step nine, layers read existing. Step ten, the image eyes wait for all layers read existing. Step eleven, demonstrator wait for all callbacks finished. Step twelve, the pulling thread finish is task and existing. Step thirteen, the image eyes wait for demand existing. Step fourteen, demo thread existing. At last, the image eyes continues to run. Now comes the conclusion section. Let me summarize what we talk about in this presentation. We know that it will be the trend to run workloads in container with trusted manner. Then the confidential containers project, which relies on hardware-based TE techniques, are initialized to address this issue. Besides security and trust, customers still have expectations for performance even with provided confidential container solution. In this presentation, we propose some performance optimization methods to accelerate container boot-up in hardware TE environment. We provide a following approach. For example, parallel image downloads and decryption with hardware-based accelerators. We also provide the multiple key retrieval for different layers in one round. Finally, we will continue our work and commit to open source for the confidential containers related to the community in the near future. Thanks for your attention. Due to COVID-19, we cannot attend the event face-to-face. If you have any questions, you can reach me and my colleague, Hawquan, through emails.


Hey guys, so usually I don't do an unboxing thing, but I thought it would be appropriate considering what this is. The audio is going to sound a little weird, mainly because I'm underneath my camera right now. This is the only way I can set it up. Anyways, this is what I wanted to show you guys. I've waited so long for this. I am so happy to finally have it. This is the Blu-ray Special Collector's signature edition of the Iron Giant. To tell you how much I love this movie, I still have my old VHS, even though it's seen better days. I have been trying to look for a print of this for the longest time. Either way, this is apparently number 5,433 of 15,000, which is a little bit worrying, because I don't know if you can see it here, but you'll see a little bit of scrunch here. This is because the Amazon guy dropped it off at my friend's house who lives in the States, and he said he left it on the porch, but he actually left it behind the house. Ergo, this thing was now in its package in the rain for three days, so I'm a little upset about that. I'll see what I do. Either way, let's open this up. I've been waiting for this ever since I watched the re-release of it, this film. I think it was last year. If you want a link to my review right here, that was an awesome movie to watch. Let's see. Let's look at the damage here. Okay, that's not as nifty anymore. The paper is really soaked on the top here, but I'm not so much angry, mainly because this is just the thing that tells you what's in it. It just kind of gives you a brief summary of what's in the box. It's kind of like what you got with the Dark Knight Trilogy thing. You had that thing on the back, and if you were really dedicated, you kept it. Otherwise, most people got rid of it, so I'm not too upset about that. Oh, that's awesome. Let's get that part off there. There's the screw of the giant. He left his little chin screw. Okay, so let's open it up. Oh, that's great. Look at this. I assume this will either be the DVD holder or the art book. Let's see. Oh, wow. Ooh, look at that. Oh, that's cool. Concept art. Ooh, yeah, there's a little bit of moisture in this book. Thankfully, the pages aren't ruined, but that's what he originally looked like. That's the original idea. Then there's here the concept art. Oh, here's the actor. I don't always find it funny that Harry Connick Jr. is in this because, you know, everyone remembers him as Will Smills Buddy from Independence Day who died. And then this, too. I always find it funny. This is still her highest ranked movie. And there's this more concept art. Ooh, that's kind of a really bad digital printed thing. But otherwise, that's okay. Oh, yeah, this is a great scene. Oh, I love it how there's little quips, little things in here. Ooh, yeah, some of these pages got a little bit. Is this a page here? Nope. Got a little damage. I'm assuming this is from the rain. Oh, this is pretty cool. Final resolve for good or bad. Oh, that's sweet. So that's a good little art book. And let's put that, let's put that over. Oh, this was inside. Oh, this is about the art. Oh, yeah, he's going to be in here somewhere. So put this over here. And this is a, oh, this is awesome. This is kind of like a thank you letter from Brad Bird. That's pretty sweet. Fortunately, time and word of mouth have been kind to the Iron Giant. People who see it seem to urge others to do the same. And the film's reputation has grown with every passing year. To all who have seen the Iron Giant who have recommended it to others and to those who are seeing it for the first time, this blue is for you. Oh, man. Way to see what Brad Verge's does next. Because Tomorrowland was, I don't know, I didn't really enjoy it. Ooh, there it is. Now, most of you probably have this already for those of you who really care. I'm absolutely ecstatic for two reasons. One, because this is finally this movie on Blu-ray quality. And two, because it's got a documentary about how the film was made and how it wound up being a boxed-off as bomb. I actually like that they talked about it. They showed a preview for it when I saw it at the re-release. So I'm looking forward to that. Oh, and this is it. This is the little guy. Wow, he's really tiny. Let's see. Oh, he's got a little plateau. Aw, sweet. I finally have it. I finally have a little Iron Giant. Superman. Aw, sweet. Aw, this is cool. So that's a... That's pretty cool. There we go. And let's see. Ooh, this is a... Oh, these are the prints. Aw, that's awesome. Oh, this is on Mondo. You see this on Mondo all the time. Aw, that's pretty cool. Aw. Ooh, yeah, that's even cooler. Aw, sweet. I love a hover garse in the middle here. Aw, those are awesome prints. Put those there. See, there's anything else underneath? Or is that the bottom? Yep, that's it. All right, guys, so that's it. Eight foot tall. Oh, shoot.  I didn't read that properly the first time. Jesus, that's taller than me. How would you fit in this house? Anyway, guys, that is the Iron Giant Special Edition. Thank you for watching me unwrap it. Hopefully this lighting was okay. And my audio doesn't sound too weird, but I'm really happy to have this. I've waited ever since it was able to be pre-ordered. And I'm very happy to have it. I'm definitely... This kind of sucks, but like I said, this is the stuff that goes on the back that you never really care about. So, anyways, that is the Iron Giant the Super Special Awesome Edition. To pre-order it, I would definitely look into it because, like I said, there's only 15,000 of these. So, anyways, thanks for watching, guys. Tell me if you thought this was okay. This is the first time I've ever done it on boxing. So, anyways, that's all from me. See you guys later.


All right, you guys ready to get started? Chat about this stuff. If I was to do a quick poll of the audience, who here knows like the JSON schemas of image manifest and that kind of stuff, getting down to that low level details? I know a few of you do. Okay, we got about 50-50. I think everybody rose their hand, I'd probably know. So that's probably the part of the challenge here. So welcome. This is gonna be modifying the immutable one. So we're gonna talk about how you can attach artifacts to OCI images. By that we're talking about everybody's been saying stuff like generating S-bombs. And we're talking about how we create the S-bombs. Other people are saying how to consume the S-bombs. This is saying how you can connect those to your image and start shipping them out to people who need to deploy them later on. And so let's chat. The background of me, I'm not gonna go through the full details. I do work for Boxboat. Got other people here. I'm sure someone's hiring all that good stuff. But the important details from this one are that I'm an OCI maintainer and a lot of this work comes out of the OCI. We've got a working group we were going through a lot of efforts on this stuff. And on some of the slides in the demos you're gonna see a tool called RegCuttle. It comes out of a RegClient project and I'm the maintainer of that one. So when you see that, that's me just picking a tool because it's what I know. All right, so for the background, for those that didn't raise your hand on the underlying stuff, you probably already know that container images have file system layers. They've got their own config. You've probably done a Docker build at some point and then probably changed to other build tooling and trying different stuff out. You've probably seen it, there's a SHA-256 checksum for like pinning an image to a specific digest and so someone can't change it in that way and you might have a rough idea what's going on but not quite. And I'm sure at some point you've come across multi-platform images where someone's saying we need to start building for all these Mac M1s out there because everything else has been built for all the Intel machines. And so under the covers, there's a lot going on in OCI so I wanna hit a little bit and make sure you understand what's happening under the covers because that's gonna apply for when we actually start talking about how we start to attach things together. So under the covers, the important detail here is that everything is happening in OCI when you push it to a registry is a content address will store. And so what that means on the first line is I'll take a digest and if I curl that digest, the name of that digest from the registry and pull down that blob, pipe that through a SHA-256 checksum, it's gonna output that same value. And so it's the digest of the content itself is the name of the content and that's how you do the content address ability. Fancy name there. In this case, I'm looking at a layer and so you see a whole bunch of the files in the layer so it's just a compressed tar file and so that's like half the image, right? The other half of the image is gonna be your JSON config. What user am I running it as? What are the commands that I'm kicking off when I start this container up? If there's a history in there, you can see all the previous historical steps, environment variables, all that stuff. That all gets passed as a JSON blob. Same idea, content address will store, you just serialize it into a byte array, do the digest on that and now you have another address for that blob as well. And these three shortest blobs, registry doesn't care which thrown a blob. So JSON, tar, binary, text, whatever, it takes whatever you wanna throw in there as long as it just maps to the digest to the string you gave it. So now you got these two pieces, we need to put them together because an image, not necessarily one layer, it might have multiple layers and it's gotta config and so to assemble them together, we have as an image manifest. Yeah, another piece of JSON here that we're looking at. So I know this probably gets a little bit tedious but bear with me for a second. Where we've got the config descriptor and that descriptor has the digest that we're talking to. We've got the layers in there that we're referencing and so in this case, I've got a single layer that we're talking to and you put those two things together, you put them in the JSON, you serialize the JSON, you calculate the digest on that JSON. Now you have the digest of your image manifest. This is the pin digest, whenever you say I wanna pull an image by its digest, this is what you're pulling. If you ever change one of the layers, you change the content of the layer, you change the layer digest and that changes this digest as well because it's all included in there. So that's how you make that structure. Graphically, it looks a lot like this. We've got a tag, the tag, think of it as like a symbolic link. You can have multiple tags when you do the same thing. You can have a tag that used to point to one digest and the future points to a different digest and then that points to your manifest. That manifest is immutable because it's referenced by the digest. All this content is referenced under there. So pretty pictures, I feel like that wakes some people up sometimes. I know I'm holding you right before the coffee break and so it's gonna be a little struggle here. Immutability is the nice feature we get out of all this. So when you do this, you've got a merkle tree, you've got a dag, a directed ace like the graph out there and you've got the content addressable store we already talked about. You put all those things together and you get this immutability. So in case I'm going too far back into the college days, the merkle tree is when you have a data structure that has a hash itself and it's content, all the child nodes are hashed and so on and you already change it and so that was that structure we were looking at there. Okay, so far hopefully nods in the room. We've probably got a little bit too deep in the weeds for some people, but that's kind of where this talk is going. Another piece here that's important are the multi-platform images. And so to do this, we have a different kind of manifest. That different kind of manifest just has multiple descriptors for each one of the different platforms specific manifest and so it's a manifest of manifest. So you have this hierarchical pointing. And when you do this, when you're looking through that array of descriptors there and you say, okay, which one do I want to pull? You have to put something in there that can identify one versus the other and the way we're identifying it for the multi-platform manifest, we put the platform in there. And so you put that extra field in there, you say this is the platform for ARM, the other one is the platform for AMD and then we're going through looking for year manifest, you can pick it from the list and the runtime just does this for you transparently under the covers. But importantly, this has its own digest as well. So you can serialize this one, you send that digest in there and when you send this to your runtime, the runtime knows how to figure out its own platform under the covers. All right, graphically we're now up to this where you've got our tag that's pointing to the multi-platform manifest, that knows the island is called an index and so you have an index, just the terminology is how to pick, that points to multiple manifest for each one of your platforms, that points to each of the configs and all the layers out there. So we built this nice big graph and now you put one last piece on this puzzle and then we can actually get into the fun part of the talk. And the last piece is that for the longest while we've been able to push artifacts to a registry. Anybody ever hear about pushing a Helm chart to a registry or something like that? If you're gonna push a Helm chart to a registry, you just push a blob. And their blob, I think they actually happened to push a tar file out there, a compressed tar file, but it could have been anything they wanted to. You push that blob and the thing they change is the media type that is on that config descriptor. They change that media type on that one piece and that tells anybody running it that this is no longer a container image or trying to run with a container image run time, but this is some other tool that should be looking at it, working at it, even though both of these are image manifest. We just kind of overloaded that one tool out there just so that we get that portability. So we overloaded that, but otherwise in this example here, I made a little electron bill of materials and I just said that this does contain electrons, shipped that and I can attach that to any image I want to if I decided to. Okay, so that's all the fundamentals. This is stuff that already exists out there.  This is kind of the underlying bones of what's going on under the covers. The challenge OCI faced was we're saying, okay, great, we've got all these S-bombs out there. We've got all these other tools. How can we associate one to the other? And if anybody was in here for Rose's bit, her conversation earlier, the discussion went, hey, we're shipping the container images out there. We really want to ship the S-bomb alongside of them and somehow associate the two together. Because it's not the best if you say, we're going to have this century repository of all the S-bombs that some government agency manages for us. I know I come out of the DC area, trust us, we work for the government, might be a famous term out there, but I'm sure a lot of people in here are like, no, no, no, we're not going to trust them. So, trying to get a centralized entity isn't going to necessarily work. Trying to have every person go out to a different place to try to figure out where this S-bomb isn't going to work. You don't want to like figure out, okay, it's under the released folder or on GitHub for this one project, someone else put it on their website. Now we want to ship these things together. We already have a way to ship an image. We can already ship other artifacts within the container registry. We just need to associate the two together. So, the challenge we face was how do we modify this immutable thing? Because our container image is immutable, it can't change, but we want to be able to say, for this container image, what's the S-bomb? What's the signature? What's all this other data out there? And we had a few requirements. So the working group was spun up and said, here are your go-to requirements and some of those things we were looking at was efficiency, we want to make sure we weren't making a whole lot of API calls. Other challenges we were looking at were, how do we both attach and detach content? If you start shipping out an image, you might say the upstream had it signed with their signature, but when we brought this in-house and we brought it to our own registry, we wanted to sign it with our own ID. We don't care about that upstream signature, so we just don't even want to pull that in-house. Or maybe they had more metadata than you even wanted to include or you needed to add extra metadata that wasn't there. So, a lot of different challenges along those lines. We also, we couldn't predict what everybody was going to include. You could start including cat pictures with all your container images you wanted to and we didn't want to try to write the spec for how to attach cat images to the image to container images. Gets a little complicated. So, the nice thing about this problem is that we weren't faced with the impossible, we actually had multiple solutions out there and some of them were already being used. And so our challenge wasn't how to create this, it was how to pick. And so the first option we were looking at was the Aura's team was out there and they said, we're gonna make a new artifact manifest. We're gonna push that out to the registry, we're gonna have a new definition that's not gonna have this config blob because we don't need that, but we just have our own little blob so if whatever needs to go in the artifact, we're gonna have this subject view we're gonna put in there and that subject view is just another descriptor, has this digest and that's gonna point back to the image we're extending. But now, from our manifest on the left-hand side of the screen, there's no way you can go from that arrow back to the right. So now we need to add new API. And so we add the new API that refers API that when you query that with our manifest digest from the left-hand side, it'll spit back the list of descriptors for all the manifests on the right-hand side of this picture. So that's how he made that mapping we were gonna have to add something to the registry. Couple pros and cons of this one, I mean it was nice and efficient, you had the API and the registry was gonna do it all for you but none of this is gonna work on existing registry today. Any registry out there that doesn't know what that artifact manifest that blue box on the right looks like is gonna reject it because while they accept any blob at all all those green boxes they'll take whatever you throw at them. They don't care about that part.  It's doing all of that. Association clean up, it's doing some validation in there so if you push something in there it doesn't recognize, it just rejects it. And so that was one of the big challenges we looked at for this. So he said, well, it's easy enough to change this a little bit. OCI has the model where we say you can extend any manifest out there. You can take a manifest that has five fields and you can have six field into it that's got some extra structure in it. And as long as you parse it and you see the field you recognize you can work with it and someone else that knows how to process the more fields they can do their thing. And so we could add the subject field to an existing manifest and so now we have another way to make this back reference. So now we can push this thing that's got this back reference in it using an existing media type just extend it a little bit to a registry. That means it's now portable. We can push this exact same manifest to a new registry or an old registry and it moves from one side to the other and back. And it's all nobody cares. Everybody just, it passes from one to the other. We still have the challenge that we can't find this though without having this new API. And this new API would be a new feature you have to add to the registry. So we're halfway there, we're not quite there, but we're getting there. And so the last thing we were looking at that I'll go over is that we were saying we could add a custom tag. And this comes from the stake store group. Anybody's seen CoSign? I think there might be a few people that might be signed some images. Might have been up on stage earlier. People talking about stuff that need to be signed. So they came out and said we're just gonna have a special tag that is the digest of that manifest on the left. Again, we like that digest. It's a nice, immutable thing. We can always reference. So we just make the tag with the value of the digest. She had to change a little bit of the syntax a little bit so you can change the colon to a dash so it gets parsed as a tag instead of as a reference or as a digest itself. But you change that one little bit there and now you can reference it as a tag and now anybody can use that to look up some abstract thing, whatever that tag points to. And the thing we would point to would be maybe the manifest in this case that we wanted to use. Maybe it's pointing to a list of manifests, something like that, but you could just make that pointer in there. So we had a couple options. Different A, B, and C and the question you might be saying is okay, well you threw a whole bunch of options to ask, which one did you pick? And the answer to that is yes.  We're bad at making choices. We're bad at a lot of things, but making choices is definitely one that we're not experts at. So at least as part of the release candidates, and this is still up for debate on the first bullet point, is that we did add the artifact manifest. And so I'll put a big asterisk there. We're back and forth right now. It's probably gonna get there eventually, but if you're writing something new right now, there's some disclaimers that I'll go through later on. We add the subject field, and not only the subject field to the new artifact manifest, but we add it to the image manifest. And so you can extend things like we said, so that went in there. We add the new referrers API. So there is, API is gonna go on a registry server, but this is only gonna be on new registries to implement the new feature that we're talking about. So for all the registries that don't implement this, if you're a client and you're pushing this stuff up there, the client is now responsible for maintaining that tag. Anytime they're talking to a registry, it doesn't have the new feature. So with this, we now have the full backward forward compatibility. We've got a nice solution, and graphically it gets a little busy, little bit busy, and I actually had to take some of the arrows off here to make it flow a little better, so those subject clients there will go all the way back to the manifest on the left.  Let me go out and see if there's anything that refers to it. And so you go hit the refers API, and if that exists, great, it's gonna come back out with this index. Nice thing about that index is that data type structure that already exists right now in all the specs. So we didn't have to invent anything new. And that index as we were talking about just a bit ago is a manifest to manifest. So you can just point to as many of these we want to, which means we can have a whole lot of artifacts we're all referencing at this point, which is great. And by the way, if it doesn't work and we have to fall back, we use this tag and the tag and point to the exact same data structure. So the clients don't care how they get the data structure, they're getting the exact same data back from the registry, whether they're talking the new stuff or the old stuff. And the reason we want the new stuff is having the registry manage this for us is great, but in case it doesn't, the client can manage it when you at least have something that's functional. All right, before I go too much farther, I get a lot of questions on this next topic, which is, hey, you talked about adding this subject field to the artifact manifest that you just added. You talked about having the subject to the image manifest, they'll refer to a single image. But hey, what about the multi-platform images, right? And people keep asking that question, can we have that subfield over there so the multi-platform image can point to things? And the way I'm going to start that is to say the picture on the left exists, where if you're saying I've got an artifact and I want to extend a multi-platform image with some metadata, you want to sign a multi-platform image, you want to add an s-ball with that level, you can do that. You can sign at the top level or you can sign each individual manifest, you probably want to do both, but you can do that. It's the picture on the right that we don't allow. And the picture on the right that we don't allow, the reason we don't want to have an index that points back to something else, is because at that point, you know from the index that you're creating both the subject field and potentially all the child fields, which means you can predict both of those descriptors, or not predict, you know exactly what both those descriptor values are. And the way you walk this, even though those things both point to the left, the way you walk this is in a circle. And we were talking about earlier, we made this DAG structure, the directed acyclic graph. I didn't really go into the whole what that means, but a directed acyclic graph means that it's acyclic. There are no cycles. You don't want loops, loops are bad in those, the island. So what's happening here is you have this B3 tag, you have a query of the B3 tag, you pull the image manifest there, and you say, tell me everything that refers this image manifest, so logically you walk over to that index on the right, then you say, tell me all my child nodes from this index, you go walking back to the left, repeat in infinite, and that's no good. The other nice thing we try to focus on here with all the changes we were making was to say, hey registries need to do some garbage collection, even though we don't specify in the spec, they still want it. And so the logic we put out there was to say that as long as you have the manifest exists that you're pointing to, keep the artifact that's out there. So even though the artifact itself isn't tagged, the manifested points to it still exists, so we can say, don't garbage collector, we're still in use, keep this artifact around. And so that makes it a lot more efficient, so when you have a registry out there and you've got all this stuff sitting up in your repository, you don't have to tag everyone, these individual artifacts, keep them from being cleaned up later on. It's nice to just know as long as the image is there, all the metadata is there with it. So we made all these definitions, bunch of pictures, if there are people back there that like to see the code as well, here's the low level JSON, and this is the JSON used in the fallback, so I actually go through and show you, if I pull an image, I get the digest that image, I define that tag with that digest in there, and I go query this manifest API for that tag, where I get back as an index, and in that index, the important thing here is to note that we've got a descriptor that says, here are the different entries in my manifest, and I've got some metadata I pulled up. So the metadata I pulled up is gonna say, here's the artifact type and the annotations, and the reason we wanna pull up the artifact type and the annotations is that when we get a list of all these manifest that extend our image, you're gonna have a signature, you're gonna have an S-bomb from Cyclone DX, you're gonna have an S-bomb from SPDX, you're gonna have attestation of the build process that went through, you're gonna have a whole bunch of these manifest, you don't wanna pull each one and figure out what it is, and so we pull that metadata up, and so this is, the refers API is gonna do this for you on the server, or if you're in client, you're managing this, you're gonna do it yourself, and the place you pulled up from is from the manifest of our actual artifact itself, and so the artifact itself, we mentioned earlier, you'd change that media type on the config, and that's how you know what this artifact is, so we change that config a little bit, you can put annotations over there, you can put all kinds of other metadata, and as long as that subject is there, that creates that association between the two. So I'm sure a lot of people are thinking, this is fantastic, you showed me all this lower level detail that I probably don't even care about, I'll give you good news, there's code that just does this for you all out of the box, and so you don't have to write any of this yourself, right, okay, that's the good news. I will at least show it off, and I did tell you that some of us are just gonna have some of my code in here, there are other options, I'll show you some of the options as well, but let me spin up two registries, I'm gonna define a few variables here that are gonna be used to reference these two registries, and one's gonna be listed on port 5001, the other's gonna be listed on port 5002, and I'm only gonna use some OCI media types for my stuff, so I went through a little bit of effort to make sure that I didn't have to keep track of Docker media types, OCI media types, and other kinds of things, I just kept it simple, so I made two different media types there. The first registry I'm spinning up is going to be the CNCF distribution registry, listed on port 5001, that registry has not been updated, so that is gonna be an OCI v1.0 registry that doesn't have any of the new features yet, so this is as is today, if you went talking to a registry out in the cloud today, it's probably what you would be talking to, something like this that doesn't have the new APIs, doesn't have the new artifact, and so anytime I push something up to here, I gotta do it the old way. The second registry I'm gonna spin up is called ZOT, so I'll come up with another line here, the ZOT registry has been updated, they jumped early on this release candidate and wanted to show off that they can do some new layers and greatest features, so I'll show how that one works, and like I say, their registry supports the new artifact manifest, their registry supports the new referrals API, and it's that latter one that we really care about, and so that API is gonna be interesting. You also see me turn off TLS, turning off TLS is fantastic for demos, not great for production, but it just makes my life so much easier, so I did that. And lastly, I needed to put an image out there, so I went and grabbed an image out from Docker Hub, and I'm just kinda doing a little bit of self-dogfruiting, I just kinda grabbed my own image because I knew that I had on the OCI media type, so I just wanted to keep it simple, and I wanted to keep a single platform, so I actually went through and found the descriptor for just a single platform out there, so I didn't want to go through like a multi-platform index and get too complicated. I like things to say, you know, as complicated as all this text is, I wanted to keep it at least somewhat simple. All right, so I'm gonna copy this manifest over from the internet, back over to my local registry, and then you can see the manifest is up there in my local registry now, and this is, like I say, single platform manifest, OCI, image, v1, all that good stuff. All right, that's just the setup. So we haven't done anything fancy yet, that's just the initial setup, and this is the part that everybody's gonna like, is that the part you have to worry about if you're attaching stuff is a very short slide here. I'm gonna run a sift command to generate an S-bomb, so I wanna have an example here, and pick your tool, I just happened to pick this one because it was very easy, simple one-liner. I'm generating a Cyclone DX S-bomb, and this is again where I'm getting into my regcuddle command where I say I wanna do an artifact put, and so I'm gonna push an artifact up to the registry. I'm setting the subject line, and I'm also gonna start setting some annotations, some media types of other things to say this is what this artifact is, because otherwise it doesn't know, it just kinda puts it up there a little abstractly, and that's not even good.  And so the second example I'm gonna push up there is gonna be SPDX, because I don't wanna pick favorites, if you ever pick favorites in a room of security people with an S-bomb, that's chaos. So I don't like chaos, like things nice and simple and peaceful. So now we have two artifacts are getting pushed up here, and for anybody that's generating stuff that needs to start shipping your images, this is it, you're done. That was all you had to do, and your job is out, finished and complete. And the nice thing is once you have done this, from the end user side, when they start pulling this stuff, they don't have to know where to look. All they have to know is they can list the artifacts on an image, and this will go out and hit that refers API three. The refers API isn't there, it's gonna look at that fallback tag. And there's, we have two manifest that list. So let me scroll back there a little bit, you can see that it is an OCI image manifest, or sorry, there is a descriptor in there with that, this is an index of multiple images. First one being the Cyclone DX, and the second one down below is gonna be the SPDX, and you can see the annotations, you can see the artifact type, all that detail we need to be able to query this stuff later on, programmatically query this stuff later on. So again, this was a tag because it was on the fallback registry, so this tag does exist, it looks a little ugly, so this is why people don't like it, they don't wanna see all these tags out there. The one nice thing is we only have one tag, so there's not like a sig tag, an annotation tag, all these other things, we just have the one tag for everything. And then if I go and query that tag with the manifest git, you're gonna see that this is gonna look very familiar, it's gonna, unless you had a really short term memory loss here, it's gonna look identical to that, three lines up. And in case that was like too fast to go by, I'll even scroll up there and show you that there was here with the manifest list, scroll up a little bit, there was a previous one, they're the same, because that was exactly how we queried it. All right, so whether it's artifact list or the fallback tag, we're getting the same thing with the manifest git as well. So from that, the big challenge is, that's great, I wanna actually fetch my Cyclone DXS ball and SPX, something like that, so I've got the artifact git command here, where I say git me an artifact that has this subject field that points to this image. So I pass the subject and I pass that and I say filter and only show me the thing with this one media type for the artifact. And so now as long as I keep these media types predictable, I can do this and there's my SPOM right just that easy. So for the end user, all I have to do is memorize that last command. They don't have to know everything in between, they just had no last command of when I see an image, run this command, I get the SPOM and I'm done. So that's the nice part, that's the easy part. If you ever wanna do this with Curl, I won't go through this entire slide, but I will tell you that all this stuff, if you don't turn on authentication on your registry server, a lot of this stuff gets easier. If you know all your media types in advance, this stuff gets a lot easier. When you don't know all that and you try to implement that with Curl, it gets a little ugly. So that's where the tools come in nice and so that's where people start writing tools on top of this. But you can actually run these low level queries, get the manifest, pull the digest out of one of the entries and go through all that. If you're curious, I'll leave that for later on. All these slides are up online, you can go replay all these presentations later on, but I don't wanna bore you too much with the Curl details here. I do wanna show you though that we had two registries, right? And I only showed you what was going on one registry. Let me copy this artifact from a V1 registry to the new registry of the new release can of stuff that has the Repers API. And if I do that, copy those quick because it's all local in the same machine. I run the list command and you'll see I get the artifact list back. So I'm able to query this listing of all the artifacts associated with my image. I copied everything in one unit. If I do the tag listing, I don't have that digest tag anymore. I just have my one app tag. And if I even try to go back and query that tag and try to pull it, I'm gonna get, let's see, do I go up on that one? So yeah, I'm gonna hit the manifest API and I'm gonna hit that API for this one digest with that little fallback digest we had. That's gonna come up with saying not found. Four of four didn't even exist. So manifest unknown right there on that line. So without that, you might be saying, okay, how that happened? Well, you saw the big pretty picture earlier on. I just had to hit this new API called refers. I hit that query that API and suddenly what I'm getting out of this was that manifest list. So now it's the same way you get the data, two different registries, two different methods to get the data, but the same data on both of them. So that's the beauty of this. All right, one last bit of detail here for anybody in an air gap environment. Do I have anybody in like DOD air gap environment kind of stuff that has to worry about that? One, two, three, four, okay, handful. If you're at the OCI layout is a great method to move images around on a file system whenever you're copying them. So you can just copy an image from a registry into the structure. It puts it into a directory on the disk. You can zip it up, ship it around, and I can do the artifact list in there. Now, it's just a directory. So I do have the tag in there. I don't have a registry server generating that API response. But in that directory there's an index that basically represents all the tags inside the directory. This is the equivalent of having a repository on a registry on your file system. And then you can just copy this stuff all around. So if you're curious about that, another good side to come back to later on if you wanna look into that and see a little bit more details there. All right, I'm gonna keep jumping ahead because I wanna save a little bit of time in case people have questions or wanna heckle me later on. But there are other tools to do this because I think a lot of people will say, you know, great, you showed me all the Reg Cuttle commands. There is another tool out there called Oris. So if I said Oris, discover on this thing, you're gonna see all those manifests listed in there or all the different artifacts that are associated with my image and same for both registries. Whether I hit it on the new API or the old API is able to find it. So that's working great. And also you're saying, I did all this on my laptop. Well, if I go hit the GitHub Container Registry in a production environment right now on an image that I pushed, they're all up there right now. And so I'm doing this as part of my GitHub Pipelines today right now on an image that's out there in the real world. And again, I could also go through, so let me show you real quick on what that artifact is. I've got three different things attached to it. I picked out Dockerstar generating some of their attestations on things. So I got that attached to this. I've got again the two S-bombs as well. So a couple of those. So as many S-bombs or as many artifacts whatever you wanna attach, attach everything you want to. And also not just Reg Cuttle, I could have also done the Oris discover command again on GitHub Container Registry. And it's gonna say, hey, you've got all these different artifacts associated with this image. Cool. So we've got a way to do this. We got commands to do this. We got tools out here. What should we do? What's the next steps? Where are we gonna go? So for registry servers, this is all a lot of the stuff is still new. We're still creating this stuff.  There's this new subject field we just added. So some registries are a little picky about what data comes in. OCI says you're not supposed to be, but there are a few people that are doing that. So we're working with them. We're getting really close, I think, unless they've already done it. They may have. And there's also the config media types that changed. There were some registries that were saying if it's a config media type that's not a container image, I don't wanna allow it. Docker Hub just recently turned that off and that was awesome for people that wanted to do like Helm charts pushed up there, that kind of stuff. We're finally able to use Docker Hub for this stuff. Additionally, the new artifact manifest. We'd like to see support for that, but that comes with a big asterisk. I'll get on that in just one second here. And the enable the refers API. So that's the thing that I think we're really pushing for right now is to get registries start adopting this. Like I say, release can't, this is just coming out the door from OCI. We've been having means and trying to get this stuff. Getting to a GA release, we're still a little ways off from that, but hopefully in the not too distant future. So anybody that's running a registry we're saying let's get this stuff out there and standardized. I think the more important part is for the people running clients, right? I think we probably got more client people in here than registry people.  We did say earlier on that slide, there's this new artifact manifest we created. I keep throwing asterisks on there. Part of the asterisks is that we're not really quite sure how and when we're gonna transition to that. And so we're still working through those details right now. And the other part of that is that any registry that hasn't been upgraded couldn't accept this manifest. And so for portability, use the old image manifest for a long while. To use this, this is all transparent. You don't know when you're pulling a Helm chart that has came with an image manifest. You just know you got a Helm chart. So who cares what manifest it is for a good long while. At some point it'll be nice to have things that are artifacts look like artifacts, some things that are image look like images, but we're not there yet. It's gonna take us a while to get everything upgraded. The other important thing that fallback tag, if you're writing a client of your own, you have to do that management. If you're using someone who's written the client, they're gonna do this all for you.  But when you have this stuff that's being implemented on the client side and not the registry doing the referrals API, what they're doing is they're gonna have to go up to that registry and manage that tag, which means if the tag's already there, someone's already pushed an artifact, you have to pull down the existing list of all the artifacts, add your new entry to that list, and then repush the new list. If anybody's ever thought about systems where you're doing like a whole lot of things going on simultaneously, you might be thinking race conditions, and that is one of the downsides of this. Is that you can have multiple clients out there pushing this stuff and clobbering each other in the process. That's one of the beauties of getting this done server side versus client side. The other important part here is the artifact type. When you pick that, if you looked at the artifact types, I was picking with the example, with the exclusion of my example early on, I was picking some media types that were well known. They came from IANA, they're registered up there, so if you go and look at Cyclone DX and IANA, they've got their list of here all the media types that have been registered with us. I picked those for all the media types I used, that way anybody else is using the same queries and you can find this same Cyclone DX S-Bomb, no matter what image it is. As long as every image uses the same media type, it's easy to find from one image to the next image to the next image. So you ask people, use some very predictable media types and hopefully that comes from the project itself saying this is our media type that we've standardized everything on. Additionally, we ask to use annotations very responsibly. And it's one of the challenges. We're pulling those annotations up from the manifest up into our listing and there are people who like to put a lot of stuff in an annotation. I'm sure people have been on the Kubernetes side has probably seen a lot of abusive annotations before on your side as well. And container image manifest, they're not overused too much yet, but I think they're gonna get there before too long and what we're seeing from registry operators is saying, if we've got to index all this detail so we can generate this API response, we're just gonna start rejecting manifests so they start cramming too much data in there. So if you want that portability, be responsible, only put the data in those annotations that you need to be able to do these queries on yourself, don't put the whole world in there. Be nice to the registry servers, they'll be nice to you. All right, so the catches, the big catch here is we're not done. We're still implementing stuff. And so as it's still being implemented, the registries, the clients, all this stuff is at various stages. There's still some debate on if and how we're gonna do that artifact manifest type. We spent three hours of glorious, fun meeting time yesterday back and forth and we're still not quite to a final solution. We'll get there, we're gonna work it out, but it's just gonna take us a while to sort out how we wanna figure that out. But for anybody that wants to do this today, like I say, I'm doing this right now in my own images. I trust it enough that I'm putting it out there so you can try it out, you can at least do some experiments, see how the code works for you. And this is the nice way that I think we're gonna see for going forward into the future of how we wanna have these things ported, passed around all these SBOM signatures, other metadata, passed around with our image in a way that we can now associate the two together and ship them together and transform. So I hope we're gonna get to that point. And so with that, I know that was a little bit of a speed run. I know there's a lot of low-level code, but hopefully that answered at least some questions that the future is here for what we're doing and it's been a long walk on the OCI to get to this point. It's been a long, painful walk for some people in the back of the room. But we're getting there to the point we're actually ready for I think end users start using us. So I hope that some people will get a little bit of inspiration from that. So with that, throw it out there for any questions. Do I see it as distribution, discoverability, or both? And I would say yeah, both, because not only can you ship your SBOM and move them around from one place to the other and keep them associated with the image itself, but you can query that image with the listing and say show me everything is associated with that image. And you may not know in advance what all these different artifact types are that are gonna be associated with the image. There can be new stuff that appears the next day that wasn't there before and so it gives you that discoverability. Yes, have I had the recursion discussion? Dig into a little bit more where you're going with that. You can do that, absolutely. And because this is a directed acyclic graph, there is always an end. There is always a bottom to that path. And so you can go down as far as you wanna go. You can have a signed SBOM that's not signed with SBOM type, but just an external signature type if you wanted to. And that would be an external artifact associated with the SBOM that's then associated with your image. You can absolutely do that. Any other questions? Okay, all you gotta do now is just turn it on. You ready? Toddie, go ahead. When can we start the spec for which part? For the cats. I keep putting cats in all my presentations. So I think, yeah, we're right there. We're ready to do it. Let's knock that out next week. All right, gotta have those. I need to include those in every one of my images from this point forward. All right, I saw the stop sign. I think my time is all up. If you got any other questions for me, I think we're just at a coffee break now. So I don't wanna hold you from coffee or tea or anything like that, but feel free to ping me and we'll chat later on. Thanks.