 Hey Emily. How are you today? Not too bad. Not too bad. How are you? Good. Just a new house and new new orientation. I finally got a desk put together. Yeah it's slowly making my way closer to my office. It's only been locked down for a number of months but I'm building an office above my garage and we're almost unmutting which means we get to sand this weekend and get like the primer on the walls. So I started in like the living room and then I went to the dining room and now I have a desk so I have all my monitors set up and like I'm getting closer to it physically. Excellent. I know what it's like. I'm going through the paper trying to get some of the commentary closed out. I've just done a load of it. I might have been coming up behind you. I think there's like three or four questions left. Yeah I'm going. That's about it. I'm at the golden image part right now. I shot past the golden image but I wanted to ask maybe it's an English thing but I've always referred to it as a golden image. Is it a genesis image or thing? No. So here's the deal and this is me trying to like undo decades of bad practice. So the concept of a golden image is traditionally like the source, the thing of which everything else occurs and it's usually like the most controlled. You can use it as an independent verification tool to be like hey or at least within like defense systems you have this team that produces a golden image and then you have another team that goes through a similar process and creates a deliverable packaged good and then you compare the two of them. So any deviations from that from the packaged good that are different than the golden image are problematic. So it's like that usually like when I hear the term golden image I think of it's this thing that sits on a pedestal and like the angel choir is saying and there's light coming down from the heavens on it and it's like you don't touch it. The problem is that a lot of instances where golden images occur as the source of truth they often go un-maintained. So like once an organization produces this they never update it because it's good we don't touch it and that's a cultural change. So part of the reason why changing this degenesis image is to get us out of the habit of like all of the baggage that comes with that terminology and that in this particular case it's not quite a golden image from the original use of the term. Do we need to explain that in the document then because that's a bit of a change to the way I use the term. So that's the problem is like the term golden image is a very overloaded term and the only reference that we have to explaining what this new thing is is the base container image of which the build worker is based. Yeah. Which you could probably just call it a base image a base worker image and be done with it and then you avoid all of the baggage that comes with things like golden image meaning it's good enough and we never touch it. But that's why I'm trying to like trying to read through Justin's comments. I get his concern. I think it's a valid concern because it's it's very overloaded. I try to avoid golden image whenever I can because it's just a bad history there. So if we want to call it Genesis image if we want to call it base builder image maybe that's maybe that's more explicit and clear. I guess base image is maybe clearer and just trying to figure out is that does that pertain to the the entirety of the context. Well, so the only other reference I think that we have is in that same section and I have not gone through and done a control F on this is the build environment consists of all the content required for the build including the sources for the build in any of its dependencies excluding any tooling provided by the build image. Yeah, we've we've got four instances of that three of them are in that same section and one of them is way down below in containers as build workers again same context though. Yeah, so I think if we're if we're going to make the change it needs to be consistent because we're really we're genuinely not talking about a golden image and it's traditional sense. We're talking about the base image and that this is the thing that is not part of your software product. It's not part of the end result of what's being built. It is an ephemeral object that is spun up, serves its purpose and disappears. I'd go with base but but I'm only call Alex Vinod any any thoughts but you know we're discussing the image about there's a section on page 24 build step and worker when we've got a we're talking about the point one a golden image is what's used to base the build worker upon the gold image genesis image or in real reality base image. Yeah, so I'm I've changed it to worker image for the purposes of this conversation to kind of make it a little bit simpler. Yeah, yeah, I think that makes sense. I think actually in fact I might have been the one who originally called it golden image but I think I was also ignorant of all the history behind what what golden image has meant in much of the community. Yeah, it's one of those like what tech is 1942 I think so it's well over. It's it's almost in retirement age at this point but the term golden image goes back I think like eighties and nineties. So I'm good with work of base image. Okay, let's do with worker base image and then we should probably just provide a little bit more of a clarity explanation about why it's included excluded. So I just added as this tooling is not part of the end product being built and hopefully that should alleviate Justin's concerns and I can make a note to chat him to double check that section. Let me get that golden thing again. Work of base image binaries from the worker more down the bottom. I've changed it in the other places too. Okay, Justin's got a comment on the set. UID, GUID, there should be one of these privileges. I linked to this comment as generally to it should be the same one but it is true. So I would agree that we need to say the build container should be run with the least privileges. Sorry, which which where we know build pipeline to create build stages. If you I think I'm logged in. So if you're in a Google doc and somebody is doing something and you need to find out where they are, click on their icon and you will automatically be taken to where they are in the doc. Which one are you should be logged in? Oh, apparently I'm not. I don't know what I am. All right, I think I'm in the right place. Yeah, there you are. Hey, Richard, I'm wanting obvious impediments to security configured with least privilege is in the build container. I think we just add in the first sentence that it should be. Yeah, that's what I was trying to figure out is like where where does it fit best? I think either the first sentence or a new sentence at the very end of the paragraph would be my two thoughts. From a minimal image, I think it's a strong point, right? I guess my my view might be the front of that. Yeah, do you want to take a stab at it? Or should I do? Literally run with least privilege. Should we specify how we can do that? Um, rootless. Oh, you're now I got to go back and think about which which builds use rootless. Is it builder? No, builder's got a backdoor root in it. It's not like truly rootless. Hold on. We could just we could just make a reference to the rootless container site, which has articles on while since I've been there. There we go. At the spot, I think I'm at the spot. Insert, footnote, awesome. So we have that. And then I think we should add the footnote about the set UID and we could just. Generally, this should be disabled in a high assurance build environment. I'm going to I'm just going to accept that comment then, right? Yep. I've already resolved that relevant information from Justin's. Yeah, cool. Still getting used to it. We can fix formatting later. All right. Done. Yep. I'll accept that other comment too, right? Resultery. Yeah, so I'm going to ping Justin in the channel just like he's aware he'll get the email. So I think the next one's down to like page thirty one, thirty two. Yeah, I'm down there. Let me read through this. Very useful builds improve on this. But I think it's. It's confusing the previous part, but she's very very too. Oh, you know what it is? We talk about deterministic builds. So I think it just needs to be moved around. Yeah, so the way I read this, it's I think what we're saying is a deterministic bill is a verifiably reproducible build is a step above a deterministic build. Is that what we're trying to say here? Yeah, and that's not how we introduced it. I mean, it is, but we kind of sandwiched that statement, which makes it very confusing. So OK, does this now that I move things, does this read? This is equivalent. Yeah, that's a lot better. I think I think if I accept all of these comments, it would be easy to read. Yeah, OK. I mean, I think I got rid of that hanging paragraph there so that those you accept that last one, it should merge everything in. Yeah, I think it looks good. So I have another question. Are we still using the term I.T. anymore? Like you usually in conversations, we refer to the industry or the community or the system, the application. Go blanket software industry. How about that? That's fine. It was just it was very strange. And I've used that in quite a while. How about software industry or something like that? That's fine. We've also got I.T. Systems in the next area. So just change that to systems. Also, Trojanized is a word now. What's that? I have seen this twice in the past two days, the word Trojanized. We have it in the blog and we have it here. I like it. I like it. You can use it to there's a psychological component to it. I went in this meeting and Trojanized the outcome. Yes. Yes. It's an awesome term and it's like. I've never heard of it before, like the paper and the blog and I'm in love with it. You know, when you type in Trojanized it, the very next, if you put it in Google, it's just Trojanized Solowins. I guess that's one way to, like, just try to rebrand SolarWinds a little bit better. Literally, Trojanized meaning and then Solowins. They rebranded to enable, which just is hilarious to me. Trojanized. Yeah, it's a thing. What size are front notes supposed to be 10? Now, what's going on with the highlighting? Is that some weird highlighting on the word Trojanized now or what? No, I don't see it. It looks clean to me. Oh, weird. That's odd. It looks like, OK. Yeah, I've got some weird highlighting on it on my copy for some reason. OK. Do you have control light for something? Let's see if I can spell the day. This is 11. Should be that color. Why is it different? OK, now that I'm hopefully done futzing about with the font. I don't know. Somebody has to fix the font. Google Docs hates me. It's not letting me do it. So on the front, let me let me supply the thing to start with it. It's supposed to be aerial 11, not Roboto, 10 and a half. What? Oh, OK. There you go. Awesome. Someone fixed it or am I? No, no, except at the change. Damn it. Yay. All right, so this should fix Justin's last or last comment here. Is the font color the same? Yeah, it is. No, it's gray. Are you serious? Yeah, it's been killing me all morning. I have like these new monitors and now I can notice font color distinguishes at that level. Wow. Yeah, the easiest way to tell is if you click the end of the sentence and you click up higher in the paragraph, if the little text color icon turns white, like it indicates that there's an inconsistent color between your selection. So I've changed it to black. Well, I never found that, that's for sure. I'm learning all sorts of new things about Google Docs in this journey, I tell you. This is now my preferred editor. Oh, here's what happened there. Follow. All the comments? I thought there was some of the bottom. Yeah, there's loads down at 40 something. Yeah. Whoops, someone did that. Oh, these are. What's going on here? All right, references. We don't need the word ref in front of these things, right? No, it was a little mistake before I accepted the Y and then it was a different position, but. No worries, I'm just deleting the ref and then putting it like that, right? And we need these in bold as well, right? Yeah. I'm not sure I entirely agree with the first part of the appendix statement on containers. Feel free to. I was attempting to rewrite it based on my own confusion around the highlighted part from how it was originally written, but feel free to rip into it and change it around. I mean, generally, one app can be consistent of several microservices. So it's really one or more than one micro service for one container. It's, what is it? Maybe app isn't the right word there, but. It's like there's supposed to be a term that talks about like minimal functionality and like separating the different functional components to do the one thing that they do well and encapsulate them such that they do that thing. That's the genesis of why libraries exist. You write a library to do a thing. Right. So we could just get rid of that and then there's no arguments about the statement. That any given container may include numerous software components applied by multiple vendors. So I think the clarity here should be called out as both and that container bloat is a problem side of reference to what we mean. Maybe subject to container bloat. What is the paragraph actually there to provide, right? It's a good question. You refer to it in the document. Yeah. So we've got containers, right? And it explains what a container is. It's got container based container images, containers as workers, docker files in here, multi-stage docker files. I'm just wondering, it's a bit, it's a little bit muddled because it's, are we trying to explain what a container is? Oh, that's a good question. We really should not be explaining that. I'm all for just deleting that entire paragraph. Yeah, I think we probably could get away with that, right? This is the appendix. Do we really need an introduction to the appendix or can we just jump right into the base container images? There we go. Yeah. It's gone. I'm just going to delete the thing. I don't accept your, because I'm going to get lost trying to accept all of the comments. Yeah, no, you don't need to. Cool. We need to drop a, all right, the spacing is all right. No, it's all right. So the only question here, and it's right. OK, so we've got a containers appendix. It tells us about base container images. It tells us about containers as build workers. And then it talks about docker files and multi-stage docker files and configuration files. Shouldn't slimming container images be heading up? Because right now it's sitting underneath of docker files. Yeah, yeah, it should, yeah. OK, I'm going to have to run in like two or three minutes. That's bumped up. That's the end. Awesome. This is fabulous. I'm excited. So what's the next stage, Emily? I think we've had comments open for a while. We've gone through lots of comments updating it and such. So right now we finalize it. The next SIG meeting, we should do a status update to let them know that it's been finalized and that we're going to start working with the CNCF to get it published. And I need to look up what that process is, because it's been a long time. I think we start with an issue that gets submitted to the CNCF service desk to get support for conversion to a PDF as well as conversion to Markdown. We need to clean up the supply chain part of the repo to ensure that this has a place for it, because I don't think we have a paper section. So we, as a SIG, need to decide where we're putting our papers, how we're managing them. Like the Cloud Native Security Paper is a general one. That's fine at a top level, but a supply chain paper, we already have a supply chain part of the repo. It might make sense to disentangle some of that. So that maybe somebody should drop that on the agenda for the next SIG meeting to figure out what it is that we're going to be doing as far as paper management within the SIG. Yeah. Cool. And in terms of this document, given the agenda, are we still open for comments and keep that open? Nope. We're done. Yeah. Shut it down. So if someone could add to next SIG meeting agenda paper management, because we're close to being done, I will attempt sometime this week to contact the folks that I worked with last time on the paper to figure out what the correct process is, because I think we stumbled through things last time. Other than that, reviewing the blog, the draft blog, and making sure that it's consistent, we should be good to go. Awesome. Congratulations, everyone. That was cool. There's a lot of really good material in there. There is. It's exciting. It was a momentous feat several months. That was significantly longer. And yeah, but enjoyable. But enjoyable, most for sure. Cool. All right. I got to run. Have fun, everyone. Congratulations. Take a break. Enjoy KubeCon. Thank you very much. Thanks, everyone. Thanks. Thanks. Thanks, Alex. He's gone. He did a load of work on that. It was really good. Yeah. A lot of editing. Yeah. All right. We'll catch up on the other side, all right?