 All right, welcome everybody to the August 17th technical oversight committee call. As everybody on this call is aware to things that we have to abide by the first is the address policy. The second is our code of conduct, which is linked in the agenda. All right for announcements today we have the standard definitely developer newsletter that goes out each Friday. If you would like to include anything in that newsletter, please do leave a comment on the upcoming newsletter's wiki page. That is linked off of the agenda. The second one says meeting management. I'm not sure who added this. That would be me. Okay. So I want to show people on the TOC that are generally in a lot of community meetings. We now have Zapier set up. Plug into zoom. And so, for instance, these two meetings is areas VCX call and this a pack call for cacti maintainers. These are automatically uploaded. There's I'm working on making every single piece of it completely automatic, but it's much better than it used to be. The names come from the meetings. And I see I have a meeting I need to edit. So these are for the defined meetings. Some of you have calls that are not on defined meetings. And we need to fix that. So I will be talking to each of you in turn about getting your meetings on defined calls that are automatically recorded to the cloud so they get to YouTube automatically. I appreciate your forbearance and working with me and getting this done. One reason that we're doing this is it costs money to have videos on the wiki and it's a terrible hosting platform. The other reason is we get transcripts that are when we do a cloud recording very nice. So I know that there are some meetings where people will stop the cloud recording because for they have reasons. Please don't. The second thing that I wanted to show you is we have the hyperledger.dev website. Which was basically unused. This is going to become a web page about how to get involved. This is a repo. If there are any edits you want to make. I ask you to send in a pull request they are greedily accepted. And if there are no questions on meeting management then I will hand the baton off. You say don't stop the recording. Would it be possible or is it an option to have some meetings set to not auto record and so that it's up to the organizer to turn on recording and record to the cloud I just find it painful to have the. All of the preliminary stuff recorded so that you have to find where the meeting actually starts. So I do have thoughts on that. One thing and I'm not sure let's just grab a random meeting here. I'm looking for the. So it doesn't. Or it does. So it doesn't. Automatically record meeting you can turn that off. I can but I'd rather not. Doesn't look like the host codes are published. Let me get back to you on that. Okay, because if you have the host code. You can, you know, stop the cloud recording, which we do here for the TOC call. Yeah, and then start it when it starts and if you. Oh, I thought you said not to do that. Oh, is that okay to do. Not stop the pause, right? No, no. I'm looking for one here. So this is a non credit spec working group. Yeah. I think those are just people that showed up randomly. If you stop the recording and start it. When you go into. I don't have any. I'm looking for one that has a bunch of. Files. I don't see one. They will show up as two separate recordings. So it's really easy to delete the very short recording. Like this one, which is 220 kilobytes. That's easy to delete. If you pause it. Then you end up with. One recording. And it just makes a problem worse. So it's better to stop the cloud recording and then start it. Okay. I'll keep that in mind. That's, that's what I was looking for. Okay. And so just to be clear, the. The short recording will still be added to the page. We would go in and edit it if we wanted to after. So what happens and what happened this morning. As I woke up and there were, I don't know. Five or 10 short recordings here. They're private when they're published. I'm sorry, they're private when they're uploaded. So I just went through here and selected a bunch of junk meetings, deleted the recordings, and then I. Handle the rest, putting on the playlist and stuff is not automatic yet, but I'm working on that. So there will be no intervention on your part required. That's awesome. Right. You're amazing. That's perfect. So my practice will tend to be. The auto is on. I'll stop. I'll claim host. Stop the recording. Start it when the meeting start starts and all will be good. Yes, that's perfect. Okay. And when you started, record to the cloud. Yes. Oh, yes. Always record to the cloud. Yep. Perfect. Thank you. Any other questions. On the process. Nope. Any other announcements. Sorry. One more comment. Sorry. I couldn't find you. Thank you. One thing I would suggest I did a document a while ago about. Hosting. Hyper ledger meetings. We probably should have a document like that. I have one. Somewhere in my indie staff because I was turning the. The process over to somebody else. And so I just wrote all of my notes about how to do that. So things like what we just talked about there should be included in that. So. Okay. For the. The CA team. In our meeting today, we're going to cover. Exactly how we want to communicate this. I just want to. Get in touch with TLC members first. Awesome. Yeah, my question. I have two questions. So the first one is if like, I know that. Documentation task force. Sometimes we have. Random meetings during the week and I just use my zoom room. I use my zoom room. Should I be setting this up through the public calendar? Even though it's like just a. Between me and my mentor or like, should we be primarily using the zoom room through the Linux foundation or should. You know, for ad junk meetings, use our own. Are these meetings. You said you and your mentor. I mean, are these meetings that you want to end up on YouTube? Not necessarily. I mean, I don't know. I don't know. I don't know about it. If they are, then let's talk about it. Okay. Fair enough. And then the other thing was just offering the services of the documentation user group. We're using a lot of AI tools to create user guides that are. Cohesive through the community. So if you want to use your guide for your information, just send me an outline. We'll do. Thank you. Any other. Can you share some examples of what you've produced? Yeah. We'll show you. We'll show you. We'll show you when we do our presentation at the end of the. Sounds awesome. Thanks. That's the teaser. You got me. All right. Any other announcements. Okay. So for quarterly reports, we do have the areas report that is out there. I did see a few. Approvals coming in. We probably have enough approvals. Though I did see one minor comment or clarification that needed to be done before we can merge that particular report. So. So. The bevel report did come in sometime while I was asleep. So I did see a number of people who've already reviewed that, but that one was due today. So. If you haven't had a chance to take a look. Please do so. Then we've got the so laying report. Let's do next week. The transact report is also due next week, but I know they're in dormant state. So I'm just reaching out to transact and finding out. Do they want to remain in dormant state, or are they ready to move to an end of life state or what the status of that project is and whether or not we should expect to see a report from them. That would be great. All right. Any questions on the reports. Okay. So for discussion today, I did have. A couple of comments. I think we need to talk about that particular comment before we can think about a vote. Stephen, did you want to talk about your comment? So. Before you do, I actually replied. Yeah. There's. There's two comments. I definitely think the, how this is done automatic. Automagically it should be included in there. Cause I didn't get that from that. And. Envisioned all this extra pipeline stuff that might be needed. So. Would love to get. A brief summary put into that of how that works. Or, or just to say this is automatically done by GitHub. The bigger comment. It was one I've stated before on other things. And. I'm happy to ignore it. But I really find it difficult when we combine. Both the policy and the template. Into a single document. And so I think it would be much better to either have a separate document that is the template. Or at least a. Delineating point in the single document that says from here. On out, you know. Use from, from below this forward to see the. To use as the template for a given project or repository. Yeah. I just find that document. Is way too. Complex and difficult to maintain for a project. Because it has so many things to do with hyper ledger policy. And not to do with project policy. Right. Steven Hart. Hey. Yeah. So one of the reasons why we did this. In fact, maybe the primary reason is so that people. Could go to a single document. For a particular project and find out about all of the. Security policies. You know, we have lots of people that come in. To, you know, report bugs to hyper ledger that are really not familiar with the whole ecosystem. And, you know. Say if you're reporting a bug to base you and you're coming from the Ethereum. Ecosystem, right? You're not going to want to click through all of the different hyper ledger stuff. You know, you just want to know, what do I need to know for reporting a bug to base you. So that's why we, you know, put this all in the same document. I'm not exactly sure what you, why you think this is going to be a big burden on maintainers. Can, can you explain that to me? Yeah. Because I think. Because I think the security policy has a lot of, flexibility in it that it's going to be different per project. And I think over time that the security policy will evolve at hyper ledger. And what developers will do is they'll just have a security document that was created at such a time and never changed. And, and that's what I think is the danger of it. That's what I see in the maintainers documents today is that. You know, at some point, somebody created a maintainers document. It was the picture of what was there. Back in that day. And never gets involved. And, and it's important that these change. Over time. So that's, that's the maintenance. Thing that I have. And then the second is just when I practically go in, and it was more of the maintainers, but when I practically went in, and said, Oh, I'm going to create this for acopi. It was really painful to. To sort of, what do I leave in. Because it's relevant. And what do I remove because it's just verbiage that doesn't matter. And it's not relevant to. To acopi. So that's the challenge I think. Again, I, this is not, I'm not going to. Not a, not a hill to die on. So I'm fine if we want to keep going. It's just, I find as a maintainer. This approach is kind of painful. All right. Yeah, I do tend to agree with Steven. I think it can be resolved fairly easily up by just putting the template information up top. And then down below have more of a content. And then, if you're using the template, you can just ignore the stuff below or for reference, it's down below, but the policy is at the top. So I'm not entirely clear how you all think we can sort of separate the template from the policy. You know, particularly in a way that. You know, I'm not entirely clear how you all think we can sort of separate the template from the policy. You know, particularly in a way that. People coming from the outside or people who aren't as familiar with security can sort of read and understand. You know, is, is one of you willing to take a crack at this? I'll take a shot at it. And what I'll do is take that document. And produce and occupy. Security. What I think should be in that. And then that to me. Would be a sample of a template. And so I can take that. Is that reasonable? And then, and then we can see if we agree on that as a template. And again, you know, if it doesn't work, that's fine. I'll have wasted a bit of time, but. That way you see what I'm thinking of. I mean, I'd love to see what you're thinking and we can also take it to the open SSF if you want as well. No, I definitely want to do that. I don't. I mean, I think that's the proper thing to do. I mean, that's what we did with this, but we have, right? We got it reviewed by the open SSF. Yeah. I mean, I would have expected the open SFF to take. I mean, I think it's worth it. I'm fine. As I say, I'm not going to. I just find it. A little painful, but. You know, I'm just curious. I don't understand. Like it. We tried to put it together and it's, it's a non painful of a way as possible. So I just, I'm just trying to figure out the pain points. You know, I guess. The, the big part of it is, you know, the pain points. You know, I guess the big thing you mentioned was, was big updates, but you know, I don't know that we are going to really see big updates. And most of the updates are going to come from the projects themselves. You know, right? When they change something, when they, you know, they change a reporting method or something like that. Okay. I guess. Yeah, let's just go forward then. I mean, I, look, if you think there are pain points, you know, like. No, I mean, that is the pain point is that if we think the whole document should go in every repository. Tweet. Where the highlights are. I disagree, but I'm not going to. I'm happy to do it. I'm happy to do it. I'm happy to do it. I'm happy to do it. I think the best work for me, all I do is copy and paste the document and. Make a few weeks to it. I just think it's hard to. Hardly hard to maintain. And. Yeah. But, but. You're explicitly saying that you think because of the way. People come into the project is actually better to do it this way. So I'll go with that. Crazy. I wanted to share the screen, but that's okay. I'll first probably just talk about one aspect. I think Steven, I see what you were trying to suggest. It's more from a developer or maintainer standpoint. Previously, we were having discussions about having a link from repositories to them. One of the main repository point a document. Point the current document to other documents, right? That's one. Available option. I don't know what the to see here. Thanks. For the security MD across all the repositories, if we can point them to one place per project, and then we maintain that infrastructure for the project over there. And in terms of what can change from a template versus. The policy standpoint. I feel it's okay to have, again, it's my opinion. It's feel okay to have the verbose information saying, this is what it means. And this is what the policy suggests. And we follow this particular. Mechanism and delete the things that we probably don't want to keep in our project. And mostly most likely the places like this is going to change everything else will have the same verbosity. In case of changing a major changes to this policy document, which most likely we will not see in near future. Again, the change effort would then be limited to one repository versus multiple repositories. Thank you. All right. So I have a couple of comments based on the discussion so far. My first is that if maintainers think that this is confusing or difficult to complete, then we probably haven't done a good job of documenting this, right. And we should take into consideration things that are going to make it easier for people to do this rather than harder for people to do this. And then I guess my second comment is more of a question to people who might be reporting security bugs. If they are reporting security bugs to multiple projects and they come in and they're looking at a document that looks exactly the same at the beginning for project X versus project Y, will they not assume that because they've understood project X's security policy that they understand project Y's security policy without actually reading project Y's security policy. So those are my two kind of comments slash questions concerns with where we're at right now. Based on the conversation that we've had. Tracy, your last point is kind of what I was thinking when I mentioned I agreed with Stephen. So I think for people coming in and trying to figure out how to report a security bug, it should be pretty short and sweet and they shouldn't have to read all this verbose text to be able to figure out how to do that. That's why I was saying it would be good to have just some very clear guidance at the beginning saying if you need to report a security vulnerability, use this email or use GitHub security advisories rather than having that kind of buried in the middle of the document. And then for a lengthier discussion, reference this document or reference the bottom for more details about our overall process and how we do things internally. All right. Thanks, Dave. So I will say that the open SSF actually encouraged us to be more verbose and sort of explain everything for the reporters and how, you know, how things worked. So, you know, I know that, you know, like people like Dave are obviously super familiar with all of these processes and security stuff, but I gather not everyone is. And when we did go over this with the open SSF, we were encouraged to be verbose. I think verbose version does make a lot of sense. I just think a summary would make a lot of sense at the top saying if you just want to report a security vulnerability, here's where you go to do that. And then down below is, or a different document has more verbose version. Okay, yeah, I know I think a summary makes sense if we say, Hey, if you know what you're doing, you know, just do this. Otherwise, here's the full details. Sure. That makes sense to me. All right. Thank you, Stephen. One thing I definitely think we should provide in this. And really, I think this is important is that projects have many repositories. And so there definitely should be a thing that says this project in every repository. There should be the option of having a pointer to the one true security document for the project. In other words, we don't want to repeat the same text in every repository, because that that does become a maintenance challenge when you even even just to change the name of a member of the security team. You've got to update all of the versions of the document. So there definitely should be an option to say in a given repository point to the security file for the rest of the project. Yeah, we had absolutely intended it that way. I don't think that's in there. So it should be stated. I didn't see it in there when I read through it. Yeah, I think it's not explicitly in there, but we did say it was the policy was defined for the project, right? Not the repo. It can be more explicit about that though. I think that's the very top where it says copy this file and edit the highlighted. It should probably be right in there to say we're given repository you may point to security document for the overall project. Sure. Yeah. All right. I just wanted to take opinion of adding this line at the top under the about this document section where we say after the first paragraph, which we see over here, the next paragraph would be if you're familiar with the security policies of this project and you're interested in reporting the bug. Please jump to this section. And that would be the summary. That we were discussing is about to ask if that's sufficient. That would be in the, maybe I can share the screen. Something like this. Would it make sense if you're familiar with the, that would appear in the markdown like this. And then we can add the instructions for maintainers at the top saying that we don't necessarily have the copy this file in all the repositories. We can also have a link to one central report, link to one document, which your project considers as the, I don't know, should we call it a main repository or primary repository. My position would be if you are as a project. Using the boilerplate. Security. Recommendations here. I think it would be okay to just link to the governance repo where this will, or the talk repo, wherever this lives. I think that would be okay. Say we use the hyperledger security policy and here's link. That's not a very strongly held opinion. Hart. I don't think that works because we have a lot of personal stuff that needs to be listed on here, like who's on the security team. You know, so, so I don't think, you know, the idea was that we didn't have to have like a central repo for like every single person on the security team. Right. And we had, let the project, I don't think that works because we have a lot of personal on the security team. Right. And we had let the projects pick that. So there's enough information in here that's catalogs that, you know, we would have to take a totally different strategy if we wanted to allow that. Okay. So something like all of the Aries repos. Could they do that and point to the Aries policy, which is in one repo? Yes. Okay. And it's good. Okay. Any other thoughts? Yes. Yes. I apologize for background noise. But I have to say, I'm leaning towards the students opinion. I think there may be a way to kind of split. Like the general stuff that's applicable across the board with across the hyper ledger. And, and then, you know, we have a smaller version which has more of the specific stuff with the pointer to the general stuff. And it's kind of a middle ground where we, we still have distributed information for each piece that's specific to the project. So it stays close to the project. But for the main tracks of the policy, which is applicable across the board. This can be central. All right. Thanks. I did have another comment above the one that we're just been talking about that has still not been addressed. It's the discussion about whether to use the security email versus use GitHub security reporting. First of all, I think it needs to be more clear in the document that there are two options. And then secondly, the instructions as they are here lean heavily towards the email approach. And then, you know, I think it's just for the fabric project itself. I prefer the GitHub approach. And so I think we should. Maybe we need a broader discussion about. Do we want to raise the status of the GitHub reporting a little bit more than it is here? Or just maybe we make just make it more obvious for projects to make that decision. But for, at least for fabric, the reason I like to use the secure reporting is because it's a process from start to finish from reporting through disclosure. That's all in one place. And then secondly, it doesn't seem to make a lot of sense if we have like, say a dozen projects and three people on each project. They're on the security team. There's 36 people. And if somebody's reporting an issue to fabric, why do we need to send that out to 36 people? 33 of who probably don't care much about that issue. So that's kind of my bigger reason of why I wanted to push a little bit higher or push the GitHub reporting process a little bit more rather than the email. But at the end of the day, I agree. It's up to the each project to make that decision. All right. Yeah. So the email has mostly been there for historic reasons. That was, you know, sort of a required reporting channel in the past. You know, if, if people don't like that, you know, we can change it, you know, that's just been the understanding in the past. So yeah, Dave, I mean, you're obviously welcome to, you know, for fabric explicitly say that the GitHub is the preferred policy. All right. Thanks, Hart, Peter. For me, the email list gives me a little more sense of security in the sense that if somehow everyone from cacti who should be seeing the vulnerabilities come in, misses them, then maybe the email list is a good last resort fall back in the sense that if there's some critical vulnerability that we're not seeing maybe someone else on the mailing list will see it and let us know. That's Peter Hart. Yeah, I will say, you know, this has not applied to a project like fabric that is very on top of typically of responding to security bugs. But one of the advantages of the security list is it has enabled staff to see who's behind on security bug issues. All right. Thanks, Hart. I will point out one of the more complex projects that we have for this is Bezu. Bezu has their own security mailing list. And one of the reasons that they agitated for that was that they are I'm sorry advocated for that was that they wanted everyone on the list to see the inbound emails. Even though they use the private GitHub, you know, reporting methodology, we could, you know, have a, you know, a per project security email setup. I would really rather not do that because it becomes even more complex. But that, you know, that is one thing that the Bezu project wanted was they wanted a per project visibility onto these emails and who is and isn't paying attention. So. Any other comments that we missed in this that we need to make sure we cover here. So just to close the loop on that one, I want to update the document with what I was talking about saying it's up to the project. And there's these two options that a lot of projects use, but of course projects can use yet a different approach to. All right. Thanks. That'd be great. Just your pull request there. And Steven, I think people were in agreement with your request to your original thought of somehow separating. So if you wanted to also do the example that you suggested with I could probably, I think that would be good. To close on this particular issue. I thought I had avoided that. I conceded to heart. I avoided work. Yeah, but then everybody else was like, no, Steven, you can't avoid work. Because we all agree with you, Steven. Fine. All right. Any other, any other comments on the security policy, then we won't do with the vote stable wait until we're. In a different spot. I guess. All right. If there's no further comments there. The next task force that we thought we'd start up. With the security artifacts timing task force. So this task force was. We considered some, some low hanging fruit to help improve the security using. Six store for artifacts signing. And so obviously developing some best practices and tooling. For hyper ledger to go ahead and use six store for the artifact signing. Is really what this task force is all about. Or what it was intended to be when we initially put it here in the issue. We didn't have a leader step up yet for this, but we did have some people who suggested that they would be interested in participating in this. So I think the question that I have for today is two fold. First, do we have a volunteer to lead this particular task force. And then secondly, to just double check on the list of deliverables and the task force. So I think we should make sure that that's exactly what we want to do. Yeah. I mean, I can get started on this. And actually wanted to talk a few more points to for us, all of us to get started on this particular task force. Okay, great. So, you'll be the leader and maybe I'll let you take over the conversation then. Thanks, Tracy. Thank you. Thank you. So I think the question is, is that your job as a volunteer, it is completely involved in much more deeper level with the open SSF community. And art is definitely aware of this. Options available through when SSF. And we can all agree. That. When we do a release. It has to be. For the security policy document that we all read, it also suggests in a way that. from coding standpoint, but also it's the complete holistic view adopts every aspect of it, including the infrastructure which we use for releasing artifacts. Now there are multiple questions that come to us when we talk about releasing artifacts and we'll have to address that somewhere in the policy document and haven't seen a specific document as such for releases yet and the only place where I came across about the releases is that each project is free to choose their own release process. The release taxonomy however is suggested through the policy. Now continuing that, there is some policy that we'll have to note over there on process to be followed for releases, at least from a security standpoint that's one open item that we can now get started on and then specifically talking about signing any artifacts that originates as part of the release. OpenSSF has this tool which has been made available in GA. That's called SIGSTORE. It has multiple components for us and at least the tool that is of importance is the one that we can all leverage for signing the artifact. The advantage and what differentiates this from the rest of the tools available over there is in terms of key management. I think that's I would call a best approach in terms of not having to maintain or store the key for a longer duration of time. In fact it generates on demand and we sign the release and then the key is ephemeral. It's not needed to be there for a long time. I know OpenSSF also has an infrastructure for us to leverage where all the sign logs are maintained in an open log transparent immutable open log as they call it which the users of software can verify. Now that's from a signing standpoint that we can all say here is a tool that we should all leverage in terms of releasing software. From a policy standpoint I know it sounds easy but from a maintainer standpoint that may require them to work on the deployment pipelines that already is there and now the bigger question however is also in terms of usage of those artifacts that are produced. Now the six store definitely does have a support which at least on the Kubernetes deployment side if we are doing a container releases then they do have an option which can be added as an admission controller check plugin which allows Kubernetes to natively do verify if it is pulling in images that are produced from Hyperledger Foundation has been signed and is following the process that is expected. Now we'll have to further explore that option I was trying to look into what happens for the SDK releases that we do from the projects right and then when we talk about developer focus things the majority of the time the developers they they will make use of SDKs that are released and artifacts are generally pulled in through some of the tools like Maven or Gradle for Java and then similarly for other projects right from Go language it could be through the like I forgot what it is for Go but for us I think there is like the crates that are pulled in they can get pulled in through the rust I mean through the rust I keep forgetting things my bad sorry yeah so so I think you yeah cargo my bad so I think you get an idea that I try to search for those options from six stores if we do say like we should start following six stores it is good from a it is good first step from a maintenance time bomb but from a usage perspective there are still open questions that will have to write down or at least say like these are the opens and if you are using these artifacts and if you would like to verify then do follow these processes or do follow up with open SSF right so yeah I just wanted to bring these topics up before we go deep I'm discussing all these questions further and one more thing we'll have to look into is in terms of adding s bombs and specifically when we talk about releases the artifact releases I'm not sure if we have done that or defined the process for doing that so far that's it I'll probably take a pause and open up for discussion Peter I only have a deep dive comment so sorry if I'm derailing the conversation we can table this for the next meeting too but the first thing the first idea I had is to look at six store and then find out how could I quickly integrate that to cacti releases today and I found quickly that there's a github action for it so then my question is can we have this installed and or is it already installed in the hyperlateral github org and if yes can I could just give it a spin as in now do we need any anything else for it or can I just try and install it and then see how it works it's not I mean this is a per repo thing so you should feel free to install that github action if it needs further permissions then please just reach out directly okay you know I'm looking at the I'm looking at it it doesn't seem that it needs any additional like super permissions or anything but I assume you're talking about cosign installer that's all yeah just go ahead and give it a whirl and let's see how it goes thank you all right I have one more question just because I see no one else has raised their hand unrelated but important question is if anyone knows if they have a list of supported artifacts to sign because it looks like it's somehow generic and just works with everything because at the end of the day we are just signing files that are just big blobs of data but is there some sort of additional convenience feature that makes it easier to work with NPM dependencies for example or is it really just this low level piece of infrastructure where it the only assumption makes is that the input is a giant file with release artifacts all right right um I don't know an open source reference I'm sorry about that but I don't know the process that one of the organizations that I worked with in the past followed and releasing these softwares and that was um purely there were no like set tools as such however the software installer package did have an option to go and verify those signatures right so it was built in as part of the installer packages then the signing process was the usual thing like there was no set tool to do it we could always we could as well just leverage um any tool that that we are familiar with including for instance OpenSSL if we were to choose one but those were like proprietary software sold as packages I don't have a reference for how this happens in open source and except the six store I don't know how six store works now okay yeah sorry I didn't mean to jump in on the deep end immediately I know we are just trying to figure out how to kick off this task force I was I just got curious if I mean trajectory I mean yes six store is designed so that you can pretty much sign any kind of blob of data it doesn't really matter I mean the whole idea is you know we used to have uh sign packages when you put the hash and the signature along the problem is you know it's very hard to find the keys and then the maintainers lose their keys and so on and so six store addresses this problem by providing a central point where you can find the information for you to verify the information that's all all right thanks Arnaud part you had to end up with there's something on there I was just gonna you know uh say to Peter that yeah it's great to explore this stuff you know go ahead and and give it a shot the deep dive is great so I just want to applaud Peter's enthusiasm yeah I think the the best way we can probably succeed in this particular task force is for people to try this out and see how Orgson you know from there we can develop those best practices and really document for others how to use the tools I will point out that I have a number of tests uh get a board where we can do stuff like this in a painless way so feel free to reach out and let's uh get this set up all right let's right here right you still have that high pleasure dash c i c d org probably that's what I was thinking of I just don't know if I've deleted or not okay if if I can if it still exists and I can still have access then I wouldn't mind playing around with the cacti clone over there yeah let's it looks like I deleted that org so uh let's follow up okay all right all right um just wanted to ask are we all aligned on using six store and adopting that in our release process looks like that's the direction we are trying to take I definitely supported it on a first glance because it appears to be well adopted based on the series of logos that I'm looking I'm seeing on their website and with a tool like this in my opinion one of the most important things is adoption and also uh how it's being maintained so even if even if we found another competing solution solving the same problem 10% better which is already subjective but let's assume that it is somehow 10% better but no one is using it then I would still say let's just use six store because it has community adoption any other thoughts at the moment all right I'm not seeing any hands I think next week task force discussion is the automated pipelines so Peter I think you're up for next week for the task force and hopefully we can come back and see about the changes and updates made to the security policy so for vulnerability disclosures so that we can close out on that particular item as well uh Rama yeah thanks Tracy I just want to let people know uh this meeting schedule for the badging and life cycle task force tomorrow same time as this fall so uh I know some of you expressed interest in joining but anybody who wants can join uh at least I'll expect that I guess you Tracy Arun, Peter and Bob will be on so and I'll leave some notes on the uh discord before the call sorry I didn't get time for you this week but I'll do so before the call all right thanks Rama for reminding us all of that call um so that we can join that one and make some forward progress there any other last items comments okay well then I will go ahead and close off this meeting safe travels to Arno uh and we will see you all again next week