 All right, welcome everybody to the March 9th hyperledger technical oversight committee call as You are all aware 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 As far as announcements we have the Dev Weekly developer newsletter goes out each Friday If you have something that you would like to include in that newsletter Please leave a comment on the wiki page that is linked in the agenda The second announcement is that the hyperledger mentorship program is still looking for project proposals You have less than a week to get your project proposals in please Please do add those project proposals to the link include it in the agenda and also Min is looking for one additional reviewer for the TOC to review the project proposals once they come in So I think right now we have Marcus Roon and Peter that have volunteered So she's looking for one more person if anybody would like to volunteer Please let Min know and then the last last Announcement that I have is that daylight savings time begin next week in North America So next week that for those of us who aren't changing time yet or who don't change times this meeting is going to appear at a different time on your calendar, so please be aware of that For me I get to wake up even earlier next week. So really looking forward to next week when it shows up Other announcements that anybody has that they would like to make No announcements, that's fine. So we do have some quarterly reports that are out there. I did take a look. We still have For most of these we we cannot yet merge them We still have at least three people who have not reviewed them and then I don't remember which one Only has like five reviewers and so please if you haven't had a chance to review Please do review those as far as Comments or anything question. I didn't see anything coming up in the the comments But if anybody has any questions or comments on any of these reports Let me know now So then we do have two past due reports Reminders have been sent to the maintainers on March 2nd for both grid and transact There is some ongoing discussion in the transact contributors channel With Sean Asking about what sort of status this project might go into such that they can do minor releases Whilst while they're moving the the code to live sawtooth but without having to do project reports, so My My expectation is that we may see a request coming into this to a dormant state in the future, but Sean would like the rest of the developers maintainers to wait in on whether or not that's the move they want to make and Then I haven't heard anything back from grid Probably worth sending another second reminder to them to the channel today and seeing if we can get some sort of response back from Hyperledger grid Any thoughts or comments on those two? So Tracy MSM I don't quite understand that the motivation for the spatial status is just that they don't have to do the quality report So I think I think the intention or no is that transact is going to become end of life at some point in the near future Because they are trying to move the code that was in there to live sawtooth And so yeah, I think they're they're pretty much not doing a whole lot of work there at the moment Dormant actually probably makes a whole lot of sense for that, but yeah, I I don't know that a status change should change kind of the the reporting nature of the project Well, maybe just, you know, I Don't think, you know producing a quality report for a project that doesn't do much is a pretty Easy task. It seems to me so but okay Either either it's dormant and nothing happens anymore They're still working on it even slowly and then producing a report doesn't seem like a very taxing activity too Even if the report was just We're playing on the end of life in this soon Nothing happened Yeah, exactly and I did pull together this list of activities on the transact star repos And it's pretty much been dead since I put in some change requests to retire maintainers in september. So I mean, there's not a lot of activity going on here I think yeah, so september of 2022 was the last bunch of commits there, so After that nothing Okay As far as then upcoming reports, we do have the q1 ursa report that is due next week So we'll have to see if we can get that sooner than three months out from now Hopefully we can get that one to come in on time or close to on time For discussions today, I did have the task force discussion set up. I did also see that we have a New pr that's been created by steven on the maintainer guidelines It's not linked in the agenda unfortunately But but it is out there and there have been some comments on those On this particular full request But I know that not everybody has had a chance to look at this. I think only three Um, three to see members have had a chance to actually review and provide commentary But this is something that we should definitely take a look at. I think there was one item Steven that you suggested maybe we could talk about in the toc call. Is that something you want to talk about now? um, we could The question was whether um adding Whether a maintainer could veto The addition or or in fact removal of a um a maintainer in a repository um, this is text that I found in In earlier works or works that I based this on And so I just left it in there. I'm not sure the original source of that um so My guess would just say zoo I just thought it was a better to have the discussion. This is the one I believe we were pointed to um When asked to create a bunch of maintainer files, we we um aries had a bunch of repos without them and we got notices Um to create them and this was the suggested template to use Yeah, that behind me for that. I I did that. Okay um, but So do we think vetoes are needed? I mean I You know, obviously there's significant conflict if something like that comes up and and yeah My thought was what's escalation and do you take it to the toc or or where do you take it if there is that kind of um That kind of issue as opposed to you know, simply a veto which didn't really say where to go after that I you know for me as those others are pointed out in the That seems a bit extreme. I mean, yeah in an open community You would want people to strive towards getting consensus as much as possible and that's about as far away from it as you can be Yeah, so I wouldn't you know, there may be cases where some projects might decide to go that way And we don't necessarily want to prohibit it But I would definitely not put that in the template that we're encouraging people to use because I don't think as Hock said, I don't think it's typical at all. I don't think that's something we want to encourage Okay, um, what I'll do is just take another pass at that and remove that section with um a You know some mention of if there's conflict Um, just a matter of interest actually does it make sense that it If there's conflict it go to the toc or or do we just Not reference anything. Has it ever happened that we even have to worry about it? Right, I don't know if somebody else wanted to speak up but quick comment, right? I think previously we did discuss about this where maintenance are being not responsive enough And if the new maintainer who's being added They do have concern with the current maintainers not responding to them. I think they already know who to reach out to And in terms of making a decision for me and for making somebody else as an additional maintainer to a given project I think we should better leave it to the current maintainers of the project and um And we should let it to the project's governance itself It's a toc may not have complete visibility into What goes in and out of it? Good point Yeah, one of the things that that I tried to do in this was to separate that these Maintainers dot md files go in repositories. They're not Project files, which was a lot of the wording before so I think that that does help that you're right the Resolution of of any sort of conflicts would go to the project right Yeah, and fabric we have had a few conflicts in terms of new maintainer proposals And what we did is we just stuck to our rule which was majority of maintainers must approve it And sometimes we barely got over sometimes we barely got under but that's what we stuck with and I I think that's a good thing I don't think kicking into the toc would help because the toc doesn't have all the context of the project or what's going on so I think that's fine Good good. Thanks. All right. So I think um what we can do obviously is leave this in the pull request Uh, let people have a chance who haven't had a chance to review this yet to review it and provide their comments and feedback um, and then we can obviously bring this back to a future meeting for A vote to see if this is the the direction that we're all willing to to head with the Updates unless we can get you know the majority of people to Vote on the pr itself Rae did you want to talk about what you were just saying? Sure. Um, these are issues that I created and uh a long time ago and these are the uh The repos that are missing maintainers files I have a job that runs once a day to grab the maintainers files and uh These repos have not been in compliance for a long time I've offered and I know that um I don't remember the project off the top of my head. Um That these can be pointers Right for the ursa stuff This could be ursa could have one maintainer file in a repo and say please see this other file And I know that fabric does that for some of the repos. They say this This repo has the same maintainers as that repo and that's totally fine um I would appreciate it if I don't know There was something else I could do other than file bugs and Say hey guys, you're not in compliance with the uh common repo rules So I guess I'm asking for a hand from the toc Alexander Someone whose name appears here Quite often with hyphen.com python, you know junk scripted on ios et cetera The main issue that we are facing is that um A lot of the newer repositories That is those that are built for the rust it'll have version two have maintainers files It's just that they do not get recognized because they're not the main file Unfortunately, we are in a bit of a precarious situation in the sense that on the one hand The it'll have version two is not yet ready for the blind time On the other hand in order for every development every change to be applicable We kind of have to change this also for the it'll have version one and the original maintainers of that are completely gone To the extent of which we can make some modifications But almost all of them have to be tracked and we don't even have the infrastructure to check those Should we really just move on to deprecating you know her one and thus move the helper repositories out of those So this is the repo that you can't get stuff merged into Um, yeah, we can get stuff merged into and I think we added a maintainer's file If not, then the pull request is the handle. Yeah, we did It this this repo wasn't on the list Yeah, um a lot of others were there Yes, so what i'm saying is those other ones you could just put a pointer and say please look here And if you can't get that merged I can just I can I can merge anything in any repo. So you just tell me merge this file and it will happen Okay In that case, we'll just close those issues last night very quickly Thank you All right, uh any other discussion items before we move on the task force Discussion Okay, uh, then I guess Arun it's to you Thanks, racy. Hi everyone. Good morning again and good evening So um previously we were discussing about And just for the context right so we started discussions on Having a vulnerability management team and each project nominating at least two people to this team And we were discussing about the roles and responsibilities of what this team is supposed to do and that's where We had few pointers. I don't have those notes handy with me right now But I would like to continue Further on that topic right so For today's discussion. I do have five points that I would like to bring up That we as a TUC can pitch in and then create a process for ourselves here in the hyper ledger So the first point We'll we'll come back to the roles and responsibility of the VMT right as part of some of these points that I'm going to bring up today But for today's discussion, let's discuss the first point which is related to um the association of hyper ledger with the cve numbering authorities, right? so Let's assume for a time being that In one of the issue that is reported is indeed a vulnerability that has to be addressed And now as a hyper ledger foundation We um We may need to recommend those people who report those issues a security issue And then we may need to work with them and creating a cve Number right and these numbers are issued by These agencies or authorities I don't think so hyper ledger foundation has that authority. I think heart mentioned that sometime ago but we can work with some of these authorities and and um Create those right um So that's one of the open item that we can discuss over so we do Heart is correct. We do not have A the authority to issue those however. We have been issuing them through hacker one and github So we can't get them issued for issues in github I do want to also bring out the the point that when we report The vulnerabilities to these authorities. I think they go through a set of questionnaire And when we answer those questions It assigns a score against the issue that we have reported And this court tends to say how severe is the issue? And um Oh, sure. I was just going to ask a question on the cve stuff Um, do we want to still sort of have the thing where hyper ledger? You know causes are You know does the cve process or do we want? Uh, you know, do we want to make it More so that projects can sort of handle this for themselves? I know there are some cases where You know where it might be it sort of has to be out of hyper ledger Uh, but there's is someone brings up the basu at github But you know, most of them are done like through hyper ledger at this point Except for the ones that come in through ethereum So I just don't know if anyone has any thoughts on that Like are you happy with what's going on right now with the cve's or do you want something more flexible? I can tell you for one of the fabric security vulnerabilities We opened a github advisory And there was also a hacker one report and we ended up with two cve's and there were duplicates of each other It caused a little bit of confusion So it would be really nice to pick one or the other as the preferred approach instead of both So I guess do you want us to state that in policy that one should be preferred or do you want to pick yourself? I think we could define that as a policy at this to you see here Okay, I don't really have a preference. I just like us to Decide on one or the other Yeah, I think github is much better Uh in terms of our ability to We can issue a cve against any repo. I can't imagine a time where we would need to issue a cve from Hacker one that we couldn't also issue from Get up If you're going to pick one then I will give a plus one to get up Okay, so maybe we say We'll say in the default policy. It should be github, but You know, if you have a good reason for it not to be github, that's probably okay too And my thought is that like So of the basic stuff in particular right some of the The bugs and security reports come in through different intakes. They might come in through like an ethereum wide intake And so the basic community might not have control over where the cve, you know, or over who handles the cve So the um Thanks heart and and and for the continuing on the same topic, right? So At the foundation level Do you think we need to have a Let's say a sync with A team on this on the github in case we choose that as a preferred partner For issuing all the cvs And have that access with them in case something needs to be a detail or updated like At the foundation level No, I mean, I think that already basically works, right? I don't think there's anything that we need to do with that Right. So as I understand some of these Some of the times when the cve is created like the creator has access to it and then the creator sets the policy And we as the foundation we get very little to be involved over there in case we want to moderate any of those From publicly getting disclosed Until some point in time let's say let's say somebody reports an issue and We set our guidelines saying that hey, give us 90 days of time and then we Will come back to this will make sure this issue gets fixed or will address your concerns as soon as possible But it's at the best effort of us, right? And we do not really have control over whether that If it's really critical and then if it in case it gets disclosed in public forum Yeah, I mean we no one can really do anything right if you're If your vulnerabilities are publicly disclosed by the finder right I mean, that's that's just sort of a you do You're best with what you can right? You want to encourage those people not to do that, but you know if they do there's nothing really you can do about it Any other thoughts and comments on that? so yeah, Peter Yeah, I just agree with heart. We don't control Who does the disclosure if if they do disclose it? I don't know how often does it happen that security researchers don't hold to that standard 60 or 90 days of grace period, but If if we just get unlucky and someone finds something who you just not care about that for whatever reason then There's just basically nothing we can do about that Hey, Peter Hey, so in the proposal, I'll put that We do prefer GitHub But in case you are disclosing and through other means or through other authorities, we still welcome that That's good Okay, the next point that I wanted to bring up is With respect to the embargo list So this is the list of people who would Who'd be given early access to the vulnerabilities that are reported? and the open SSF recommendation is that for For those projects which are widely adopted which which would affect a wide range of users Which we already know of at least for those projects. We strongly recommend having the embargo list Where the service providers are informed. Let's say somebody is providing Managed blockchain as an offering to other partners And then whoever is using their platform would be impacted if this vulnerability gets disclosed So the open SSF recommendation is to work with those vendors or those partners Make sure they are given early access and they are informed about this vulnerability But it does come with certain risks associated for instance This may be considered considered as A thing where let's say a foundation is giving preference to certain organizations or others Or maybe it may be perceived as The Early access embargo list those people may have Since since everybody else is under the They do know about the process. They understand the risks associated with Disclosure in public forum But the embargo list can sometimes grow very big and if there is possibility that the information that is Shared across may publicly be visible sooner than what we expect it to be So it's like more people knowing the secret relate to Much more of them knowing about it And the other risks associated with it are the Let's say once the issue is identified and we eventually found out that The fix for it may take longer time or maybe The Like the consumers they are already be Like exposed to that vulnerability Now the embargo list Has have little to do and they may be at a risk and they may Have a bad impression of the project itself which they are providing as a service Right. So there is risk associated with it In multiple ways So any thoughts on the embargo list itself or any of these risks that are associated with it I know we can we can actually reference some of the projects that we have and Correlate them. I know some of the some of the projects that are widely adopted could be for instance Aries fabric and basal Right So, yeah, I really second to ruin's point here Um, I'd be curious what people here thought about embargo lists In my experience, um And this isn't a different life they typically work pretty well because we are all on the same page but, um There Someone can break the embargo When the change goes in a lot of smart people are going to diff every change and see if there's anything Uh exploitable there you can just look at like the windows updates when they come out they're reverse engineered in hours So I I think it's worth having um But you have to realize that people have different desires and they're going to do what they're going to do absolutely Um, so it's maintainers on here. What do you think about embargo lists? Dave Yeah, I definitely think giving vendors early access to a disclosure is a good idea I think the benefits outweigh the risks is is that what an embargo list is basically Yeah, basically you just have a list of people that you know that use your project at some level, right and you basically uh You know typically you would nebulously notify them of that, you know, like this is a There's a huge bug coming up be ready to update or something like that, right or you know, you can say There's not necessarily a lot of consistency in what you tell people early But it's just generally you tell them early. There's a security vulnerability to be prepared Yeah, my my opinion is the benefits outweigh the risks Awesome. Okay. Does anybody else have thoughts on this? Peter I agree But I will also say that me personally I will only add people that list whom I know Uh, it leads to some extent because I would be very that Someone just spooves the identity of some company and they get on the embargo list actually to get, uh The information that they need to then exploit the vulnerabilities So it would have to be somehow verify then The only thing I can think of right now is that if I if I've met you then I can add you to the embargo list. Otherwise, uh No But I know that's a little bit on the paranoid end of things I don't think that's too paranoid. That's usually the strategy that a lot of big companies take Oh Okay Yeah, okay, then I I support it and this would be my personal preference of actually handling who gets on Thanks, Peter. Hi, Steve. Um, so would the Would the mechanism for implementing such a thing be simply that that is the that is the set of people invited to see the security Um issue on github is that no way you would implement that? No, this would be like an email list or something Uh, generally, you're probably not going to share the full security issue um So you're you're probably going to share some information with these folks but not complete information So we either we as a tuc or the project teams we can recommend projects to come up with lists of templates for instance if anything So as part of the vulnerability disclosure, right? So when the issue gets reported I'm sure like before it is considered as a security risk Somebody must have analyzed it and they would know the severity of of that issue And uh, when a cv gets assigned, I think it's that's that's the time when we disclose this information to embargo list And um, it could be a total level we as a tuc can recommend a list of templates And with minimum information that we would like all the embargo list to be known And then we can let project teams decide upon what additional information they would like to share about that issue Tracy Is the embargo list per project or is it per hyperledger? Right? So is it for the foundation? Or is it per project they get to decide who the embargo list is? Uh, I'll jump go ahead Arun and I'll go on heart. I just say it would get the project idea Yeah, me too. Um, I think it makes a lot of sense to do it on a project by project basis, right? If I'm not a fabric user, right? I don't really need to know Information on fabric security bugs, right? No, I think that's good, but I think we just have to be very specific there Um, I think that's the right answer It's just I wasn't getting that out of the conversation and I wanted to make sure that that was very specific in What we were documenting so, yeah, so I think the the goal is that We're documenting a template for each project to have right So each project is going to be able to customize a little bit And one of the big things that they will you know be able to customize obviously is who is is on their particular embargo list Stephen So how is an embargo list implemented? How does like is it a embargo dot md file in your repository or I just struggling with that part Yeah, so I mean in theory, it's just an email list. Uh, there may be some uh, privacy concerns so, um You know, it may end up being like a maintainer only thing Uh, but I think that's again up to the project. I think some projects people are going to be comfortable with that being public and some might not agree as I can hard some I think one of the risks that comes with embargo list is if let's say organization a knows about organization b and Like both of them have early access to the vulnerability. I don't know if the competition leads them to malpractice So we can give benefit of that doubt and Probably it's better to have that access Hidden or at least the information he done about who is part of the embargo list But we should disclose the information saying that there is an embargo list with all the major service providers and if you are not on that list to reach out to Let's say a contact person either from the project or at the foundation level so that we can we can add We can think of whether to consider you to that list When I say we um Intending to say either if it is something that we can determine at the OC level or at the project level Um, I saw Peter raising hand so Peter Oh, yeah, you and hard pretty much said everything I wanted to say I wouldn't mind having Uh, it documented that the list exists, but I would definitely not want It public who's on the list because then they could just become targets for spoofing and uh, all sorts of other things Yeah, if the list existed absolute the the existence of the list absolutely needs to be public, right? That's just best open source practices, but whether or not like You know, uh Whether the list itself is public is a whole other thing, right? You know if I find a bug and there's an embargo list public You know if I'm a black hat hacker well now I know what to do with my bug, right? um So, yeah So any other thoughts or comments on the embargo list before we put it in a proposal So just generally speaking I think, uh People are in favor of them embargo lists. Oh, do we want them to be? You know, do we still want them to be optional anybody? Peter my two my two cents is that they have to be Um, you know for some projects, I'm not sure who would even you know that I'm related to I don't even know who would be on that so Um, I don't think they can be required Yeah, well the general thing is uh People you you don't you know, you make people tell you so people are only on the list if they tell you they want to Be on the list so You know list participant discoveries not a not necessarily a big thing um, it's You know, that's on the people that's not on you. It's just a matter of whether you think the pro you know Can you handle like you know? It's does the like should we require projects to do this like extra step of notification? Basically And we could say it's optional You know, we could say, you know graduated projects have to have it You know, there there's there's lots of gradations here, right? No, no one's going to expect labs to have to have you know embargo lists, right Peter plus one for optional I ideally I would say this is a must have but If if what what we see in practice is that some projects struggle to To keep up with quarterly reports as well. So I think having just more mandatory burden Would not help Thanks Peter David Yeah, I would just use the word recommended I like that and that's going in the document draft. Thanks, Dave so The the connected question to that I think we kind of gave an indication that it should be project team who decides to who can go into embargo list Is that what we are also agreeing upon? just for confirmation And we provide a means for somebody to pitch in saying that they can be on the embargo list David I'd say it probably makes sense to have if we have two contacts per project That probably makes sense for those two to manage the embargo list. Does that make sense? Yeah, absolutely It's the security team that manages it Okay um, so the the openness of recommendation was that VMT the The vulnerability management team Would come into picture to decide who can go into embargo list But we could um, we could set up that The escalation procedure for somebody right so Let's say if I would like to be entrusted in the embargo list for a specific project I'll go to that project and ask them Hey, since we are the largest consumer of this project, please Keep me informed about anything That you would disclose and then if the project team doesn't agree then I can go to VMT and Request them that his I did request this but they did not approve. What do you think of it? Or maybe the next step could be company who see um, yeah, Tracy I feel like if the team says no um Then the team says no, right like if a project thinks that they shouldn't get it then um, there's a reason there and why why would we have The ability for somebody to to override the the project I don't know. I mean it doesn't seem to make sense to me, but there could be a reason that I'm not seeing Any thoughts from anybody? I cannot think of a reason And the only reason I can think of is that just the security team might not know the extent of who's using the project But I think this should be relatively easy to document Like you should be able to convince people that you're using the project, right? It makes sense to me hard. I think that if uh, if somebody's using the project you Should either know that right off the bat or they should be able to prove to you how they're using it And and I just um, guess I'm Saying that if they can't do that and the team says no then the team says no Right or the project says no, um, it just seems to make sense to me Thanks, so you see peter Yeah, if if they are a major user of the project then chances are you've Ran into them at a global forum or or a meet-up or anything else before Like sense All right, um, so moving on to the next part, I know we already may have some Something put up on this particular part of of the proposal. So this is related to The process itself. So so far we have been talking about having a VMT and then what their roles and responsibilities are and then how the scoring can be issued to a reported vulnerability And who gets early access to all of this But now all of this information are are um They are like the process that we have to follow our maintainers have to follow the what's not Publicly visible is the process that will be followed When the issue is reported. Let's say if I'm a security researcher. I come here. I identify an issue What's the next thing that's going to happen when I report an issue? I have no visibility into that, right? So most of these discussions do happen among the maintainers and the reporter But um, I would like to know what would happen in let's say five days of time, maybe 10 days of time Maybe um, like what's the next thing who will be informed about this? What should I do later? at let's say at the 90 90th day, right? Um, so this process, I know there is a confluence page. I don't have the link handy, but we do have uh, that information mentioned somewhere Maybe what we can do in addition to that is put a link to that confluence in all of our security md file and say Tell it to somebody who's coming and reporting a security issue that hey in case your issue gets, um accepted as a cve With the at the scores and this is the process that we follow and here's the link to that process and expect to Um, I mean expect us to do these activities at this point in time And then do reach out if in case you feel it's not going to ask for schedule, right? Um, I don't have the link handy. Sorry for that. I wish I had my laptop with me, but I'm not sure if you have the link handy to share it I Which link are you talking about the security response link? right So the recommendation is to put link to I mean that link in each repository security md file if we already don't have it in it So that the reporter would know the process that is involved Right. So I was referring to the security bug handling process that is listed over here Yeah, we can we can make that public and we can probably also clean that up a little bit It it is this is public. Um, it's it is hard to find It Should be linked in Most of the security md files I was looking at this for some other reason Um, and I think that like fabric had it Yeah, we definitely linked to it this this might also be a chance to This this document might live in the uh In the governance repo. Yeah, that's my that is the point. I think Okay, so I'm fine with that Okay, I think all of this I think we should have probably a a sub repo Uh for security in the governance repo, but I'm not sure what you mean. Just let a sub folder for security polishes Make one Okay file pr. I'll merge it Are we saying Sorry, I didn't get that. Are you suggesting that we create a repository and maintain list of all the security related policies? Yeah, so I'm just suggesting that like this If you're coming from the TOC website, this kind of stuff is hard to find right now So I'm just suggesting that we move some of this stuff to the project governance Folder And yeah, we we don't have to do this today, but in general do people feel okay with this Yes Yeah, no reason to do So, I think I think moving it to github is fine. I guess the question is does it Does it fall under hyperledger governance or does it fall under hyperledger TOC? TOC right Sure I I was speaking of governance earlier because it was on my mind I don't have a feeling about it. It's a TOC policy. So Let's go there Cool I know we only have a couple minutes left But there are a couple other security things that I wanted to pull people about If that's okay and just get some general thoughts Sure, yeah I don't think so I can bring up two other points that I had in my notes. They're longer discussion items Go ahead. No, no, but bring them up. They go ahead No, let's go with the ones that you have because these may take longer time It's fine. We should just bring them up anyway if they're going to take a longer time So so please So I wanted to review as part of this task force the current process that we have And make sure that we cover at least these seven points that I have noted down Those corresponds to the acknowledgement to every issue that is reported I know many of the times there is a possibility that as a reporter I May I may be in a and I may be motivated to report a security bug and reporting that it has a normal issue Right a normal bug So, um, it is important that we acknowledge each of the issue that is reported and the onus is on the VMT Uh representatives of that project Or at least identify somebody else who can be who can respond to these Or at least acknowledge saying that we have received your request And in case I mean whether it's accepted as a vulnerability or it's just an issue It's important that we inform it to the Somebody who has disclosed it and if the project team decides that it's a It's an it's just an issue that can be disclosed publicly without withholding any additional information And it's it's fine to be disclosed in open forum. They should be able to Just create an issue out of it and then say hey now we have considered this as an issue And we'll fix it based on the priority of the project right And um, yeah the acknowledgement and the response Back to the reporter. It's very critical And it should be done irrespective of how many issues are being reported And um, it's also important that we cover the embargo list information with that is With the person who is disclosing the issue or who is creating the issue so that they know about The additional people being informed about it, right? And there may be negotiation period or Negotiation that could happen with the person who is disclosing If they do not wish And so we should make this as an optional right for them If I as a reporter I do not want embargo lists to be notified about the issue Then it should not be So the the whether to be disclosed to embargo list or not as should be given as a choice to the person who's disclosing it And um, we should also make sure that we do inform the person who's disclosing about the patch information when it comes up and um I mean we we can work with the person who's disclosing to get them a cv number assigned to the issue Um Right so and then we can also work with them for the release date, but it's not mandatory Uh that we need their approvals, but it's good to be it's good to inform them about the release in which The issue will be um fixed And finally we need to work with the person who's disclosing A date um on which they can publicly Disclose that information I want to make sure that we captured these points in our list the security bug handling process Right so hard. I think that may require us to probably go through each of these points and then see which of this is missing Yeah, we can go through these point by point Um, I also had questions. Um Is anyone using or or well I should ask what are people's thoughts on? private patch development infrastructure If anyone wanted to share on that And then I also wanted to solicit feedback on what people thought about github security advisories I know we have two minutes left. So if anyone wants to get in a quick Sinister to that'd be great or otherwise we can table this for a future time Tracy What what is private patch Disclosure infrastructure Development infrastructure Yeah, what is that? Uh, so it's basically just a private fork Develop, you know used to develop security bug fixes, right? So most of the time when you do open source development You do it out in the open But if you're fixing a critical security bug, you might want to do it with a very limited visibility, right? So that's all that what that is. So that's how it's done with github When you create a security, uh Vulnerability it creates a private repo that the researchers added to So that's that's the way it works right now on github That sounds like a good thing So basically I'm just curious if uh If everyone is happy with that and we should just tell people to use that Just do it in github How does it actually work logistically because eventually it has to get into your main branch for To release from right? Yeah, so once once the uh code is merged The The repo where the development was done gets deleted So if you want David, uh, when we're not on a recorded call I can show you some stuff that's under development some security vulnerabilities are under development and I'll show you how it works logistically Hey I think it makes sense in theory as long as the logistics work out. Okay. Yep Peter It's a plus one from me Uh, I think we should also use the word recommend it here if someone has their own thing for whatever reason If they actually want to put in the work to to create their own Environment for this then they should be able to But uh, but also we should definitely help people by saying Yes, we recommend the the feature that github has because it's convenient Okay Thanks, and then your last question on security advisories. I'd like it. Is there anything not to like about it? in github Uh, well, I mean, I was asking you all that I've had good experiences with it I just wanted to make sure that I my opinion was not out of line with everyone else's I think it's better to bring this topic again in the next week And I know we are on top of our top of the are but one more last item I want to also bring up and maybe people can think through until the next week is We um, we need a way to monitor these Whether like all the projects are following the process set up for the security and this becomes very critical for From a governance standpoint So we need to think of a mechanism to govern these things And I know most of these we cannot just ask them to be Ask them to report it in the quarterly reports, but we need to find out the mechanism Or come up with a mechanism So, uh, how about we have a checklist and uh, we uh one moment So how about we implement an actual checklist and everyone reports something like a quarterly report So we can integrate all this information Into some page and actually check what is done and in which comments it was done Let's take this up in next week's discussion But yeah point considers All right, so thanks everybody for the discussion today, uh, we will be meeting again next week. So until then Thanks a lot