 All right. Welcome everybody to the February 9th hyperledger technical oversight committee call as you are all aware. We've all been on this call before two things that we must abide by. The first is the antitrust policy that is currently being displayed on the screen. And the second is our code of conduct, which is linked in the agenda. So as far as announcements today we have the standard hyperledger definitely developer newsletter goes out each Friday. If you have anything that you would like to include in that newsletter. Please leave a comment on the newsletter wiki page that is linked in the agenda. The last announcement that we have may have seen this showing up on some of your socials but hyperledger is the winner of the 2023 devies award for the best innovation in blockchain cryptocurrency Web three. I understand that we have Bobby to thank for this for nominating hyperledger so congratulations to everybody on this award. And then the last announcement that is on the agenda here is the hyperledger mentorship program has been kicked off. So that we're currently looking for mentorship project proposals to be submitted. If you do have something that you would like to propose please do so by March 15. Any other announcements that anybody has or would like to make. I will take that as you know. So for quarterly reports I did see a number of people reviewing reports this morning on GitHub there's been a lot of back and forth. A lot of comments happening on these different reports that have come in. We still do have people who are outstanding as far as the reviews for both of these reports so we will continue to leave them in an open state. I did not specifically see anything that we need to discuss on the TOC call but is there anything that anybody has to bring up on the Indie or the noncredge report at this point. Okay. And then as far as the soft tooth report I think we have eight of the 11 people who've reviewed that one that came in a couple weeks ago, maybe last week. Please if you haven't had a chance to review that yet please do so. We'll again wait until everybody clicks on the approve, or has a chance to review that for us to merge that into the into the repo. So there has been on the Ursa report. I just wanted to mention that there has been activity in Ursa in the last couple of days, the last couple of weeks and so I've asked Brett Zundle who's been doing some of the updates to put in the report so I'm hoping that we'll get that soon so he has some guidance on how to do it and hopefully we'll provide it soon. All right, I appreciate the update on that Steven, I did see that as well the chat going on there in the Ursa channel so but I appreciate you bringing that up here. I think it's important, as we kick this project back up for us to start, you know, at least understanding what's going on there so appreciate that. Any other comments on the quarterly reports at this point. All right, as you probably noticed there was a fourth report there, Iroha did submit the report yesterday. It is not linked here but it will be linked for next week's agenda since it was due today. We'll make sure that gets out there so that if you haven't had a chance to take a look at that you'll at least remember to do that based on the agenda. And then we do have the bevel report that comes due next week. So we'll look forward to seeing that hopefully sometime next week. Yes or no. Yes, hi. I had a very practical question on the reports, managing the reports and GitHub. So, I mean one thing that I liked in the week is I could go to the task I had then I could see which one I had not reviewed yet. I mean, right, do you know any magic query that I can use to see which one I haven't reviewed yet. So the link that's in the agenda will actually pull up the ones that you haven't reviewed. So, if you've reviewed them already they won't show up in this list if you haven't reviewed them they will show up in this list. Thank you. I didn't realize that was the link in there so I would just go to pull requests and I'm like oh shoot which one I have. All days it's not obvious to remember. So the trick is to go back to link. Thank you. You won't find anything for that name because there is nobody with that name but yeah anyway, the that link I tried to mimic what I had in the other agenda where we had it on the wiki where you can see like your outstanding I tried to do that for the outstanding quarterly report so there's a few things that I'm doing or I noticed what I did on one of the reports is I'm adding the quarterly report label to them so that we know their quarterly reports. And also making sure that we add all 11 POC members unless of course they submitted the PR to the reviewer list so that each of you should get an individual email for each of them saying that you're been at it as a reviewer for them, assuming that you are subscribed to receive the emails from GitHub. So, hoping that will help people to recognize that they have outstanding tasks for themselves to do. That is great. Thank you. I'm also trying to figure out a way to make these to have embedded in the template, the label. So I know it's possible. I just haven't figured out how to get to work yet. I did add a code owner's file, which has everyone listed individually. My hope is that that the next PR comes in will be given to everyone individually to review. All right, we will keep you informed about right. See whether or not that happens. Thank you for trying to make it as easy as possible on us all. All right, any other comments are tactical or on the reports themselves. Yeah, Peter. Thank you, Tracy. Hi, everyone. Sorry, I was away for long. I had a lot of travel doing what I wanted to highlight is what I put in the chat, which is that there's this pull request merge key feature coming out from GitHub and I think everyone should check it out because it will drive efficiency of CI pipelines that all the projects have. Basically, what it does is that it orders the pull requests into a stack and then the CI and the tests and the build everything within the CI only checks can be executed against a revision of that pull request that it will have at the time of its merging, which can be known if there is a queue or stack structure queue. I guess not stacks are because that way you can always compute what other pull requests will be merged before your own. And then the source code revision can be figured out that will be the final revision that will be merged onto the project's main branch. And so instead of having to run the CI end times because of other pull requests getting merged before yours, the number of times you have to run the CI will be just the one as long as you have a place in the queue. I don't know how clearly I explained this, but the bottom line is that it's more efficient and I highly recommend using it when it becomes generally available. I will definitely use it in its current state in the public beta because I'm really curious about it and I'm very excited about it. That's it. Thank you. So for those that have been with us for a while, this is Garrett functionality where you would have a bunch of changes in a stack and then you would merge the parent one and then everything would happen. So, if you own or if you are an admin, the setting is in your repo settings branch protection. If you have any questions, please ask on discord and I would be happy to enable us for everyone. I also, I mentioned this in the maintainers channel. I turned on for the entire org the private security disclosure feature. So if you get any disclosures, and you're surprised by that, please get in contact. All right. Thank you, Peter. Thank you right for bringing our attention to some new features. Good news for for us as maintainers of project. Any other comments at this point. All right, so I think for discussion, we didn't have any specific topics for the doc to discuss today as a whole. So, as you have, as we discussed last week, the beginning of the round Robin for the different task forces. And so we've got first up the security vulnerability disclosure task force that we will be discussing today unless anybody else has a discussion item before we get to the task force discussion. Okay, then I think we are up to the task force discussion. So, Aaron, I know you have volunteered to be the leader for this particular task force. Do you want to, I don't know, walk us through kind of what the this task force is all about and what the plans are for how we approach this particular work item. All right. Thanks, Tracy. And hey, everyone. And so, before I begin right so some disclosures. So previously when we had security update task force was proposed early last year. The, the what we lacked over there is to scope it down into specific activities that are specific expectations that we wanted out of it. We started with some agenda and it eventually evolved into security being a wide domain. The discussion spread all over from having a threat modeling for a specific project and all the way. It's definitely started with vulnerability disclosure topic. And eventually it landed up to the topic where how do we do a threat modeling of a project and which parameter should be considered. And it also led into discussions into how do we tackle if a project is unable to deal with a high severe, I mean, high or severe issues that were reported. And what's the process that we should set up in terms of addressing these and do we need a formal way of announcing to every every graduated project that there is a process of type ledger and then this is that process. And follow these guidelines right. So, as you can understand the discussions went all over the place. Now, one of the topic that that we had to address or that we could have started with is of course on the vulnerability disclosure. So, to give a background of what this all of what this is all about. Right now today and all the projects we do have security MD file markdown file that we add into our repositories in terms of letting people know that if they have any concerns, which they would like to discuss in terms of security. We are telling them, hey, we are responsible cities and then come follow these process that we have either send an email to the security mailing list that goes to a bunch of people or report it in a way. And that in a in a responsible way that you still track it for completion or you still follow up with the maintainers of the project, but there was a way of communication. Is this sufficient or is this probably is not a sufficient model in terms of how we go about and any vulnerability disclosures right and that's where the discussion started and how we even start how do we even standardize the process across all the projects. And at the same time open SSF had the working group it started put putting down a collective information that they could get across all the different open source initiatives. And they created a bunch of checklist and a playbook for how a vulnerability disclosure can be addressed or how it can be treated by the maintainers of each project. So that's that's the brief background of what this topic is all about. And specifically in this task force that we have for now, we will scope it down to what it is meant to do in a sense. We will try to address how vulnerability disclosure would happen and what actions would a particular maintainer have and what actions but the project overall have. And what's the responsibility that we hold from within hyper ledger and what's the like all these questions that we try to address. And as a starting point, we do have a reference that is recommended from the open SSF. So there was a call and if you were part of the previous task force where we went over each of these items. And I remember like having discussions were hard proposed that some of the, let's say the containing things right some of the subjective terms, which are part of open SSF recommendation. We keep them away, but we try to see the rest of those recommendations from open SSF are good point to get started with. And probably as part of this task force will will try to start from there and will definitely start from there. And what we will do eventually is to like address as part of these discussions, whatever questions that come up right. And then we will selectively pick those subjective terms, but our goal should be to have a vulnerability disclosure approach for all hyper ledger projects. And one thing that we will intentionally try to keep away for now is I know like there were also discussions from the previous task force where we were debating on. Should we have additional questions that would gauge severity of a bug or an effect that was reported in terms of security relevance right. And if we were to gauge those, then should we introduce the questions that are like blockchain threat modeling specific. So we will try to keep those questions away in our task force, and that could be like an extended task force or the next task force from within the security scope that we can pick up. So without the limited scope and a set agenda or a set expectation from the task force, we could get started. Before I start sharing the screen and go through the open SSF recommendations that we had previously discussed. Do we have any questions on the scope, the topic or the background. Yeah, my question is, I saw in the chat that was set up for this task force hearts thought on creating a template that would be used by all the hyper ledger projects, and then only changed it for some reason that it felt necessary is that part of the scope of this as well. I'm sure. I think the template so hard correct me if I'm wrong here so I think by template you wanted to say that the the disclosures I mean, did you want to introduce the reporting template or did you mean like a template that we give, give out as a way to tell community that this is the way that you should report vulnerability stores. I believe it was the latter, and I'm pretty sure that it's in line with what you're saying. So maybe using template was just a poor word choice by me. So if I may interject I mean I think, you know, the idea is, we develop the policy because the thing that hard pointed out right is that in the documentation provided by open SSF, they go, it's pretty extensive in terms of what you expected to do. At the end of the day they don't put it all together into a document, they say hey, and by the way you must document all of you know this stuff on your website part of your repository. And so we have to do that hot said, I come they don't provide a template so we, you know, we could already start from that. And so I think hot is right. His idea was, basically, once we have developed our own policy, following the recommendations, we can then submit this to be basically a template for others to use and maybe open SF could leverage that and, you know, publish it. Did I get that right hot. Yeah, absolutely that was perfect. I mean, I do wish the open SSF had a better starting point. And I think if we if we do this work, then yeah I think we can contribute it back. They have expressed interest in this so Yeah, I mean, just just to comment, I like the framing of templates and I think we could think about templates and other cases I know we have the inactivity policy right that we put together that projects can somewhat override if they need to write based on what it is that they're doing. But if projects don't have this document it then this is this is the default and this is what you're going to end up using as the mechanism I think this falls in line with a lot of other things that we should probably think about for our projects. So, I'm perfectly happy with direction I just wanted to make sure that we we had that in mind as we were going through. Yeah, I mean to answer your question I do think this is in scope. Absolutely. Okay. So what I'll probably do, I don't know how to take notes at the same time on screen share so I'll probably take notes on a separate note that I had, and later I'll attach those notes to the meeting minutes. So, so to get started, right. So, one of the repository that I put in the chat on the top under the task force chart group is it has extensive information as are not pointed out right so it has everything from what should an open source maintainer do or a community do in terms of setting up a process as well as it has information on what should you do if you have discovered vulnerability and what's your responsibility to participate in open source collaboration from an individual or a individual's perspective and what kind of recommendations that we have for you in order to get better response from the maintainers right so they they're both topics over here. And what we will focus on to get started with is on the process that we have to set up and eventually all the discussions that lead lead from I mean that evolves from these conversations, we will convert them into a template that we were discussing back. So, the process that we are going to discuss right now is in terms of what open SSF recommends for our setting up a process being an open source community. So, the guide. The guide starts with all the information such as why should we need a process like this right and what's the information that the security researcher or a user of a project be expecting from us, and then how, how should we make it available for them like all of that information in the introductory section. So, how do we go about it like I remember in the previous task force meetings we went through different sections of paragraphs and then we debated on each of them. Should we follow the same approach on this call as well. I think it's up to you, right, I find that useful so that we, we could debate on the topic and then we could finalize on the things that we all agree upon. And then and then and then it also reminds us in future that we did have a discussion on some topics like that. So, initial section of this document at all talks about what's the what does the glossary and other things right so what I will get started with would be Right, I think some of these explanation are all towards what's an expectation from a reporter that they would recognize they would want a recognition or probably they would they are expecting a fix because they have it in their production and and all of that aspect. So, I would suggest that we also incorporate if possible, these kind of information somewhere in our documentation maybe as a central at the central place, saying that we care about security and the we could give this as advisory notice saying that this is your role as an reporter. Right, so somebody who walks in and then says that hey, I thought I found an issue. But how do I go about it what's my right and how do you want me to report it so probably we should list these kind of responsibilities and then give that importance to the security researcher. I know not all of that information can be found on this page some of this can also be captured from the other place, such as this one, which is all about guidance for the researchers on what that means for them to report disclosures right. So I recommend I mean I would propose to have this section documented in a central place. Yeah, I wouldn't interject here. I mean the idea behind this is that you know, they, they wanted to try to point out the motivations of the reporters and they are different kinds of them right. But there are people that's all they do they're like say, security researchers, they focus on one software today another one tomorrow, and they look for vulnerabilities to report. And, you know, but they, there is a big range they are just simple users will find stuff they stumble upon stuff. And so the whole point of this section really is about trying to establish her, you know, some kind of understanding of what you're dealing with so that, you know, basically trying to diffuse any possible tension and avoid conflict, trying to communicate with some communication with the reporter. And, you know, acknowledge what they are providing. Unfortunately, I think there are quite a few cases where that relationship is pretty bad in general, which is why there is this other I just pointed to that was then published later on, which was also to try to tell the reporters hey guys, maybe you should know a little bit more about how, you know what it's like to be on the other side, when you approach projects open source specifically, you know, with your reports, and it's all about trying to, you know, help with the communication establishing a positive communication between those different parties. Go ahead Tracy. Yeah I guess my question is how do we distinguish between what we're trying to do and what's already available. What I'm hearing is there's already documentation about information around the finders who they are, what their motivations are, there's information to the finders about why and how they should report open source security vulnerabilities. My question is like, I don't want to recreate what's already existing and open SSF I want to add to that and make it valuable for hyperledger and so I want to want to see if we can understand better where the lines are between what open SSF has and what we're trying to do in this task force. Yeah, so that's a great question Tracy. So what I view the open SSF is having done is sort of come up with a, you know, very broad commentary, you know, set of best practices set of suggestions, all about stuff on what you sort of sort of should do for a good vulnerability disclosure program. But, you know, my perspective is this is sort of, it's sort of people who already know what they're talking about writing stuff down. And it's not as useful if you're a new project or if you're a project that maybe isn't as familiar with security to try to you know actually figure out a consistent set of rules and policy, and what should be done. But what I'd like to see is something that's much more user friendly. So, hence a template. So something that people could just take and apply and say as a project we are going to do X these are the rules we're going to follow right. And, you know, have this, you know, there can be some customization and so forth. But basically, you know, have a set of rules that people who aren't as familiar with this sort of thing and who, you know, haven't done it before, can just follow, and essentially be, you know, in the good zone, if you will. And, and, you know, I would have thought that the open SSF would have done this but you know it doesn't appear that they have this. So that that's my thought and I hope that makes sense. I guess the question is, to me rules mean, here's some things that you should follow, right, versus here's some background information that you should know before you follow these rules. To me the background information before you follow these rules are already documented viewing open SSF versus the rules aren't documented well enough for us to be able to just go ahead and implement. So I want to make sure that that is the line that we're drawing of the background information is here. Go read that if you want background information. Here's the rules for the project to follow that's what this is focused on. That's exactly right. So here, the open SSF documentation how tells you what you should think about when you're generate when you're building a policy right. And that's sort of what you're referring to is the background, but it doesn't, you know, give you a policy it doesn't say do this, right. And we just sort of want to bare bones document that says do this and this and this. I completely agree with heart and I don't think we should duplicate this content. We should have a pointer for people to read as background. I think that's, I think, as a hot says what we want to do is really have a kind of a roadbook for how a project handles security disclosures. So this is, you know, in our project we're doing this, the securities are reported there. Once we receive the security, the clock start ticking. This is what we do next. And this is what we do next and so on. Yeah, I agree. So to summarize that the recommendation is that we still point everybody to a document that is put up by the open SSF, but then say here is a state transition some similar to what we had for a project life cycle, right. So this is the process that we are going to follow and this is the approximate timelines that you maybe are waiting in these phases. And for us, when you reference this document, these are the resources where you can do certain things because open SSF blindly talks about all the available options. Right. That is one thing that I would probably skip as part of this discussion. And probably that's also because that it is like a debatable topic, right. So we'll start the discussion on that by depending on based on the feedback that we receive on this call. We'll try to see if we need to include this in our first phase or maybe take this up as a latest task. So one of the recommendations from open SSF is around having a vulnerability management team, right. Let's review the current process that we have. And in the current process, there is high reliance on the staff. So somebody in the staff or maybe somebody on the security mailing list should notify the corresponding maintainers and maintainers should go and review a reported issue. And if they feel to the satisfaction that they reported issue indeed isn't is something that needs to be addressed and it poses a threat. Then, like there is that intake that we can consider a project. I mean, that particular project can consider that issue as an reported issue. Otherwise, there is a possibility that the maintainer whoever has analyzed the issue. Going into a discussion phase with the reporter or the other aspect that can happen is that they will say that, hey, this is not a security issue as you point out to be. This is basically our design that we have or a design assumption that we have in the project. And in our assumption, we do not consider these scenarios. So there are these different possibilities that may occur. Now, in terms of playbook or in terms of different phases that we will have to handle. I know having a central team that will be a single point for all the projects. Maybe too much for that particular team who's trying to handle it. Some of the recommendations previously that came up in the previous task force is to have a representation from each of the graduated project. If they're graduating from labs or if they're entering into incubating under hyperledger, they would need to have a representation into a team. And each of that the person either should delegate when issues reported against their project or they themselves are responsible or accountable for following up on that. I know I brought up a bunch of topic here, but I'll take a pause and then open up for comments. So I think this is where it starts getting interesting and where we have to define the policy for this for our foundation. And I think, you know, I would set some rule that says every project must have identified, you know, named a person to be at least one right to to be the the vulnerability management team for that project. And that should be a condition to be within hyperledger, but frankly, thanks a lot, Tracy. Yeah, I think we have that. I think that was one of the things that came out of the out of the security task force last year. I can't remember if we added it for only graduated projects, or if we added it for incubation but I remember adding it to one of our documents under the to see the hyperledger.org. So I'm trying to find that. I don't know but I think I mean, we may have that in the somewhere, but I'll be curious to hear from right because I think I remember right saying we that there are very few people listening. Hi, so. So I think the one of the topic that came up was a project maintainer who was on vacation and a delayed response to somebody who reported an issue. So without taking names, I guess, I mean, heart is recommending that those scenarios, like even though it's not intentional could happen, like an open source setup. So, yeah, I suggest that we have my thinking. So maybe the policy should be that we should have at least two people per project. At least. So since, since, so he's raising hand so adding on to the suggestion. So since we are talking about the security topic here. I propose that we also we make this process mandatory for all projects, irrespective of whether they are graduated or not. So if they're incubating and the hyperlensher if they're becoming a top level project that they are required to have this in place is Tracy. Yeah, I'd love to hear some of the main painters on the call. My thoughts are on whether or not they would have three people that they will as hard as suggested in the TLC chat, whether or not they have three people that they could actually nominate to be on the security team regardless of whether your project is an incubation or Yeah, I mean, I think it's fine to have three people if you have three people are up and willing to do that but I think even if you have just one person, it can be their job to delegate to somebody else that they go on vacation so all we need is one person who is in charge of receiving notifications and then figuring out what to do. Thanks from David. Yeah, I was going to say two or more would be a good policy for project whether it's incubation or graduated. Thanks to you. Yeah, I think I agree. At least to, we should also make it really clear in a concise manner when we announce this policy. What are the expected activities on this VMT team. I believe it's mainly monitoring the incoming requests. So, which means this team is, there's no like regular activities of this team, most of the time, unless there's a report. It's when they kicking to action. We just need to make that really clear. So, the teams don't think this is yet another, you know, burden on their shoulders on the day to day basis. I agree. So, Steven. The only caveat to that is when someone is appointed or however the team manages it, they do have to understand what their role is. They've got to go through the policies they've got to understand they've got to understand to pass off and things like that. I think that's the only while it's not a active until needed. There are some prerequisite learnings that are half have to be done. Thanks, Steven. Yeah, yeah, I agree with that. I assume there's going to be some at least some minimal trainings with either self reading material packages or a training session for fellow volunteers, or people who got volunteered. Have we talked about monitoring CV reports on dependencies, would that be something that each team do themselves. Each project is expected to do themselves or this is something that the that's the VMT team or that or if that's a different, different team within hyperledger that does that. Good question. So, I would say that that goes down to best practices in in pipelines and things like that like that's more of a project best practices and in particular where hyperledger can really help I think is in tooling and making sure people are aware of what's available and things like that. We're constantly or not constantly but having new approaches come up that we're discovering as a project and would be, I think, valuable to other projects across the way so again that leads to that pipeline best practices. Yeah, yeah, I think there's some some sort of blurring the line between it to supposedly each project should be on top of these things right for example if your JavaScript code base npm does really good reports of these vulnerabilities in different severity levels, having a pipeline that at least looks looks for critical issues would be a good thing and fail to build. And I don't know if that exists for other other languages. But there are going to be escapes, and they will turn into reports on the project themselves. I think far flat have had at least one on Java. So it ended up being a report on the project if we didn't address them soon enough. And that can be costly to the VM team can be costly to the foundation because they may expect a payout because they reported this. So I don't know if there are more things that foundation or the security task force can can think about so we can encourage the team or we can help the team to stay on top of this. Yeah, I do agree this is more of a project best practice thing. Thanks Jim for and thanks Stephen for bringing the topic. In fact, yesterday for the first time I attended the open SSF, the working group call on the vulnerabilities closures. What I learned, at least from that call is there is another working group or at least there is a project with an open SSF that is working towards this question that you brought up in terms of how do we address a dependency CVs within the project, right? There is a way of automatically taking care of fixing them and identifying and then figuring out the dependency versions and upgrading them. I guess some of the objectionable questions that were raised in that meeting where would the project maintainers be happy with those automated CR PRs and to what extent should that be taken care. But that's a valid question. And in these discussions, I think if I were to summarize last two, three minutes, probably last five minutes of conversation and probably bring up few questions that are still unclear is in terms of when we spoke about VMT, I guess. I forgot who brought it up, but I think Jim, it was you asking for trainings to the VMT right in terms of what they should be doing. A similar topic on the training is also what is the responsibility of a VMT apart from being a representative for the project within hyperledger. What else would that VMT be doing, right? So there are few thoughts in terms of what they could be doing. For instance, since they are going to know and they are the facing singles point for the projects, they would know all the things that occur in terms of security, at least for the project. So we could propose that VMT often meet with each other and then share the learnings across to other projects as well. It may be obvious that in few cases, some things that we do in one of the project could be a learning to another project. But hey, we made this decision long back. We thought like this was, this is what we assumed and we started with it. Like now we face this issue. So see if you can avoid doing the same mistake that we did. I'll probably see if you can, if you have such a design in your or such a dependency in your case and see if you can do a work around immediately before somebody else will figure it out. So this is one other thing that a VMT can do. And this will not just encourage the projects to collaborate and like know about each other. But this would also bring up in terms of security standards, higher quality code across all repositories and across all the projects. And it would also encourage security researchers to have these focused group conversations, join these conversations. And I mean the responsible people would also be recommending things to the group. I know it's all going to work out well if executed well, but any thoughts on these things. I think the training can be covered as part of these groups where we can invite an external participation or expert who have expertise on these things. We can have them as a guest speakers and then cover these topics in some of these regular meetings. David. I think the most important outcome here is some very clear guidance to the VMT folks. So I'm thinking like a one page guidelines document that references the open SSF stuff as background, but then it's very crisp about the expectations and guidelines. I don't think we need a lot of training extra meetings that type of thing, but let's make sure we have at least like a very clear one pager of guidelines. So any other thoughts on adding the additional responsibility to the VMT. So I don't know how to treat this response to me. Like all silence. Does it mean what I proposed is fine or what David is talking about is fine or like which one should we follow. Happy to. Yeah, I think it's a good idea. I also just wanted to say that I agree with the points about not making it a huge effort as an extra effort on the maintainers. And you know, with that, the important point made, I think it's okay to add. That's it. So to also answer your question in my case, silence was agreement caught you. So what we are then proposing is, yes, there would be regular interaction among VMT that could be offline. And if needed, it could be on the main basis requested call, which may be even like one call per month, right? Where we get all the VMT representatives. And sure, there will be given guidelines, which are offline references to go through and then they have a clear cut, crisp information available for what their expectations are from the project. But these additional guidelines or additional meetings would be helpful to enhance our learning, sharing sessions, what we can call. So I'll put it up in a proposal and then we'll see if there are any oppositions or any other thoughts right offline. I know we have like five minutes, but the other aspect that I wanted to cover it, like within these discussion points, which is still open as in terms of when does the responsibility of VMT gets, I mean, start, right? So does it start immediately when an issue is reported? Or does it start when a vulnerability is identified to be really an issue? Like what's the taking point when we start considering the timelines, the responsibility on the VMT itself start? What would be that initiation point of how we connect the dots, right? So one thing that I skipped in this discussion is this one, the topic of how to set the policy or how to handle the expectations. Probably this will address some of the opens that I have in terms of initiation. Yes, Tracy. Yeah, I think the, you know, if we look at what had been previously documented for Hyperledger, it was 48 hours to respond. We had the reporter acknowledging that they had reported something. And then one week to triage report and coordinate with the effective project maintainers to plan the fix of the bug. So, I mean, those seem reasonable to me, but I, you know, don't know if people think those are reasonable time frames or we need to extend them or shorten them one way or the other. And that's what was originally documented in the issue that we have for the security vulnerability disclosure. I did include what we previously had documented for timelines. And so I think it's worthwhile for us to just review what we had, see if any of that is still applicable and if it is great and if it's not, how do we need to change it? I agree, Tracy. I think we should start with what we already had. Assume that's still valid until somebody challenges it. So what we, what is stated there, those 48 hours in the 90 days is widely considered standard and sort of the upper limit of what you should have. You know, I'm comfortable if people want to bring those numbers down, particularly the 90 days, but I would say a template would have 90 days. I mean, I think though, like the Linux kernel has like either a week or two weeks now instead of 90 days where they basically, you know, they disclose things immediately, almost. But, you know, those are, you know, those are sort of the established upper bounds. And, you know, you can still see that those are the established upper bounds if you go through the open SSF content. Right. So, sorry, hard to interrupt. I think the, I got what you're trying to say. So what Hart is saying is with respect to when should the reported CVE be disclosed, right? And then in public, but I think what we were trying to cover is the, like what's the responsibility in terms of VMT team? Like what's their timelines and how much time do they have to respond back? And immediately when the issue is reported. So I, did I understand you correctly? So, I mean, I thought it was the VMT team that was going to respond to the initial people, right? So obviously, but I thought like Tracy is saying one week to try out, are we saying to change it to 90 days? No, the 90 days is to fix it. Yeah, I didn't read the rest of the responsible disclosure piece. I was only trying to answer your question, a room which was what is VMT responsible for initially and what's their timeline, which I thought was the 48 hours to respond and then the one week to triage the 90 days to fix is the next one in the list of things that are documented. And so I think Hart was just reading the whole thing. Yeah, that's right. Sorry for the confusion there. No worries. Yeah, we would have brought this up in some time, but yeah, thanks for bringing that up. Okay, I see we are top of the art, but yeah, this was a good discussion. We'll continue these discussions offline as well. And for the items that we have discussed today, we put them in the meeting minutes and see, yeah. All right. Thanks for taking us through that. We will do it again next week.