 Hello. Hello. Sorry I beat you Emily to the attendance list. No worries I was actually getting ready to copy the template over and I saw somebody else had just done it when I almost hit control the. Sorry, my clean responsibility for that. Emily how long will you need for your section or just on the time adults and save I'll be joining. I can't imagine I would need more than like maybe five minutes. I mean you guys know how fast I talk so. But there might be a lot of conversation aside from me, explaining it so I would, I would probably venture on 10. Okay, sounds good. Just that people join in. All right, cool. It seems like we have. So let's just kick this off. So as usual, this meeting is being recorded and CNC guidelines applied to this. All right, so I'm going to go through the this of attendance, see whether we have any announcements. So let's start. Magno, I think you had one. Do you want to. Sure, sure. Yeah, just a reminder for that were March 17 meeting that we're going to have Jen Burns, since the last one was canceled, talking about tech for containers. And people asked me to remind them about that a few meetings earlier so I'm doing that. Awesome. Okay, yeah looking forward to that. That was on the attack matrix right exactly on attack for containers yeah and Kubernetes is cool. Right. Yes, agenda items are good there. Okay. And Diego I'm assuming your data is in the agenda item right so we covered we're going to cover that data. Okay. Ash, thank you for volunteering to describe. So let's get started before that any other new folks new introductions. Cool. Okay, so let's get started. I think that the first, the first issue that that we have from the agenda is actually about the cognitive security map. We presented a few weeks ago about the version to a cloud native security landscape, which we call the cognitive security map. And so we have started a new project now, which is going to be kind of like the first version one of this cognitive security map. So I'm going to share my screen. Really quick here. All right, so we have this new new issue now so we've sent our email to the cognitive security mailing list. So you can look at that to kind of get a good idea of what it's about. But the information is also encoded over here in a different way. So this is really what we're doing is, this is taking the concepts of the white paper. We're going to cognitive security map which really focuses on the more practical practical use aspect of it. So looking at things like the different projects which you can use on different aspects of cognitive security as well as, you know, what are some examples of things that you could do. We are open to flavors of this right. So this has been that will maybe to like magnificent with the chocolate for the next iteration. It's only at more spice into this. All right. So this ends with the previous issue. But I kind of want to really go down into the details of this. What we're really doing is we're trying to scope this down really bring down several aspects of the original vision, which is like removing some of the thematic aspects first. Focusing on the content. And we hope to get this done by the end of March at least to have a really prototype in which we can start refining a little bit. And then we're hoping to kind of launch this that keep on you. So this is where we're going to get a lot of additional eyes on this. And hopefully, you know, bring this the next chocolate version of strawberry. So kind of as an overview. So this together with Ash and Diego. We are coordinating this effort. So this is kind of like a quick mock up on what it will look like. So currently the security map. So you have the different stages of the life cycle in the company the security pipe paper. So you could go into the different ones, you know, security tracks of them on tests, you go in. And you could go into distribute you have different aspects. So it's a good way to kind of like explore the different areas of security. And so a lot of this content right now is just content from the white paper. So Diego and Azure are going to go through the content aspect of this so right now it's all just white paper content. So what we're planning to do is to, you know, include additional details of okay here are some projects they can use. Yeah, some examples that that you can carry out as reference for implementation. So let me go back to the issue. If you're interested and we've got some comments origin here. I think the next kind of big point to look at is really this cognitive security map. Google document. We have already some contributors that putting your name down. So we are looking for contributors both in two areas one of them is in developing kind of the website that we saw earlier. So if you're interested in that to put, put down your name in the issue and say that you're interested in development. And we are also looking for content contributors. So I think Diego, do you want to, do you go as you want to kind of talk about content contribution. Yeah, sure. And so, yeah, you want to keep the document open and we'll be fine. Yeah, so as Brandon was saying, we will love more contributors to in this effort and in this document that it's linked in the issue. And just please bring us either put a comment in the issue or see the dog that we are specifying and a channel at the top of here in the edge you can see this like channel that we are. Just tell us that you want to help and here in the document, how you can contribute, you can include your name in the contribution table. So here we will assign the specific topics to each person who wants to help. And if you go a little bit up the document. We are putting the example on how it's going to be in a specific section that you can add it's identifying the projects that are relevant to that area. And putting some examples of why that it's a good example of a practice, and even extending other links for more context and information on that topic. And I think that's the main theme for now but we have, if you can see in the table, a few, a few areas that we need help. Yeah, the more the merrier. And yet if you have any questions, please bring us to Ash, Brandon and me and come in the show this lecture now that we will happily impress you to conclude. Did I miss anything else. Yeah. Yeah, I think our everything just your one more thing to add would be the projects in the list can be open source projects, preferably CNC and other non CNC open source projects, and we're also accepting some like commercial projects as well in the list of projects, but they'll be lower priority compared to the open source one so feel free to add your name to the contributing the subject you want to contribute to and then add the projects in the examples that you want to contribute as well so Yeah, so happy to help you all with those contributions and if you want to contribute to this effort. Thanks. PJ do you want to mention what we discussed in the earlier meeting about the white paper and the branching off of that that paper to this map. PJ. Okay. So yeah I'll go ahead and talk about that like we had a previous meeting me PJ and Alex about the retrospective of the white paper at the survey that you want to send out to people about the white paper. And so we thought, at least we discussed this that the white paper is more. Okay, sorry. Yeah, feel free to chime in. So the white paper is more like awareness document right so to raise awareness for cloud native and everything is not a is not a tutorial it's not a cookbook is not it's nothing like that and we understand that. We hope that people will understand that as well but but like, if someone wants to implement a specific section of that white paper right that that best practice of security. So basically, let's say for runtime protection right so where where the where should I go right so what where they should should they look for right and we thought that a good idea would be to have this this map as more technical and more detailed information from from the white paper, instead of having the white paper with like a lot of technical information. I'm not sure if that makes sense. But it's this well said and I hope that this this document will kind of like me at least half of that requirement right I think that we are still not going to be at the point of like the cookbook or something but definitely it's going to be like some starting guidelines to kind of getting started. I think a cliff notes if you don't mind me kind of chiming in I think cliff notes are great here right because look they're already inundated with, you know, guideline bugs and best practices right this to me cliff notes is I use the term if nobody's familiar it's just like basic like a TLDR. This is like a TLDR, but works right. That's a good way to. My brain so small I can only process things in that way. All right, cool. Any other questions so we will follow up. Actually, I got myself will follow up on on those that have commented the issues to kind of see see what will be good places to kind of pick up. But, you know, this is good. This is going to be a fully cut everyday document so even if you just request access I'll give you access start writing stuff. Feel free to go ahead and no one's stopping. Brandon just a question so in each section we need to mention different projects, like for example, we can take service match or anything right. So, so projects can be mentioned but what you want under the examples are these more oriented towards different use cases that that could be solved or, or what. It should be under examples is it use case or is it I mean, is it right post what is it. So, so the idea of examples really that the motivation behind it is that is to provide like a better illustration of if someone says we supply paper and say, okay I need to do this this that. And then the next question is like, how do I do it. So the examples are supposed to serve as a way to say that, okay, a control for example for image image scanning or application manifest getting is you know, you should not run application manifest should be scanned so that they're not running as a root user for example. I think I think it also depends on the specific topic because some topics are a bit broader than others. But the main ideas you know it should be of feel free to really go down into specific specific example so in this case for application manifest scanning. And we say that you know prohibit content images that use the latest tax, you know, for him, and for certain registries for containers and things like that. So kind of like ideas that people can look at and be like okay maybe this is something that I can do. And, you know, obviously not a comprehensive list of all the things they can do by at least give them an idea of what they can do. Okay, yeah, thanks. And super quick observation if I may. This is great stuff by the way, on the title of this activity stream, would you mind renaming this to plain from vanilla, we're international community, like the nuance of flavors get lost in people so if we want to call it like plain or high level or basic that's probably more descriptive. I was going to the Android route with naming. Yeah, I think that it wasn't so much kind of like this would be the plain one but it's just like a versioning a virgin name. Yeah, cool. If not there are the examples you know actually when I have really put some I think this one was actually written by kind of a poet is written by someone else from the APEC meeting. But yeah, this is this a ton of stuff that's written here so you know if you feel free to take a look at other stuff and then write based on that. Cool. If not that sums up the section and any last questions before we proceed with the agenda. Alright, if not Emily, all yours. Okay, so this is actually kind of exciting because it's a little bit more actionable for the community. So we had so we merged and the new security review process if you have not read it please go read it it's very awesome we're extremely excited about our next projects coming to us for review that way we can test it out. But to that effect, the security review process which I talked about last time is broken up to better align with the project maturity. The co chairs had wonderful meeting with our talk liaisons, Liz and Justin to discuss these new changes and we were trying to discover a way that we could introduce security for non security focused products in the cloud native ecosystem and one of the recommendations that we came up with was this concept of the security buddy. And what that means is, we'd like to look at a one or two non security focused sandbox product projects to take advantage of our self assessment template which is new and the security review process and assign somebody from the site to engage with them and kind of walk them through completing the self assessment. Now the self assessment is designed to be, excuse me, that initial understanding and self reflection of a project state of their security. The security buddy would explain security concepts to them, potentially have the opportunity to join a security focused mailing list for the project to help guide the project in making more informed security decisions. The intent does not to have them be a developer or a contributor on the project per se, but to be more of an independent security advisor. This model is currently in use by container D, which is actually really neat. There's a lot of good information on it. I wanted to propose it to the group to kind of generate interest, see who would like to be able to learn more about a project that's currently in the sandbox stage, walk them through what self assessment actually looks like and start engaging in those conversations. It's a good way to bring more non security projects into a security behavior and also expose them to different portions of the CNCS as well as that cross knowledge and collaboration within the group. So, I guess a quick question. I guess some of these details may not be kind of formed up yet, but this is something that the TOC is going to say, okay, every sandbox project will be attached to someone for a certain amount of time because I know that projects can be in sandbox. So this is not at this time determined to be like you are fixed to the hip for life. This is more of just that initial jumping off point to get the projects to think more about security. It's also to provide the talk with evidence of this new security review process and how it could potentially be applied to non security CNCF projects, which is the next logical progression that we'd like to see projects move and we want. We want the SIG to not just perform security reviews on security focus projects because they're already thinking about it. It's the rest of the ecosystem that could potentially have significant value add even from the most lightweight review or even discussions about the state of their security. Is there any particular reason why it's targeted at sandbox, not incubation or anything else? Um, it could be incubation. There's a fair amount of projects. Give me one second. So not really anything in particular, but we figured if we started with a project that is early enough on in their maturity, the self, the self assessment better aligns with that, whereas projects that are coming to us for incubation have are slightly further on. We would expect a self assessment probably to have already been performed and then they would be receiving a joint evaluation with the SIG. So kind of trying to set it up so that these different templates and documents for our overarching security review process has a better alignment with the CNCF phases for early adopters and early majority, as well as the very early innovation projects. Okay. So, so my question would be, and I think Frederick mentioned that in the chat there, like the first question would be why not security champions, right? Because on the dev tech ops approach and everything and we have that concept of either a developer or application security person that is involved with a squad or a development team to help them and to champion those security initiatives, right? So maybe creating a new name would cause maybe confusion. And I think that the concept is very similar here. And I really liked that that that that we're doing that I'd like to volunteer as well. So, yeah, that's it. So I think the initial thought around security champion is more somebody that's integrated with the project, which we're, we're hoping that these are more independent than an actual contributor of the project. It could be a security champion. I'm not fixated on any particular name. We want to approach it from the perspective of a lot of security professionals are usually seemed at or viewed as kind of like the enemy, the thing that stops developers from being successful or being able to deploy faster. And we want to be that security friend. We want to come to them and be be part of their team, but enough that they come to us and they're, they're, they're listening to us. So whatever terminology works best to kind of relay that message in that position, we can certainly go for it. I will be writing an issue to define a lot of this. So part of the effort is to not only look at what this individual would potentially be doing. We do have some great resources from the container D team. But also actually picking a project, seeing if they have the appetite for this level of engagement, and then following through with probably one, maybe two different projects to determine one is this if is the self assessment valuable as it currently exists and two did the project get value out of the engagement. Okay. Okay, got it. Yeah, yeah. The name, the name really doesn't matter, I think, for my perspective but yeah, I think it could be also sidekick right pop sidekick would be a good name as well. For I'm sorry, what was that for the security buddy. I think we already put this copyright infringement. I'll talk to my people. No problem. So, so yeah, I maybe like my concern would be if someone starts getting involved into a specific project right and then they can't help anymore they start volunteer they stop volunteering for example right so maybe having a pool of security buddies. Right, that each any project you go to and ask for help, and then someone takes takes on that issue and help them specifically and and if someone is not responding then another person can take that that would be a better approach from my perspective. Is it visor to generic, or is it to advisor seems to kind of like high level. advisor is actually what they're called for container D. So, that's certainly like, that's certainly an option. I think having a poll of these individuals would be beneficial as like a centralized point to contact, but I genuinely think that having a primary at least for a limited engagement would be very beneficial because you've got that one person. You know who to go to you know who to have the conversation with. Sure, sure yeah yeah once once once they get assigned to like a specific project that and then yeah for sure that would be the point of contact there right, but but I think that at least we should have a slack channel of security advisors right and they can exchange information if they need help like for example, I'm helping this specific sandbox project but I'm not very familiar with the technology or what they're using. Can you guys give me some pointers there and that would be beneficial as well. I'm not really familiar with what I call how I'm secure. But seriously, I'm, I'm sort of listening and thinking about how I'm not too familiar with the sandbox and incubator here but thinking about Apache, and they're mentoring for incubating over there. You know someone one or two people get assigned to a project. If it's not working out or they get too busy they sort of go back to the, to the dimensioning team and said hey look I'm too busy I tap out and bring someone else in so that that's a pretty small deal I think. The overall idea sounds interesting I'm curious to see if that becomes something which attracts people into Seattle or are the opposite. So, so Emily from the six perspective, won't this be like the similar process like we do for a normal security assessment right we're going to have like a security reviewer. We're going to have a team. So from a sick perspective it doesn't from our perspective it doesn't matter if it's a security or non security project on the other end. We still have that same structure, so that we have some accountability and obviously there's going to be overview by the co chairs and details if something is not going as expected or is taking too long. Then we can obviously intervene so on so on one side I think is the same process, like on the management side but the question is what's the incentive on the other side for a non security project to actually take this on. So this is in an ideal world if I had my way this would be like the dipping your toe in the water your first introduction to what it is what it means to be cloud native secure for non security focused projects now if there is a security focused project we still have a reasonable expectation for them to have some security specific documentation within their repository. And that's kind of what the self assessment does is that it's that introductory. Tell us about your project from a security perspective, these are the things that you should be thinking about and if they are a security focused project they've already probably got that we would just like to encourage them to document in a standard format. And then that self assessment, actually a lot of the content there feeds into the joint evaluation which is part of the new security review process. It's the same joint assessment joint evaluation that we've been doing with some more detail added on to it, just based off of the feedback that we've received so self assessments a little bit more like wait, it's independent so the idea is not to analyze the project but more for them to be self reflective and be there and available to answer any questions that they may have and kind of have that guiding conversation. And then all of that work grows into the joint evaluation where we do that joint kind of look at the project, poke around at see how they're thinking about security and how they're applying it and where they fit in the cloud native ecosystem from a security perspective. And then from there, those two documents when they're finalized help contribute to the security audit, which is one of which is later on in their life cycle we found that a lot of the work that's been done from the security assessments by the SIG has been significantly helpful to the security auditors. So it sounds like there's a lot of discussion about it and would be beneficial to have. So I guess I will go ahead and create the ticket and we can start having a little bit more documented discussion on what does this mean and what are we going to call it Sarah had an excellent suggestion to use a very specific name affixed to this. That way we can define a finite term during that evaluation. Awesome. Cool. Thanks Emily. And I think that our last agenda item is for the confidential computing project. Eva, are you on. I just joined. Yes. Awesome. Oh, yes. Oh, okay. Literally just joined. So the, I wanted to share a project we just launched coming out of DS labs at Microsoft, called mystic hosts. The, you know, the one line Twitter pitch is bring your own application binary container or VM and run it in an enclave. Some limitations apply. I'm already chatting with a couple of folks in this committee, and in the CNCF about using this potentially in projects like spiffy or an SM for taking advantage of the unclad native functions of attestation, setting up neutral TLS. And sort of wanted to see like, hey, we literally we just launched like a week ago. If folks want to kick the tires or check it out. And we're looking at how do we integrate this with Kubernetes. And how do we integrate it with other projects in the space. I don't have a presentation to give on it though I could spin on up if folks want me to like do a technical walkthrough of the project. Can you, Eva, I had a question. This is the name here so how. How do we think about this, maybe the one thing that came to my mind is service mesh right you talked about mutual TLS, some kind of a confidential container or runtime environment and you're adding on some kind of security capabilities. Just briefly compare and contrast the two, and how we should probably think about, think about this, just trying to understand on create a little bit better to the. Are you asking for a broader context of what is an enclave or a trust execution environment or more how does it fit into the container ecosystem. So all of the above maybe this does require maybe the deeper that but anyway, no worries, thank you, but I think all of the above. Okay, so a hardware aided trust of execution environment, basically takes advantage of some properties of processors that are kind of new still coming out but at this point all the major clouds have either sgx or arm trust zone or as a capability. A lot of these provide similar functionality through different API is like it's not yet standardized, each CP vendor has something different. Each of the cloud providers has some sort of an attestation service or attestation model that is layering on top of these. The attestation in this scenario, sort of the proof of identity of the machine. And the proof of identity of everything under it, the ability for the, the user of the cloud or the person who is defining the policy and orchestration of workloads to say this particular application or container can only run. The underlying host meets these requirements, this firmware this patch level this operating system patch level, then once it's running. That container is isolated even from the host. So the root of the host don zero if you're in Zen cannot access it. They were separated with encrypted memory regions. I'm not sure, you know, they all do it a little differently, different CPUs but the goal being to the blind hypervisor, or blind container, in this case. We're looking at some of the was chatting with a couple folks about using it for mutual TLS in service mesh, where the certificates are tied to the actual hardware ID. You have just an extra layer of proof of where the communications happening that something hasn't been moved off the cloud or out of your region out of your geographic boundary boundary area. So that's sort of a shotgun of ideas. Yeah, no that that's very helpful just one other question is given the, the scale and the ephemeral ephemerality and the dynamism of container workloads. How, I mean what is the time to set this up get it booted running and is it even conducive for this kind of workload pattern. Great question. It's going to vary by implementation. Think we're at the early stages right now. Some similar projects launch times a little bit slower than a normal container, but not by much. Not be great for function as a service yet if you're expecting you know sub the second total runtime total lifetime for your container. Because, at least in, in my testing some of our testing the bring up time is measured in the less than a second, but it's not as fast as a regular container. So that'll change depending on how much memory you're allocating so if you were allocating a very large amount of memory to one of these enclaves that initialization might take five seconds, play number out of a half. Still if you're going to run it for an hour or six hours the length of your of your SSL certificate that's still fine. Very helpful. Thank you. Great question from Cameron on where are these being discussed is it under. So there is a separate foundation parallel to the CNCF also under the LF called the Confidential Computing Consortium. And a lot of this work is centered in that body. And this particular project mysticos is right now not homed in any foundation it's just developers doing some work. As far as the discussion of surfacing this up into the cognitive ecosystem. I think that's here, at least for now until it in grows it out grows this body and needs its own channel. Yeah, this is a 10. I made me some contacts here so I have a question regarding the music as a part you mentioned. So you have mentioned the hardware ID, some curious like, do you use some tpm or other technology to make sure that you have to present, get the hardware ID and put that into the processor. So a te is another type of hardware, different from a tpm it provides similar functionality though. So you can think of it in the sense of tpm provides attestation of integrity of some devices in the system as well as some key it might have stored. Trust zone wrong. I'm trust zone is one implementation of a te. So it's SGX. So it's a MD serve. Also IBM pfcf. Right so each of these you can think of them like a tpm, but also has memory isolation and execution capabilities for arbitrary programs. So, are you saying, like, for the key framework, we do not need to care about like it's on server or, or, like, how can I say, the, like the traditional x, it is a six server right. So it's not a matter right with tt. So, one of the things we're trying to do is build a cross te compatibility layer in the runtime engine itself. We don't have that today. We have the framework for that and we've done the work for one te target and one generic non te target. So if someone wants to come work on the trust zone or the SEV support we would love the contributions. It is certainly the product goal from day one to become a runtime platform that spans across all of the different CPUs that provide this capability. So the question on this is this kind of like a, I know there's an Enox project which kind of wanted to do that. This is like the work that's together with them or this separate project that's. Yeah. Good question this is a separate project with different goals so there's some overlap nrx is was the wasm runtime abstraction plus a bunch of the run orchestration. I did a complete ring. We're talking that nrx type of that. One second. That's right. Mystic. nrx is the red hat project. Yeah, I'm talking about the slabs mysticos right now. Sorry about that. The main difference is nrx is focused on was the wasm plus its own orchestration and key release layers mysticos is focused on application portability so bring your own runtime. Bring your own application whether it's a binary you compiled and rust or go or a Docker image right now we have support to just take an existing Docker image. That is, there are some some limitations of what can be run in our current target of SGX. But take your Docker image simply migrate its format at a at a signing or attestation around it and run it in enclave. No problem we have a proof of concept with Kimu right now to take a Kimu VHD file format and just mounted and run it. So very different approach but same hardware layer. This is something that I've seen recent work on this issue in Canada continuous now that's kind of discussing. Yeah, confidential computing. You can. Sorry, I was just thinking like you see this kind of like being orchestrated as a type of work the local committees or something like that. I do. Yeah. In Azure today, we have jade product for a cast support for SGX. So it's a type of node or property of nodes you could schedule workloads to. And at the moment that would just be an SGX device available in your in your node. If you had an application that was written to use that it could use the raw device. What we're talking about with this would be a little bit different potentially. Or you could, you know, your Docker container that you schedule on a cloud might itself contain an enclave runtime like mysticos or Auckland or graphene. I think the container work you're referring to. Last time I chatted with that team they were using Auckland plus in clivari. Yeah, this this new revitalization of the issue now. Yeah, we started discussing it and then I got painted on the images stuff as well. Something to look at again. I see a question is general portability and issue for an app. So there are limitations for two limitations that are important to mention one is SGX doesn't support fork. So some of the SGX runtimes like graphene they work around this in a really slow and painful way that also, in my opinion reduces security, because it calls out to the untrusted host whenever you fork to launch a new process. But if you're assuming that the new process is trusted because it was launched from in the enclave. The reality is it was launched from outside the enclave. There's a paper that talks about this. I'm trying to, it's called a fork in the road. David, can I ask a simple question and again, why wouldn't you just fold this capability into one of the runtimes like cryo or container. You don't mean like have some type of switch that says hey, take advantage of te and all that. And again, I, you know, you know how I am with cliff notes I just I try to simplify things right so I love that you thought of that. The shorter answer is we haven't done it yet. But yes, please do it. Because that would be incredible right just talking to those individuals like look now you have the ability to say yes my containers or my runtimes are secure and they attach to some type of hardware equivalent like that would be fantastic. I remember back in the day like this way back in the day Docker was doing I was at HP Docker was like hey can you integrate you know, can you integrate with TPM right to be able to like have it so like you know getting that stuff. And it was like that kind of helped to kind of articulate some of that capability but that also helps in widespread usage of the tool when it's integrated integrated in all the ingrained in all of those various run times right so that's the ability for this to be connected as a container D runtime plugin. Yes, absolutely. Like that is incredibly desirable and part of what we're working towards but you know, do you want to do that. Go for it. I'd love to see it. The tricky part there is that that's definitely interesting but how do you do it for a different CP architectures right and uses different than Intel is different. The scope here is that mysticos provides the portability layer across CPU architectures and then container D simply calls into mysticos mysticos detects what it's on and launches the appropriate way. Have you seen kind of like, I know each enclave or you see has its own like attestation. Framebook and some of them match these different ways or that's like, oh yeah, unsolved problem so one of the bigger work streams in the CCC that I'm co leading is the attestation working group to try and address both how we how someone might do cross cloud attestation because Google Amazon and Microsoft's cloud attestation services are different. And how you might do CPU that cross CPU architecture attestation for the point we just mentioned unsolved problem if you want to work on it come join our sick. Can you put a link to that that that's like that, like how to join I think there were a couple others and they were asking as well. I haven't yet created the like a mailing list or a slack for that said yet. Things are a little slow to get started sometimes in a new foundation. The official vote to create them happens next Thursday. Can you post where the, the CIG is where you guys meet and whatnot. There's an online doc for that. As I said it doesn't technically exist yet. Okay, we are forming it right now I've been trying to corral that for a little while. You can certainly join the CCC discussion lists. And I'm going to get a link that works to that right now. I'm going to use the main page. This should get you to the mailing list. So it'll be a sub project under the tack, but it'll probably have its own mailing list in its own channel. Awesome. Thanks. And I guess when the, when the sick details up, you can, if you could put it in the security channel, you can just send it to one of us and they can dump it in there. Awesome. We almost all the time so any questions any call to actions. Awesome. Not thank you Eva. This is really helpful I, I think a lot of people are keen so hopefully you see a few more new faces. Alright, I think that is all that we have planned for today so any additional topics anyone would like to bring up. All right, if not see everyone next week. Have a good one. Thank you. Thank you. Bye.