 Hey, Matt. Ms. Marco. I'm not sure if Lee's end is going to take over the client tidy issue, or I should still try to take a stab at it. Definitely need to basal. So I think he has a PR that actually fixes it. Did you see his fixed PR? No, I missed that one. I guess I'll go take a look. Yeah, let me find it. I can drop it in the chat once. Yeah, one thing that would be helpful with his fixed PR, I'm guessing for the last few months we've had quite a bit of regressions. So if you're able to actually run it locally and you want to fix some of the master regressions, that would be really useful. Hold on, let me find it. Yep, I can definitely do that. Yeah, it was really unfortunate when that broke. This is our first 5 PM slot time, so I'm not sure who's going to show up for this one, although looks like we have quite a few. Pretty light ease, of course. But I wouldn't take too many folks from here. Oh, hey, Melissa. Hey there. Yeah, for some reason, Zoom wasn't working. I restarted enough things to get it going. Looks like we got one thing on the agenda. Was that you, Harvey, with the external dependencies? Is that my rant? Yeah. OK, all right. Yes, please ask the agenda if anyone has anything else. I don't know if there's anything else. I did get this really cool spreadsheet for Michael Payne, which has all the dependencies. Yes, I actually edited that a little bit. And yeah, it looks good. I think it's a really nice contribution. I think the idea is what I spoke with Michael about is that we would annotate repositorylocations.bzl with where the dependencies are being used and that will be sort of essentially just metadata, which will be used by folks who are doing these updates in the future. And that will obviously appear in the diff in GitHub to let us sort of get a better picture of how important this dependency update is. And if we can ideally group these bumps so that we can just deal with, oh yeah, all those build time ones and test ones, just get them out of the way. We can focus on those dependencies which are actually really interesting for Envoy's behavioral and security properties. Yeah. Did he make this by hand or is this done with a script? Yeah, I think he built it by hand. It's really cool though. Is it, I mean, I'm assuming we could probably make this with a script, right? Because that would be up to you. Well, once we have those annotations, yeah, we'll be able to build that with a script. Could we go even further and actually for extensions, could we break apart that repositories.bzl file and actually have the extensions define the repositories that they need? Because that would be even more explicit in terms of being able to look through and say that an extension uses a thing, right? Because I'm looking at a bunch of these and a lot of these I know for sure are only used by a particular extension. Yeah, we see HTTP JSON transcode, I'm using extension of the thrift stuff. So yeah, yeah, yeah. So I feel that would actually be a really huge improvement to the build process if we could use the, in particular, we could condition the build. So we're not even pulling down these repositories if you haven't actually been doing your build, these extensions. I think that probably works already, right? Like, doesn't Bazel, wouldn't Bazel already do that? Yeah, it's probably already doing that, yeah, yeah. Yeah, you're right. But it just seems like it would be a little more explicit because then we wouldn't have to keep the mapping up to date in that single file with what extensions actually use them, but I'm not sure what's possible. Yeah, the thing is if we scatter this file across the tree, I mean, anything's, it doesn't really matter, like with tooling, we could always do this, but it'll be nice. It's nice having a single pane. I would like to keep maintaining some sort of single pane of repositories and be able to easily query that. Yeah, I think that's fine. I mean, I think if there's just some way that whether it's through Bazel or some other script, like I feel like through Bazel, we should be able to know all of the code that uses a particular target, right? Like, doesn't Bazel query do that? So, I mean, it seems like we should be able to run a query. Yeah, if Bazel query could do something like that. I mean, again, like, I think of a tool, which is a little more sophisticated, which actually includes this metadata and prints things out nicely and associates them with extension. Yeah, I think we would ultimately need something a bit more about Bazel query, the Bazel query's a building block for whatever you would build. Oh, sure, yeah. I guess I was just saying that I think whatever we should do, we should try to make it part of CI. So that, for example, like if a new piece of code uses like an external dependency that we didn't know that it uses, like we should make sure that the annotations are actually up to date. Like, if it's done by hand, that seems very fragile. I agree. I mean, right now, the thing I'd say by hand is saying clearly that this is data playing a build or test. And I don't think we can possibly infer some of that through Bazel magic, but that's probably not too fragile. Like, you know, Bazelisk is never gonna appear as part of the data playing, for example. And yeah, wrapper JSON may come into the data playing some of the time, maybe control playing the others, but there's relatively few external dependencies which straddle that line. And I think those ones we can maintain by hand. So like that aspect of tagging, I think that metadata can be done by hand, but association with extensions certainly is best done through tooling. Yeah, this list is actually not quite as bad as I had thought. Like, I mean, I had thought that it would be worse. I'm just like, I'm just browsing through. Is this especially public? Is it okay to share it? I'm not sure. You have to check with Michael. I mean, there's nothing secret in here. But you know, just courtesy to check with someone, perhaps. Well, I just put it in. I'm not sure. I mean, there's nothing in here that's secret. But I don't know if it's open or not. So. Yeah, so, yeah. So anyway, I think we can add another thing that I'd like to see sort of added or something. It's an acronym I just learned about today, but maybe our good friends, it's a red hat like Kevin, or he's on the local window about this. It's a CPE. So apparently, like all software has like its own unique identified just like CVEs, you can identify exploits or vulnerabilities. CPEs uniquely identify products. So if we could include the CPEs for external dependencies there, that would be a huge solids favor for at least us at Google. And I'm sure other folks would love to have that information as tagged along because it allows you to then map back from like the stable version and that CPE to known vulnerabilities and that kind of thing. Sorry. What is a CPE? It's like a unique ID identifier for a piece of software. So like Envoy would have a CPE. At a particular version or? Yeah, the full CPE string includes version, but you can, I think that like there are variants where you can like, you know, some cases and still reason about that CPE. But like if we, so is this the reason that we eventually want to only use versions? So like we would say that all of our dependencies should have a CPE assigned or is the SHA and GitHub good enough for a CPE because that's a firm version in time. I mean, I'm not an expert yet on the CPE rules. I just learned about this acronym today. So what I think though is the ultimate goal is to get to the point where we can just start reasoning about the security history and status of all of our dependencies and that will be a desirable property. Again, not so important for stuff like Bazalisk, but pretty important for things like nghtb2 or cell or any of these dependencies that we have which play a role in the data plane. And right now we're in this situation, which is my agenda item where we have a whole bunch of dependencies which are just like, yeah, this is something like random repository maintained by a couple of people and there's no release process and we just had some SHA there. And that doesn't really facilitate this kind of like reasoning in particular as we scale the number of dependencies. Ideally this can be done in a tool-based way or through standard notification mechanisms like GitHub release watches on GitHub release is this kind of thing. So this is kind of where I would like us to get towards. And I think the way we can get this maturity is first of all by being pretty skeptical about new external repositories which don't match this. Like if you're coming along with a, you know, your own external repository library to help you out with your filter and that filter, well, you should really go and make sure that there's some sort of release maturity that's being practiced. And I mean, we could take this even further and ask for, you know, well, you should have like a security policy and all these kinds of things. But the very least like table stakes is being able to cut releases and have a version history and be able to reason about what happened between two releases. Like to me, I can't think of anything more basic than that. And it's true if you just wanna work on a rolling master's release candidate, you could do something like that with the right version history and so on. But I don't think many projects really practice that either. Yeah, this is kind of like where I would propose we go, at least for those dependencies which are actually important to data plane behavior. Yeah, I mean, this sounds fantastic. I think that anything we do here would improve the security posture. My only concern is what I put into the GitHub issue, which is just that I wanna make sure that if we specify these rules or what we expect from other projects, they actually make sense and they're not just arbitrary because it's like we can go to some of these people and be like, we want you to cut releases and then they just go into GitHub and press the button and then they tell us that they cut a release and it's like, it doesn't change anything. Again, if all they did was cut releases and maintained a version history between them, that to me is already very useful in being able to start to reason about history and being able to, and assuming they're just put through var in the version history, I mean, we want them to actually have a actively maintained version history which represents security. Right, so I am 100% for this. I just wanna make sure that if we do this, we apply this across all projects and by that, I mean that we have a bunch of Google projects here and Google's used to working for master and again, I mean, I think this is great but if we're gonna apply this, we can't say that Google projects don't have to do this because they're used to going for master or something like that. No, I think a lot of the good, it's only the much smaller Google projects which are in that category, things like, I don't know, the job authentication or the, basically places where we've told people to go kind of separate repository because we don't wanna put in the main envoy one and that's basically where they are and I think it'll be nice if we could get something a bit more solid going on there. Agreed. And then there are some major ones which I think quite a lot's taken action to do a better job on with cell and others like that and cell is kind of like, yeah, it exists internally at Google and then we just decided to open sources and I don't think there's been much in the way of process or that kind of thing added to that yet. Yeah, and again, that sounds great. Like I know that for some of these dependencies without naming names, I know that some of them have been put into other repos to avoid our extensive code reviews. So, which kind of defeats the purpose of what we're trying to achieve. So, you know, like we should just make sure that we write down what our expectations actually are. I mean, one of the nice things is if we could do what you said at the beginning and start to associate and directly the extensions with the repositories is those repositories which don't have release maturity and we can tag that against a bit of metadata there. We can then automatically enforce that, hey, you don't get a claimer secure, you know, one of these super secure postures because it turns out, you know, you're not practicing, you're not doing this. And there is prior art here, like there are best practices, badges for projects and things like that. And this is actually, I put it in the issue but it's something that has come up in the CNCF context quite a bit because every project pretty much has this problem and it's even worse in other ecosystems. Like C++ isn't, I actually think quite as bad just in the sense that there's fewer dependencies, more software tends to be written either from standard library. If you look at something like Go, it's basically like no JS. I mean, it's like these projects pull in literally like hundreds of nested dependencies. So keeping track of that is very complicated but there is interest in trying to do better here. So in so far as some of the security folks in the CNCF context could help here either with guidelines in terms of what we wanna see from projects. Like I feel like this is stuff that doesn't apply to just us. I mean, it applies to other projects also. Yeah, I mean, do you have like dedicated folks in CNCF who are working on this? Or is it just like, I just applied to chat about security. No, so there is something called SIG security in CNCF. There are people that focus on both the security projects and just general security posture for the CNCF ecosystem. I doubt about this issue and I was told to basically open an issue against SIG security. And one of the things that we might consider doing is you or I or both of us, we can go presentially present or talk about it at a SIG security meeting just to explain some of the problems that were happening and maybe see, I mean, again, I don't know that we're gonna get anything useful out of that but given the fact that a lot of what we're talking about is not really on voice specific, it's just dependency maturity and like dependency tracking and things like that. It seems to me that there's a lot of common stuff here. Cool, cool. Yeah, so let me, it's on my to-do. I will open that issue and I'll make sure that you're tagged and then maybe we can get a meeting slot and we can at least go talk to them. Sounds good to me. Cool. Yeah, but in terms of near term stuff, I mean, I love the idea of getting this spreadsheet like built into some tool that's actually checked in CI and like we can make sure that the annotations are correct on the extensions. And at least then it would allow us to understand like what do we depend on? What is it used by? You can imagine that now that we have all these annotations around, is an extension like alpha? What is the extension security posture? Like maybe we have different rules around what we require from DApps. It's like if they're in the core extension or they're trusted for untrusted data, like maybe they have to have a different posture. I'm not sure. Yeah, I think that'd be great. So yeah, hopefully, I think Michael's next planning is to take that spreadsheet and at least add some to turn into metadata and we'll see from there what we can do. Sweet, that sounds great. I think that's all I had to say on that topic. So yeah. Cool. I don't think I had anything else did anyone have anything that they wanted to chat about? Anyone? All right. Have a good evening. Bye.