 All right, welcome everybody to the April 27th hyperledger technical oversight committee call as you are all aware you've all been on the call before. Two things that we have to abide by the first is the anti trust policy that is currently displayed on the screen. And the second is our code of conduct, which is linked in the agenda. Any other announcements today we have the standard definitely developer newsletter that goes out each Friday. If you have something that you would like to include, please do leave a comment on the wiki page that is linked in the agenda. Any other announcements that anybody would like to make today. I will point out that hyperledger does have a Reddit and we staff have been given permission to engage. So, if you go to our hyperledger and tell me your Reddit username I will give you the appropriate flair as a member of the community and I, if you want to jump in and answer questions and stuff that would be great. All right, I try any other announcements that anybody would like to make. No, okay, quarterly reports are the hyperledger fabric report is linked here in the agenda. Steve and I did see that you merged that this morning. So, yeah, there were a couple people who hadn't had a chance to look at it yet but please do take a look if you hadn't had a chance, good information in that particular report. I merged it. Pretty sure that's what I saw. No, I'm so used to hitting an approval and then seeing the merge and merge button pop up that I just didn't even thank my apologies I shouldn't have done that. Yeah, it definitely was I think you were maybe just a couple days early on that merge but that's okay I think people can still obviously have a look at it and see if there's anything there that they would like to comment on but Dave, I really appreciate the reports that you do put together for fabric. All right, as far as other reports transact is another report that we have that's been passed to you. So I know Daniela did say that she was going to reach out to Sean this week I don't know if Daniela has had a chance to do that as of yet. And I do not see Daniela on the call. Hey, we had a call with Sean yesterday. So Sean supported moving transact to dormant status, I believe. So, and eventually end of life in it. They wanted to make sure that sort of all of the, everyone had migrated off before they totally end of life did, but he did support moving it to dormant status. Okay, thanks. We can then get a PR open, or I mean an issue open for that so that we can. Maybe at the next call, just to make sure that everybody has time to think about that, unless people feel like they're ready to do that today. So yeah, also I apologize I'm going to have to drop to head to the conference. Okay, well hopefully heart. We will get some comments or some input on your security documents during the task force discussion so hopefully look forward to some information showing up. Awesome. Feel free to comment or edit the document and you know I will try to make more changes and I would eventually like to take that back to the open SSF to get their thoughts on it as well. So, yeah, let me know if you if you all need me for anything and thank you so much. All right, so then, Ursa, we do have a conversation here to talk about moving that to end of life. But before we get there just a reminder some upcoming reports that are due. I did see some conversations happening on that report to get that submitted to us so hopefully we'll be seeing that show up shortly. For next week we do have the areas in the and non credits reports that are due. All right, so without further ado, I'm going to discuss this move Ursa to end of life. I did see Mike had created an issue for us in the TOC. And also on the Ursa repo to move Ursa to end of life. There has been some discussion on the ticket that's in the Ursa repo about people who supported people who would like not support that. And so wanted to I see that Mike is on the call Mike. Any comments or input that you would like to provide to the TOC. Yeah, sure. So the people that are probably requesting to keep it open. I believe Aroha and some from the Aries community. And I believe this can be resolved pretty easily by Aroha I think is only using it for like one or two items. And so those could easily be extracted and given to their project. The rest of it that people are interested in can actually be moved to the hyper ledger non creds project. For some code and just put it there because that's really all they care about the rest of it could just no one's really using it. And the rest of the maintainers. I mean, I was the principal maintainer for many years. And ever since probably about three years ago, I haven't been able to give it full time attention. And then as of 18 months ago I pretty much stopped giving it any attention. And then the other two maintainers have just kind of been limping along on life support so I believe those that are kind of requesting keep it open. Other concerns can be addressed really easily. And as for the rest of it, I don't see any reason to keep it open. There are open. There's probably about three open security vulnerabilities on it. One of them is, well they're all they're all fixable. One of them requires a lot of coding which the maintainers don't have time for that's probably what you've got the task force discussion right there. The third one is an easy fix from a coding perspective, but it will take a long time for the cryptographers to work out what, whether that is actually a sufficient fix or not, which I also don't have time for the third fix involves changing some code which could mean breaking changes for downstream dependencies which I think would be that's why I think it'd be better if they just pulled out what they need. And applied it to their project. So it doesn't break anybody else who might need it. That's all I have to say. All right, thank you for that Michael. And I did see Brent also on the issue in the Ursa repo did also say that he was in favor of moving Ursa to end of life as well I think Brent is another maintainer on the project. So I guess we have a couple hands here to start the discussion Alexander. Yes. You know how perspective has changed. We are in favor of moving the project to allow specifically because when we were planning to maintain Ursa, we planned to break it down into smaller modules which can be loaded independently. But some other functionality would have just been completely gone. Some of it is just re exports of existing rust libraries. Some other things could have just been extracted specifically the problematic cryptographic modules. That is the intention. And this is where we're going. And it will be. We will consider refining what was in Ursa and potentially spinning it off spinning off your crypto off of it. Whenever there's need. We will probably need to engage more with an uncred and see what actually needs to be done with that. And I'm available to help with that. I just don't have the full time capacity to maintain Ursa anymore so I'm happy to advise on how to do that and maybe code a little bit here and there. In all due honesty. Given the scope of the changes that we wanted to do. We will not have been Ursa anyway. It would have been a completely different library which had some of the code inspired by us. This way we're going to get some compatibility and so on. So we'll be happy to have you around and help us with that. We will need a cryptographer eventually but for now, the things that work. Let's assume that they work well and let's use them. So thank you for that. I just want to make sure that I heard correctly in the ticket you said you were against moving Ursa into life and I think you've changed your mind to say that. Yes, Ursa moving to end of life is okay with the era folks. Did I hear that correctly. Yes, precisely. Okay. Great. Thank you so much. Stephen. Yeah, I wanted to add to Mike's, I believe the BLS signatures where it needs to be moved to Indy. So that's a second piece that needs to be exported out of Ursa. So the CL signatures to to a non creds I guess, and then BLS to Indy. Other than that, I think we're okay with it being end of life. We can manage it to get it done right. I think we have a developer that can do it to do most of the work like you helping it would obviously be appreciated. We will get the one of the things we want to add on is getting the CI CD right so the big thing in for us is on a non creds being able to get arm supported and things like that. And it's the same sort of issues that that that we wanted so I think it's the right thing to do when we're fine with it. Okay. So it sounds like the objections that did exist in the ticket are no longer objections. Anybody else who has any objections to moving Ursa to end of life. Obviously not as a vote but as a discussion item. I have one question for Mike. If this goes to end of life, should the crate be unpublished. Yeah, I will yank it. Okay. Okay. unpublished. What does that do the dependencies that are using it today. Can you explain what that the ramifications of doing that. Yes. So, in rust, you can yank a crate and anybody who's currently using it is still has access to it. But if any new projects come online, it'll just say hey you should use this anymore. Just, it'll give them a hard to error. If it's a new project with existing projects that've already pulled it before won't have a problem. Okay, so anyone building a non creds or building indie would not have a problem. They shouldn't. Shouldn't because because I've, because I've pulled I've used crates that have been yanked. And it warns me and says hey this creates been yanked but since you've been using it. It will still allow it. It sounds a bit like magic but The other thing we can do is publish one last crate that all it does is update the read me right that just says this project is no longer maintained. Okay. I would prefer to do that that unpublishing it sounds like a scary thing. Maybe it works but it sounds scary. So I would like to do the ladder, and then maybe in three months or so yank it. Okay. So, can we collaborate a bit on the ring me. Yeah, just submit a PR, we can just submit a PR for that and then you can review it. Alexander make sure you're looking for that too. Don't worry about me. We're happy to help as much as we can. Okay. All right. Thanks for see Mike. Thanks for stepping up and being available for people who are using our side if they want to move out of our like take a part of the project that is of interest to them. And even the project is being proposed for you well. And like, because of the specialty requirement, which requires a cryptographer to understand or be able to answer some of the questions. We still request you to be also available in just in case. If hyper ledger staff or maybe the to see or maybe other men members are requesting your help. Any other comments before we get to a vote. No, okay. Would somebody like to make a motion to move or set to end of life. Sure. All right. Thanks. Do we have a second. Second. All right. Thanks Bobby. Right. You want to give us a vote. Sure. How do you want it? Do you want roll call or gays and days. The gays and days are okay. Okay on the motion before the TOC to move versus the end of life status is there anyone that abstains. Is there anyone that. Wishes to vote nay on the proposal. All in favor say aye. Hi. Hi. Motion passes. All right. Thank you. And Mike, thank you so much for the work that you did put into Ursa. Over the years and as Arun mentioned, thank you for volunteering to help. I think it's a great opportunity for the folks who are currently using it to. Make any sorts of changes that they need. No problem. I'll still be in the hyper ledger committee. Just not. Not as involved as I could be as much as I want to be. All right. Thank you. Oh, I'm rising high for Peter. I guess Peter is unable to unmute himself. Peter. You can unmute yourself. Yeah. I can't unmute him either. Peter. Perhaps type in discord. The host is not allowing it says allow participant. Okay. So I'm going to uncheck that box. And then I'm going to check the box again. Peter now suggests that since other people have been able to unmute themselves. It's probably an issue on your end. Perhaps reconnect. And if you could, should we continue? Or did you. Was there something specific you wanted to. Thank you. Yes, please. All right. So. Yeah. So I guess the next topic. Unless anybody else has anything they'd like to get to you before we talk about the task force. Is there any other topics for discussion today before we do get to the task force discussion? Okay. I mean, I think it's off to you then. Thanks. So I know I wanted to send an email. I hope you all can see my screen. Which screen am I sharing? The security policy vulnerability disclosure. Okay. Right. So, um, I know we have had multiple discussions. I think I'll get back to the Tuesday recordings and send an email up to the Tuesday mailing list. Sometimes today or maybe enough this week. Regarding all the discussions summarizing the meeting minutes across different to see calls that we had the task force discussions. So we basically went through the recommendations that were listed in the open SSF and we discussed through some of the policies that works best for us within hyper ledger. And heart was really nice to put up or summarize the document and then propose that as a policy. Over here in the document and I see already some of the review comments, which kind of discussions going on on the document. But if you have not had a chance to look at it, but please to review this document. Once and share your feedback. Since we have discussed the recommendation topics from open SSF, what's pending from the task force as an outcome is to bring those into actionable items that we can propose to the to see and get those voted upon. And then the reviewing the document that you see on the screen. So in today's call, I think I just wanted to go through the document itself. Unless you have any other topics to discuss. Since I don't say anybody raising hands will probably read through the policy document in today's call right. Tracy I'm not sure like, how do we want to take this for this. Do you want me to, again, discuss through some of this as a revision item, like the previous discussion points that we went through. Or like do a review of the document in detail that we'd like to do. So it might be good to just cover the sections as a high level to talk about kind of what's in there. So that people who haven't had a chance to look at it yet, at least know what they're going to be looking at when they do review it offline. And then, yeah, if you think there's any sort of comments that are maybe controversial for right where we do need to have a discussion on those comments as a wider group, then maybe that's a good thing to bring up as well. I think that's like minor edits or things like that. I don't think we probably need to talk through those. But if there's anything there that you just think might require some, let's have a conversation to see if where people stand on this. I think that's probably fine. Makes sense. So let's do that. Let's revise through the high level topic items are the sections that are listed in the document. Again, these are the same set of topics that were discussed in the previous task force meetings. And without going into specifics, we will probably try to revise and get back those discussion items that we had. And for the details, I would again request you all to read through this document and then add those. As we like recently heard us as recent as in today's doc call. There is possibility that like the projects end up in some certain vulnerabilities like they may end up because of indirect dependency through the library they're using or it could be possible that the implementation itself could be missing certain things from a security standpoint. And of course, like when we come to know about it, how do we mitigate the risk? How do we handle that? Now do we still keep the bar high for the projects across? So it would impact both the project as well as, let's say, from a community perspective, the confidence on the code base that Hyperledger as a foundation is having those projects that we have. So that's about the policy and since this impacts all the projects that are incubated and ideally like it's always good practice to have this irrespective of the project status, good practice to have the security practices followed. But at least for the projects which are graduated, it affects the most, right? So over the period and during the task for discussions, we did have a proposal of having an infrastructure to handle the requests that are being raised as a vulnerability issue, which are being raised for security reasons. And in terms of infrastructure, one of the key things that we had discussions over was having, so there are two types of infrastructure that we are talking about here, like the way of handling the incoming requests as well as if at all anything can be done in terms of regular audits or regular reviews. So we did revise through the existing options that we have from Hyperledger, for instance, when I say existing options, it goes back to the security audits and the reviews that Hyperledger was helping all the graduated projects with, right? Now, apart from that, the other part of the infrastructure setup that we wanted to bring up was, can we bring in somebody who is, let's say, a responsible person from each project and nominate them and create a small council or a group which deals with all the security related requests. And this is the core group who would then navigate through the issues and then distribute them among the project groups and try to mitigate and then coordinate and have these addressed eventually, right? And then as part of that, when we discussed, there was proposal that instead of having one single person from each project, we wanted to have, let's say, I don't remember the number, I need to go back to the meeting of the notes. But I believe we proposed at least two or three from each project to be representing in that forum. And they bring these, I mean, they are the ones who would navigate when an issue is raised or when an intake request is found. And they are also responsible to make sure that we navigate them through the request that are coming in. We'd make sure this group is responsible to tell them about available policies and present them with the options on how to and when to make the disclosure public, right? And we did have discussions about the scoring criteria or like the risk, this is kind of a number that can be associated against each issue that is raised and this number, higher the number, the greater is the risk that we carry unless we fix it sooner, right? So, and then we did have discussions around which tool to use for it. And as far as I remember, the proposal was that we start using the Github's provided option. And apart from the number or the like scoring criteria, we did discuss about the embargo list. So this kind of talks about, let's say there is like a core group of organizations who we consider has highly impacted a group of people. So these could be like say the platform providers that if these group is compromised, then there is high chance that like a large population is compromised. And we did have discussions around how to come up with the list and who is responsible to maintain the list and what are the responsibilities from a project team's perspective. And how are they supposed to communicate and what responsibility does the hyperlegious staff have or like what really does this embargo list supposed to do and not do. These discussions were brought up during those discussion items. And so the other things that we discussed was about, of course, the security advisories but I mean it does tell about us like for instance, if somebody is using your project, how do we inform them about, let's say there is this thing that that's going on with your project and then it has been fixed. And now you want them to operate so that they are not impacted. This is kind of making them aware that like they are on a lower like a previous version which may be having a vulnerability that needs an attention from their standpoint. And the other topics that we did have discussions over were the private patch deployment infrastructure. So this is kind of the option where you as a project team would develop or work on an issue in a private way. And when I say private way, like you're still involving the relevant stakeholders and having let's say a patch kind of approach that we do for bug fixes, right? So instead of testing and making all the code changes public, which may leak out the vulnerability info information. It's good to do that development in a closed circle or in a closed fashion where only the relevant stakeholders are involved through the process. And they are aware of what's going on and they do all the testing and then once there is an agreement and once there is enough testing done. Then the patches merged and we did also bring up the topic of how to merge it and when to make the announcement. Like generally there is a grace period after the patch is merged before when this vulnerability is like made publicly available. But there is also there was also discussion where we had we spoke about like why it is important to disclose that information as soon as possible. After a particular release is done right after the PR is merged and that's pretty much it that we discussed about it and throughout the process through the task force. We did bring up topics about how many days should it be before we release. Let's say disclosure vulnerability in a public forum or what's the metrics are like how many how soon should we respond back and in terms of responsibility of that core group of security representation that we have from each project. So these are the topics that were discussed through the task force. I can summarize that in NT OC mailing list and copy this document as well. But I hope this was a quick refresher and any questions so far on this topic. I don't see anybody raising hand or unmuting themselves. So I'm assuming there are no further questions. So this brings security task force at least for the scope that we had to a logical conclusion and like we need to formalize these policies that we have into proposal to the TOC and to relevant parties where necessary and make them aware of these policies with that. I guess I'll hand it back to Tracy. Okay. Just a question for those who have had a chance to review this and edit your comments. Are there any pieces that you'd like to bring up as discussion items for the other to see members at this point. Yes, Steven. I would say, I put in the comment there and it's in there and I think it might be worth the discussion but this idea of separating out the how to do this from the here's a sample document that a project or a repository could use. I'm okay with it being all in the same document but I think it would be worth not trying to combine the two where you're explaining what you're doing and providing an example in the same context. So that's the other thing I'd like to see is just there be a very specific thing that you copy paste into yours and then adjust for your particular project. Any thoughts on that or folks who've looked at it or even if you haven't looked at it. I mean, Steven, I think it mimics kind of what you did with the maintainer.md file, where you had kind of the sample file separate than the actual text around how we do, how we expect being here is that MD file to exist. That's, I just find as a, as a maintainer, it's, it's much easier to deal with it that way. Okay. I really did have your hand up is there something you wanted to add to that. I wanted to comment there's like, instead of splitting document if there were any other suggestions on how else to like, talk about the policy, if there are any other suggestions. Okay, anything else then that anybody would like to bring up as far as comments that they did add they'd like to make sure that we do bring up here to discuss. So it does sound like we've made some good progress then on the security task force. So very similar to, I think, what we did last week with the best practices will probably have one more time for discussion for the security vulnerability disclosure task force to bring back to the TOC kind of what they would like to make as far as changes specifically to any of our guidelines and or governing documents to make sure that the results of this task force are included there on the TOC website. So, yeah, I guess with that, is there anything else that anybody would like to discuss today. Okay, so Bobby, I think you're up next. It also sounds like maybe we need to take a look at our task force issues that we did create at the beginning of our session for this year to see if there's other ones that we would like to pick up at this point, going forward. Probably in the next couple weeks, so we'll probably take a look at those maybe next week as well. And I guess I will let you go and talk to you again next week. Sounds good. Thank you, Tracy. Thanks, Bobby.