 All right, welcome to the July 7th, I do a technical serving committee call. As you are all aware, two things that we must abide by on the call. The first is the antitrust policy notice that is currently being displayed on the screen. And the second is our code of conduct, which is linked in the agenda. As far as announcements, we have the standard announcement that we have every week that weekly developer newsletter goes out each Friday. And if there is something that you would like to reach the hundreds of developers that we have, please consider leaving a comment there in the Wiki page that's linked also in the agenda. Any other announcements that anybody might have? Okay, so as far as quarterly reports, we don't have any due today. Looks like we took a little hiatus here on the quarterly reports, but I did include a link in the agenda for checking any open tasks that you might have to see if there's any open quarterly reports that you haven't yet reviewed. I did see a number of people doing that as I came in this morning and saw a bunch of emails from the Wiki. So thank you to those who did take the time. If you haven't yet had the opportunity, please do so. Ketchup now is a good time to do that without any quarterly reports coming in. Although I did see that the Hyperledger Fabric Report came out, it is due next week, so it's actually a week early. But thanks today for doing that. I think I'll go for updating the Wiki agenda here to include that link. Any comments or questions, anything that anybody wants to bring up before we get to the discussion item that we have for today? Seeing none, then we do have one discussion item for today. It's a carryover from last week. It is the Security Task Force recommendations that Arun wanted to bring to the technical stirring committee. So Arun, I'm going to hand that off to you for walking us through kind of those recommendations. Thanks, Tracy. Last week we were unable to cover this as I was running late and then we could not get enough time after discussing previous week's agenda items. So this is the second time we are bringing the recommendations sheet that I'm showing currently to the TSC. In the previous call, I briefly discussed these 10 different action items or 10 different gaps that were identified and that we had to work on. However, one of them is already considered and accepted from the TSC where we are mandating that each project should have a representation and have a representative who will be responsible or who will be first point of contact for anything related to security and including fixes that are to be done, including issues that are reported. And continuing on that discussion and I noted that there were few open items from the time that we last met, last assembled on this topic. Few of the other topics that are straightforward or recommendations from the task force is to adopt some of these recommendations that are coming in from OpenSSS right away. So I'll defer to some of the comments added over here even within those bullet items for the discussion point. However, I'll just cover different items that are to be adopted and as a recommendation that are coming in from OpenSSS. One of them is the scorecard. And I know we had different badging proposal last year and then we went through multiple iterations and discussing that. So scorecard is kind of going to score each project with a repository and it takes us through a checklist and then make sure we are compliant and we are following some suggested recommendations which are good to follow from a security standpoint and there was a recommendation that there is no reason why we should not follow and that becomes one of the metric for us on how we utilize it. However, the bigger picture or bigger point over there is it was related to how well each project is responding or reacting to the issues and then this kind of ties back to this point number seven that is written over in terms of responsible vulnerability disclosures. One of the open item or a bigger debating item that also came up in this week's task force meeting is also on how do we make sure each project is advancing on the issues that were reported, right? So this is where we need discussion within the TSC and probably potential ideas on how that can be implemented across projects or like I can just talk through some of the ideas that we had on the task force. So one thing would be that CVs are to be addressed from the time they are reported within 90 days of time. If they are not addressed within that amount of time then it will be made public and it kind of becomes kind of adds a pressure to the maintainers that they will have to complete, they are allowed to address this within 90 days and they want everyone to know that something like this exists in the project which I don't think that should be done. I mean, it kind of forces everyone to do it. So this was one of the idea, right? So again, this has to be, there was a recommendation there should be strict guidelines around how, I mean, the responsible disclosure element itself. So there are two angles to it, the responsibility from within the project and then the responsible disclosure aspect of it. So I'll probably pass a while and of course there are a few other elements. I mean, we would like to definitely, I want everyone's opinion or probably debate on this item. And the other non-conflicting or straightforward items are with respect to the release process which was open in the previous discussion. So there were discussions around this in not this week's call, but the previous week's call thanks to Artem for all the inputs. I think you also suggested that fabric team uses Trevi for all the production. I'm not sure if it was fabric or at your workplace but you are using Trevi for scanning container images. So idea was to have the verification or the reporting process or the identification process built into the pipeline and in the CI and both CD. So in the release, the artifact releases, the binary releases that we are going to have it, even those are to be scanned at a given frequency and that frequency is not recommended from the task force using tools like these, right? Those artifacts could include the container images. That was another straightforward item, I mean, a non, what do I say? There was no conflict of interest or there were nothing that people would be contradicting to if we bring in that process. And yeah, I will take a pass here probably and would like to hear feedback on the scorecard and the vulnerability disclosure element. Mark. So Arun for those of us who have not been part of the security task force, I don't think that there's been opportunity of time to review kind of these extra links from open SSF with the vulnerability disclosures and the scorecard. I guess, you know, from the security task force perspective, the recommendation is on the vulnerability disclosures. The only real recommendation that I think I heard was the CVE suite published by the end of 90 days. Is there anything else in that link that we would be needing to handle? Oh, okay. I would definitely recommend everyone to review the scorecard when it comes to the above element which is the vulnerability disclosures. It mostly talks about the reasons and I believe it also has collection of some of the incidents or like CVs that were reported from the past that I'm not from. Yeah. So this is something definitely to review in terms of what needs to be reviewed. However, this is fine. Over here, the important aspect is in terms of learning from the experience, learning from what others have faced in the past and trying to understand at all the best model that works for us. So I would still probably recommend to have a glance through if possible. It's more of a retrospective way of understanding what happened and then how do we make our processes better. So apart from this 90 days thing, the scorecard was another proposal that came in from the recommendation, right? So I don't know, like, do you want me to go through each element or here or do you want TSE members to give some, I mean, give TSE members some time so that they can go through it and come back and debate or probably debate on this topic just from a standpoint that what are the problems that committers are facing right now or the maintainers are facing and why would it be a challenge that fixing something within 90 days is not possible or should we look into, for instance, the current release process because right now, hyperlature does not have anything to say when it comes to release lifecycle other than, I think even that heart corrected me that the release taxonomy thing is also not so tight right now, I mean, there is so much freedom from each project in terms of how they can proceed with the releases. So there are multiple ways in which we can address this particular concern. We can even tie this in with the release process itself, we can say that anytime a new project is releasing and if they are coming, they release us, let's say, a major release or probably a release that they are going to support for a long time then it becomes a responsibility from the hyperlature foundation because the release is happening under this umbrella projects. So if anything gets reported then it's responsibility or anything that comes back would be named against the foundation and not just the project as well. So I don't know, a governing around that would also help our benefit. I did not put those thoughts because I did not hear an affirmative response from those who are on the call regulated to those topics. Hey, Tracy, yeah, thanks. So I think to sort of addressing your point, I think the plan today was to go over some of the recommendations and then hear what people think and then eventually package them in some kind of actionable way that make an actual rule that the TSC could vote on. So I think that's the plan in the future. But this is more of a, these are the recommendations. What do people think? And then can we package these into rules? We'll be coming, so. Okay, yeah. Thanks, Craig. And I think that's my concern, right? I obviously have not attended any of this duty task force calls due to conflicts. And so for me coming in kind of fresh and I'm sure there's other folks on the call coming in fresh to looking at this and not having clicked on any of these links. I'm like, okay, what do you want us to do, right? And so I guess the thing that you're asking for right now is just commentary specifically on seven and eight, not necessarily on the rest of them at this point, but eventually on the rest of these recommendations. Is that kind of where we're at for today's discussion? Yeah, well, we'd love commentary on all of them but sort of, we've thought that seven is something that very much needs to be addressed and it's easy to address. So our plan was to go over this and then if people are okay with it, maybe in a week or two we'll propose a rule. Now, some of these have sort of already been the policy in theory, but there's never been any enforcement and nothing has ever been done. But yes, I hope that makes sense. Yeah, so I mean, for number seven, like I said, I think the one actionable item that I see there is the 90 days, which personally, I don't have any sort of commentary for other than to say, I think whatever the best practices is, that's what we should do. And I'm assuming that OSSF has the best practices and so therefore that 90 days is coming from them and is probably the right direction to head. For the scorecard, I guess the question that I have is right now we do, the only scorecard that I know that we're doing is, I forget what it's called, because it's changed name, but is this somehow different than the existing kind of self-attested responses that we have for our projects to see that they're in a certain state? Is this only focused on security? How is this different than, is it how does this, one, benefit the projects and two, benefit the Hyperledger Foundation? I had a heart, I see you, duck your hip up. Arun, if you want to take over, please feel free to jump in. Right, I'm looking for my hand to be raised. I will say that, yeah, seven also involves getting project contact points set up. So we think it would be good to require that graduated projects have security contacts and we plan on writing that down in a rule. As far as the 90 days goes, yes, that is very much the standard beyond the open SSF even. Arun, would you like to talk about the scorecard? Yes, I finally found my hand icon. So Tracy, I guess you had a couple of questions in your previous ask. In terms of scorecard, I'm not sure if you're asking about the CIA badge that we earlier had to our projects. It's like the one that you're asking. Right, I think it got renamed and this scorecard captures elements in addition to that if I'm not wrong. Right, I need to go back to my notes, sorry. I'll check the notes from one of the meetings. But sure, I think another question that you are asking with respect to 90 days was and art also kind of brought up a separate committee. So now that we have representation from each project who is responsible to handle those issues, what we were thinking is in terms of long term plan, have a committee set up, give focus more towards security aspects as well. And this needs to be a kind of cross collaboration that may not necessarily be within the project, but try to address some of them cross projects and try to see how to handle them. So in order to support that or encourage it, there was also, there were also discussions in terms of stopping a project from graduation and unless they meet certain criteria. And then this criteria evaluation happens through a committee which is again self-formed with these group that we were talking about. And so again, there were a few other open items will TSA be okay with it and with the shift towards TOC or TAC, how would that be handled? What kind of responsibilities would this particular group of members would have and what would they be making decisions on? These were some of the open items that we could start debating in terms of how to handle it, right? Okay, so back to the scorecard. So this is different than the open SSF best practices badge that we have had projects going through or is this the same? Like, because the open SSF best practices badge has a security section in it. So I'm curious, like are we asking for more work from the projects? Is it, you know, how much more work is it going to be for the project? It would be nice if one of the project can volunteer and evaluate it. And I'm happy to walk through on that, right? So there's one more action item that I personally have taken through the task force that's to understand the current process. So I have set up some time independently to discuss with the staff members itself to understand what do they go through and what's the process involved and why did this question even came up? That we are talking about disclosing vulnerability at cutoff height of 90 days and why is it taking that long for us if we know that it's a critical vulnerability? So in terms of scorecard, I'm still searching for a meeting. I'm sorry, I'll pass for a while. I see I'm not talking, I'm sorry, I'm not. Yeah, hi, I mean, I'm not talking yet, but I mean, I wanted to answer directly through this question. I mean, there is no current alignment between scorecard and the open SSF badge. And so they are indeed, you know, doing both requires more effort than doing one or the other. Okay, thanks Arnaud. Yeah, and I was trying to quickly scroll through this scorecard. It looks like there's some recommendations around some GitHub actions that projects can run to kind of get their score for this scorecard. And I guess, you know, I'm thinking about in the past where we've done things, where we've tried to make things easier for the projects and the projects have pushed back as far as, you know, they don't want to do that or it's, you know, the tools that we have are very specific to a particular language or whatever the case may be, right? And so I just want to see like how sure we are of this recommendation that the projects are actually going to think that this is useful versus it's painful for them to do this. I mean, no way suggesting that security is a bad thing here, right? I'm just trying to think about in the past what's happened within Hyperledger and the different projects when we've, you know, put down requirements for running particular tools. I agree. I think you bring a very good point there. And I just wanted to explain a little bit the background. I mean, open SSF badges are basically renamed CCI badges we've known for a long time. And the scorecard is a new tool that was developed initially by Google. And so there is, they don't share the same roots at all. And we can hope that open SSF eventually we all try to get all these things neatly aligned, but it's clearly not the case that they have different origins and they're actually maintained by different groups within open SSF. So, yeah, Hart. Yeah, so Tracy, you bring up a great point about things being, you know, easy and low, I guess low work for projects. So what the plan going forward is, we would like the TSC to sort of look over all of these recommendations. And as a starting point, we want to put together, you know, a list of some of the easiest and highest impact ones to implement, right? And then we will put those for approval for the TSC. This is obviously going to be an ongoing process. And some of the things are gonna, you know, take quite a while to put in practice. And something like the OSSF scorecard, which is, you know, not even, I would say, not even a complete effort at this point might not be one of the first things we do, right? We may want to let that mature a little bit before we ask projects to do it, for instance. And there are a number of other things on this list that we probably aren't going to want to do immediately, but we would like to see long-term. Does that make sense? Yeah, definitely. Just trying to see how we can help move this discussion forward, right, for something to come back, you know, to the TSC for a vote. So it's trying to really understand and helping that this discussion is useful for others as well, since I'm the only one who seems to be asking questions at this point. I think a lot of people probably have questions, but so thank you for asking them. Anybody else have any thoughts on this, Angelo? I like this, to be honest. This idea of the scores, maybe in this sense, maybe there is also something that guidelines that we can find out specific for blockchain that would be interesting. Can we ask volunteers at the beginning? Maybe we don't force, but we have a first period where we ask volunteers from the projects. I don't know, fabric, maybe we can volunteer, but I don't want to put myself in the shoes of Dave or no. But to me, this sounds very interesting as an idea. And maybe we can be a good point or reference point for the clients, for the enterprise who are looking for some handles. I really like this. Right, thank you, Angelo Hart. Sorry, I forgot to take my hand out. Oh, okay, I thought it came back up. Maybe you took it down and then didn't think you did. Put it back up, that's no worries. Any other comments? Kamlesh? Yeah, it is so clearly like this because I think this is a need to be in the Hyperledger Foundation project because even Arun and me in the Hyperledger India, we kind of responded to a couple of inquiries where people are using the projects and asked about the kind of vulnerabilities in the Hyperledger codes. And on that time, I think we don't have some kind of framework or some kind of recommendation if it's available. Then we as a community can share or maybe the people who are using the process can get confidence like Hyperledger projects are falling in particular. So we standard and some guidelines and ensuring the security aspect of the projects. I think it's a good initiative. All right, thanks Kamlesh. So I have a follow-up question which is I think somewhere as you were scrolling Arun, I noticed something about projects moving from incubation to graduate it. And so I'm curious as to security is not a one and done type thing, right? Security changes as the code changes. And so what sort of expectation do we have for the scorecard remaining up to date? And as the code changes, you know, the reevaluation happening to ensure that no security issues have been created slash added slash whatever, right, to the source base. It's a good question. I don't think so we discussed on that aspect but we were still thinking if such a thing would be accepted by the TSE or not. If we think we need to go in that direction then it's definitely we will start thinking in the next upcoming call. Later I'll bring this topic up again. And in terms of what we were thinking just for a regular cadence, I believe, I don't know. So there were, in terms of it was tying back again to the standard processes that we were following and then how do we make sure that we are following those processes, right? So I had two thoughts around it. One is with respect to apart from the process itself in terms of how well a project is going to handle and when something is reported, how well are we responding back to those? Even those metric are to be captured. But yeah, we haven't had a chance to discuss go deep into this direction and thinking that we were not sure if something like this would be accepted. Okay. Yeah, I do think that the considerations as far as the cadence for when this gets reported, how often this gets looked at is important. I just don't think that we can say that it's a static. We've done this when we moved to graduation and so therefore we're done and we're never gonna look at security again. That's the piece that I would think through what makes sense again with the caveat of how do we ensure that we're not causing more work for the projects than they actually need to be going through, right? Is it every time they do a release they have to do this? Is it once a year they have to do this? I don't know what the right cadence is but I think there is a cadence and we have to understand how that impacts the different projects. Angela? But for example, I would definitely would like to have an update when there is a long-term release, a long-term support release, that I would like to see that an update on the score there. I don't need to see an update on the day to day commit because as a company I would not take that, I would not use those commits, those temporary commits. So I don't expect to see the score on evaluate the main branch. That's for sure, I wouldn't expect that. Okay, great, thanks Angela. All right. It's really, even though we did not explicitly discuss going this far, assuming that we were not even sure if we were going to adopt a policy that would stop projects from graduating. So if we want to go down that direction then one of the thought process, at least it came in this week's and call were in terms of the 90 days boundary that we were to put. What if projects don't follow even that in that given boundary? So there were discussions where probably we should bring down that project from graduated to incubating, or that was one of the way. So we were discussing in terms of how can we make sure that projects understand that this is important. At the same time, we don't put in too much pressure in going and taking the drastic measure. Okay, that one got a lot of head raises, Bobby. Well, I know that we're working at the task force for the documentation and we're having running into the same issue. Like when is it required information from each one of the projects? When is it suggested information and what's the cadence for the update? So, I mean, maybe there needs to be some kind of system in place for the projects to, you know, maybe with the new release or yearly check in and say, yeah, all this stuff is updated. Okay, Troy. Yeah, I was just commenting on the idea of moving graduated projects to incubate it. I think we should be careful about throwing out those kind of ideas. That's extremely drastic. Okay, Arno. Yeah, I guess I'm kind of in the same, you know, thought here. I mean, you know, before we get into discussing predictive actions against projects, I think, you know, it would already go some ways to come up with clear recommendations, instructions for the projects to follow and then, you know, we can see how much update response we get and if really there are projects that seem to be reluctant, we need to try to understand why. And only once, you know, we've gone through the whole process of ensuring, okay, this is really something people must do. We should think about, you know, this kind of action. I think for now, I mean, we haven't had any policies. We haven't set any expectations, even though some might feel like, hey, this is, you know, part of this should have been taken care of by any, you know, reasonable project. I think, again, for now, we should just lay the ground, so to speak, on what the project should do. Okay, thanks Arno. And Jules? Yeah, so I will start by saying that I don't like the paternalistic approach. So I think we should not mandate anything specific, but this core, who is the target of this core? These are the possible clients or possible users of this enterprise. So they will be the one pushing for having this core. So if a project doesn't update the scoring or doesn't update this, they will just lose tracking because they will, the client enterprise will prefer other blockchains that are pre or other tools that will are keeping up with the scoring thing and so on. So in key, I guess our guidelines, I would expect guidelines and say, if you as a project, you think that for your clients, for potential new potential clients, this is a good thing, follow these guidelines. If you don't want to follow up to you, I mean, then we are all on the market. All right, and Art? Yeah, so a couple of comments. Angelo, I think you're thinking like a security professional and I wish more people analyzed situations like you. Then again, if you look at how much money, some say people dumped into the iota cryptocurrency with their hash function, if you recall, I'm not sure everyone makes these educated decisions. To Arno's point, we don't want to sort of immediately throw out everything under the sun. We want to sort of slow roll these things out piece by piece, right? So any kind of binding rules or anything, we plan on moving a little bit at a time. And as far as active projects goes, if a project is not responding to their security vulnerability reports, should we really consider them an active project? I mean, I think at some point we have to draw a line in the sand there. Well, Troy? Yeah, I mean, I hear that. It's just at some point we have to also be worried about maintainers time and interest and not every project in Hyperledger is a blockchain. For example, Aries is a set of umbrella projects and I'm not sure how these ideas about kicking things out of active would actually work for all the projects across Hyperledger. So I again, urge caution on these kinds of ideas of punitive measures where maintainers may start losing interest in Hyperledger, right? All right, that's Troy. All right. All right, so I think it's the reason I did not mention this particular thing in the very beginning is to avoid these kind of discussions. I understand all projects they work. We work hard to get them into the stage where we are currently and then the old intention over here is to understand what is blocking and from addressing some of the critical vulnerabilities versus prioritizing them as opposed to like, for instance, we know that active projects are being worked on and when we know, if we understand that this particular issue would take us to redesign certain elements and that would take more than 90 days. Yes, that is understandable. So there will be, of course, provision. So it's not, it was just a thought process, like it won't be to that level for sure. But there will be some recommendations which will come in a way, which will allow a pathway where project teams can explain why certain thing is taking longer than expected and allow them to discuss through their scenario and if needed, see if we can get some help from some other place. So it's more to understand what's happening and then I would probably also request this quorum now that we are understanding the intensity of the issue of for any such suggestions that you may have, what might benefit each project, right? So I think it's good if we can also bring in those ideas. If you can share those ideas that you might have, it will definitely help us. All right, thanks so much. Any other thoughts or comments? I think one thing that I heard in the discussion that we just had is that people want guidelines, not mandates, which I think is very much on point with where we have been in the past with our history for the technical steering committee. So just maybe take that into consideration as you move forward with this part. So I will say that pretty much all of these rules have been stated as guidelines for quite some time. Like the 90 day thing has been in the security guidelines since I wanna say 2017 or 2018. And at some point, well, we have to ask if these guidelines are being effective. Yeah, and the question there, I think, 2017 we had, what were the five projects or something like that, right? We've thus increased since that point, have we done a good job of communicating what guidelines exist, when we onboard new projects? I'm not sure that we've done a great job of that in the past. And so maybe that's a question of how do we do a better job of bringing along the history to new joiners, new contributors, new maintainers, new projects as they come into the Hyperledger Foundation? Totally, you're absolutely right. And I also wanna emphasize that we don't want to just sort of dump a bunch of mandates out on the community, right? Anything that we mandate would be sort of slow rolls, if that's the right word. You know, we would wanna, you know, we don't wanna take, we don't wanna do this sort of all in one big, massive chunk, right? We wanna do a little by little by little. So something like our first mandate that we would want to see would be that every project would have two maintainers or two people on the security, the security list for Hyperledger, right? So this is how you, this is how, you know, if someone files a bug or posts something on hacker one, this is how you get it, right? And this is sort of like a very minimum low bar, you know, and I would be surprised if anyone were against sort of this being a mandate, right? Because it is such a low bar and it is something that, you know, projects would really have. So we don't wanna, you know, start with massive mandates. We wanna start with sort of, you know, small, easy things like that. And then we can gradually, you know, if things go well, introduce more stringent requirements. I hope this makes sense to everybody. Yeah, I just think of what this would have done to a project like Burrow where, you know, they might have had a few maintainers, but some of them maintainers were a bit of a stretch because they were trying really hard to grow and recruit more contributors and we're struggling to do so. And so, you know, I don't think it's a question of the reasonableness. I think it's a question of, you know, how do we make these guidelines to where they, they help grow the project? I mean, we help make and show clear value or we use them as a marketing tool or we do things to try to align these extra steps with things that help bring customers in or help bring contributors in and hopefully convert them to maintainers. And that's where some of these steps, they feel reasonable when we think, oh, well, everyone has plenty of time to do them. But when we're kind of in the middle of one of those projects that's kind of trying to get that traction, it can be hard to meet all of these checkboxes at once. So Nathan, Borough was never an active project. So I don't think this would have ever applied to Borough. And I don't think this is meant to apply to, you know, projects that are getting started. This is more of a steady state, you know, long-term, you know, your project is in production so we need to have confidence in its security kind of thing. Does that answer the comment? It helps. It just, it feels like we're adding enough requirements that we need to acknowledge that it creates more distance for those projects to cover to get where they're trying to go. Yeah, I'm, you know, I'm, of course, agreeing with Nathan there. I am worried that we're not using enough perspective from the maintainers on these discussions, right? I am worried about the same points about loss of interest, loss momentum. It's not just about this thing, right? It's just in general, the shift from kind of the coder's voice to not is something we should be careful about in trying to attract projects and people's time. That's true. Might be worth the task force reaching out to the maintainer's mailing list or the maintainer's chat channel to have some of these conversations to see if there's other sorts of input that might provide a different perspective or idea. Aaron? Just wanted to understand the last concern that Troy raised, is it more to understand? I mean, is it that you're asking how do we differentiate any issue against a CVE or is it on the other spectrum? Like once it is determined to be as a CVE, like how do we protect our maintainers from having to do something in a given time? No, it was just a general, is it just a general comment that I'm worried that, you know, we're kind of shifting from the guidelines and growing projects and using the coder's voice for example, the TSC and shifting to LESO. And I think the less that the coder's voice is here, the more trouble we will have growing projects and attracting interest. So just a general comment that I am a little concerned. Sure, thanks. Any other comments or feedback for the security task force and the recommendations that they've been sharing with us? Any, Arun, Hart, any questions that you have specifically for the TSC that we can answer that we haven't already talked about? So would TSC be open? Sorry, I'll go next. Hey, Peter. Just one last quick comment on, I think the theme is here from people's comments is that some people say, oh yeah, we need better security, we need to improve. Some people say, okay, but we don't want that to cost us maintainers who would otherwise be willing to be maintainers or contributors, but then because of the security process they would just shy away from hyperledger. So I see both points being well made and then my thought on that is that we should keep this in mind as in just the mandate should not be too harsh but we should also keep in mind that there is a bar that has to be set it's just a matter of where we set it and then wherever we set it should really be the level where we actually are confident saying, well, if you want it to be a maintainer but you think this security bar is too high then maybe it's better for everyone if it's not happening actually. So that then we all have to be sort of confident in believing this and then that way this question, this conundrum can be resolved in my opinion in a way that everyone is satisfied with it. So it's a gradual thing and we can set the bar wherever we want to. So I think we should focus on not whether mandates are needed at all or not because I would say there has to be some but then we can keep working on where the bar should be with these mandates because there is a version of events where the bar is set too high and then we lose valuable people who would have been great maintainers and they would have put in some effort in security just maybe not the extreme that we set but there's also a version of events where there's no bar at all and then some people end up being maintainers who really just did not care about security at all and I would try us to focus on staying somewhere in the middle, which is the optimal. Thank you. All right, thanks Peter. Yeah, thanks for the comments, Peter and I want to reassure everyone that in all of these meetings, any mandates that we've talked about are extremely minimal. The bar has been extremely low and it's been sort of things that you think about and you're like, if some project didn't do something you'd be like, wow, that's really bad. That's embarrassing. We don't want to start with a high bar. We want to start with something very, very low and very easy and we have talked to maintainers and we have taken into account how much extra work that these things would involve for maintainers and we do want to keep that as small as possible. So we have, Arun is leading this and doing a great job and we have addressed, we have thought about these issues and we don't want to scare anyone away with a too high bar. So I hope that all makes sense. Thanks, Arun. Sorry. Yeah, I mean, I think everybody, I shouldn't say everybody, but I think most will say security is important and tracking these issues is important and the downstream organizations that use these projects will probably agree with that or should. But in some other ways it will also drive the utility and the usefulness of these projects by these organizations and if they're not doing these things and the projects won't be used. There is alternatives to the TSC trying to have uniform high bars across all projects where it may make less sense in certain cases. So that's kind of the problem with, I think, setting the unified bar for everybody when these projects aren't even all in the same category. So again, like security is important, tracking these things is important, especially in production organizations downstream from it will push from it besides these kind of goals. But I think keeping the maintainers on board is quite important and getting momentum is quite important, right? So it is tricky, but uniform rules I don't know that always works, right? So that's why guidelines is kind of an interesting way to be and obviously things embarrassing should be addressed. Yeah, so Troy, those are all good points and these have come up in our security task force meetings. Obviously, like, you know, a blockchain explorer is going to need different security scrutiny than, you know, a blockchain itself, right? Or a cryptographic library or something like that. You know, we've thought about this. We have discussed this extensively. So I think, you know, we, this is not something that we haven't considered. You know, even if it, I guess, doesn't make it into the recommendations document. But if you or anyone else, you know, is interested in this stuff and wants to talk about these issues, I'd highly recommend coming to a task force meeting because I think a lot of the questions today, we actually have addressed and have talked about in the task force meetings. And they, you know, just, they haven't percolated up to this document. Yeah, I mean, that's fair. It was just, I think I got triggered by the fact that there's two on the, you know, the offhand comment about downgrading projects where we're clearly, that that's, that turns from, you know, not a discussion about fixing embarrassing things, but to setting very high bars and being punitive, right? And that, when it starts sounding like that, I think people's hairs go up, right? Sure. And, you know, we're just, we just want to ask for, like, you know, very minimal things, right? You know, we don't want to, we don't want to punish anyone who's, you know, trying, right? So, so I think, you know, we'll come up with something more concrete, I think, than these recommendations. And I think people will see that this is not like, you know, being punitive is not the goal, right? We want to just, we want to incentivize people to do the right thing. So, we don't want to punish people for trying. So, so I hope this, I hope this makes sense. And I hope, like, you know, if we can come back with sort of, you know, more concrete things that the TSC can actually vote on, that people will see that they're not, you know, excessively punitive. And I don't think that a lot of these worries will, will come to fruition. All right, Peter. I just wanted to agree with Hart and try to also say a different way that I just thought of, which is that probably what we want to avoid or protect against is this sort of legal term that I heard, which is gross negligence when people cause some big trouble just by not giving at least a little bit of attention to something. So I think if, if, if a phrase of that way, then everyone can agree that we should try to prevent those cases. You know, if, if there's a DLT project within hyperledger, we should try to prevent issues there. Huge amounts of money would be lost in a production deployment because someone didn't take five minutes to double check something. So I think the scope, if you think about it that way, then it becomes visible why at least a little bit of something is necessary. That's it. Thank you. All right. With that, I think we're just about at the top of the hour. I appreciate all the thoughts and the comments. And I'm sure the security task force does as well. Heart Arun. Thank you for bringing this to us. And we look forward to having some concrete guidelines being brought forward to the TSE and the future for us to have a look at and comment and hopefully work through the process of deciding whether or not the guideline is something that we want to bring to the different hyperledger projects. So with that, I'm going to close today's meeting. Thank you all for your time and we will talk again soon. Thanks a lot, Tracy.