 Right. Welcome everyone to the July 28th hyperledger technical steering committee call. As you are all aware of two things that we must divide by. The first is the antitrust policy notice that is displayed on the screen. And the second is our code of conduct. So as we move down the agenda, we have our standard announcement. The dev weekly developer newsletter. I'm doing this from memory. It goes out each Friday. If you have something that you would like to add to that, please consider clicking on the link. And there's a wiki page where you can add your comments. If somebody wouldn't mind whoever sharing their screens going down on the agenda. Thank you so much. Any other announcements that anybody has. So Julian Gordon VP for Asia Pacific type of leisure is currently visiting India. And there are a couple of events planned. So he's in India for a week now. And this Saturday there is a public meetup event in Bangalore. So if anybody is around or if you know somebody in Bangalore, please let them know about the event. And yeah, it will be an in person event. Thanks for sharing. Anybody else have any announcements. Okay. There's no other announcements we did get in the hyper ledger saw to quarterly report. There was a slight glitch with our project calendar reporting. It was supposed to be saw to it's not transacted last week we had transact on the list but it was supposed to be saw to it's she got the reminder for such is not the reminder for transact looking at the calendar. I did see that those two got reversed for some reason in this quarter. So I fixed that we didn't get the sautees report please take the time to review it. I didn't see any additional comments coming through other than the ones I made but does anybody have any comments on the sautees report. Okay, I know a lot of us haven't had the opportunity to review that yet. Since it did just come in yesterday. Please take the opportunity to review that I will leave it on the on the meeting agenda for next week in case anything comes up that we need to discuss. Next week we have coming to the hyper ledger areas and the hyper ledger indie reports. So if you know anybody in those projects. Please feel free to remind them that they have that coming do with that. As far as I know we don't have any TSC business to discuss this week but does anybody have anything that we should be bringing up to discuss. Sure Tracy I think I pasted similar comments on the TSC group as well sometime back and taste back to what kind of project should we attract and what should we do to get those projects incubated and the hyper ledger labs or hyper ledgers. How do we invite those collaboration. And I don't know maybe we can open it up for comments and then if not now at least sometime in future. And does this relate or do you think to the project gaps. Task force that they know has been leading or is this something else. I think we can consider them as part of the task force as well. And I think the task force is aimed at identifying the gaps but does it also aim at how do we collaborate or bring in those those kind of projects or how do we start those projects. I when I put the objectives out I think the collaboration and the bringing in is the next step. So yeah, I think it does feed from the task force. The project gaps task force results. But I think it would be a separate task force action more than a task force and ongoing thing. To outreach to projects we think that would be positive for hyper ledger. So I think it's shrimp stems from but I don't think we should limit it to the task force activities. Thanks. And a room do are there certain projects that you think would be worthwhile to approach at this point. And that's why this is coming to your mind. I see a need for using some of those projects so that's where the need comes from. And if such thing does not exist anywhere and if others are also willing to show an interest, then that could be an initiation of how we take that forward right. It's a way to find similar if many people have similar interest, maybe that could be an initiation. So yeah I was just hoping for those kind of discussions to happen at some point. Okay, I think I think two things are one, you know, obviously after the project gaps task force we can talk through projects that might get the gaps that we discover right during that task force. And then secondly, let's see what we can do if you have certain projects you already have in mind to get that list together so that we can have a more focused sort of conversation. So, with that any other discussion items before we move on to the security task force right seeing a coffee, which says I'm away on the screen here. So a room and I think you're supposed to be driving us through the security task force today. I'm hoping you're not really away. All right, sounds like maybe he is is there anybody else on the screen task force you might be able to let us know current status and what we're discussing today. All right, looks like maybe a room your back. It's we see. I'm sorry, I got disturbed. It was an emergency call. What was the topic I missed probably. Yeah, so I think we're at the point where we're ready to go through the security task force. Right. So in the from the previous call that we had at the TSE. I think one of the feedback that we strongly received was that these recommendations are fine but what are we doing about. I think I'm sharing the right screen. Seeing a black screen with the line down the middle. Same thing. It says my screen is passed. It's asking me to resume, but when I click on resume, nothing happens. Is there a is there a wiki page or something that I should share. Sure. That's the task force recommendation page. Right. So one of the strong feedback that we received in previous previous TSE call was that we needed concrete proposals and not recommendations. And we needed plan of actions that as a TSE we can ask projects to start implementing. And since then we got to meet for once and next August 2nd we have the next meeting. But if you scroll down to the bottom, I think in the previous call we were trying to come up with a concrete proposal for one of the item, one of the action item. And so the first point I'll probably skip that every project to have a security representative. I guess we already added that in our requirement project requirement for any project to even incubate we need that as a requirement. And the second point that is put up over here in terms of concrete proposal. This is related to addressing CVS on a timely fashion. And the recommendation over here is we definitely don't want to be pushy for all the CVS but at least for the critical ones and the definition of criticality goes with the score that associated with it. So at least for the ones that are highly highly coming up, which are more critical, which are easy to discover. And these are the factors that will determine if a CV is critical and to be objective onto it. It's it's it can be considered as anything that is that is having a score of greater than 0.7. And and the proposals are in the goals over here is to avoid any such things being left out without fixing them for a long time. And we can we treat them as a highly exploitable ones that are to be addressed so much. So the proposal is that every project will be issued with a best practice badge. I know Tracy you had a comment on that, but I'll probably just complete this and then we'll go with the questions. So the proposal is to have a best practice badge issued to all the projects. And this badge will be issued on a on a merit basis. And this will be reviewed or reconsidered every quarter based on the project's report that they fill up to the TSE. And when a particular project is incubated, this badge will be awarded to it on on the basis that it is incubated. And the badge will remain with the project as long as they retain the status to see status of it. In case if the project is is is not maintaining the conditions which are said further, then the badge will be revoked. And if about badges revoked, then the project has to prove that they are following the process again, and they have to prove it for two consecutive quarters, following that revocation. So that was the intention. So there is no punitive measures over here. It's all about having that extra batch that gives the confidence to the consumer of that particular project saying that hey, this project is pretty much active in considering at least fixing the critical vulnerabilities, right? Ideally, we would like to have all of those to be fixed. And in two, in order to support this, in our quarterly reports will introduce a question that clearly states that if your, I mean, if a particular project has any critical vulnerability with the score of over here it is assumed to be seven and again that's open for debate. We can always revise it to another number. So we will ask the question if the score, if they have any CVs that are not fixed for more than 90 days. And if as what, which are those, and this is on the premise that after 90 days, all the CVs will be made available public. Of course, there will be consent taken from the project and project team has to give an explanation for why it should not be reported. So that's an exception process. Then, right, so the next point actually talks about that extension process and how long such extension can be allowed. So two such extensions can be given but not more than that. And this entire process itself will take the CV to be more to be to be active for more than like close to three quarters, right? So that's the next point. And the last point I decided deals with the revocation and the rules for again gaining back the batch to be to be on the normal list. So this was the only concrete proposal that we were able to put up after that call and the next call is on second. I think I see nano Tracy and hard raising hands. So one of the things to consider in this is that we don't hold all the cards when it comes to see the reporting. Whoever proposes CVE they're engaging in a responsible disclosure in agreement that they won't disclose it. After certain reasonable time and 90 days is a pretty standard thing unless there's negotiation. But you know these might be researchers and after 90 days you might say I need to publish a paper. And unless it's going to burn down the internet, I'm going to publish it. So I mean, we can, you know, how these rules said to delay publishing the CVE is that sometimes the project or hyper ledger is not in control of when the CVE gets disclosed. So that's that's one, one aspect to consider in this is we can use all the characteristics we want but we don't control the destiny on it sometimes. Okay, thanks for that input. Hey, Tracy. Yeah, so I actually have three points. Maybe we'll start with the second one since it kind of relates to what Dan just said. You know, I think in here, you mentioned that if yes please list the CVE is I think that is a no no. So from the perspective of if it truly is a CVE and it hasn't been fixed yet should we really be reporting it out and to a document that is publicly available to anyone. My second point here is, I don't know what a score greater than or equal to seven actually mean so for those of us who are not familiar with that maybe we need to be more specific about what it is that seven reflects. I think that's a very much a magic number in my mind. And then the last point that I have is the one that I made in the comments which is, I feel like a badge given to a project that's never had a CVE that says this project is following the best practices within the CVEs is not accurate. Right. I would prefer that if we do this we have like a never had a CVE type badge and a yes this project has dealt with all their CVEs within the whatever this 90 day period might look like right or within the time frame that has been agreed with whoever the report it was so I think, you know, there's, there's some challenges with claiming you are good at something that you've never done. And then also when you restore the badge. After they've resolved that particular CVE I think it's not quite right either, because we still don't know that they're good at dealing with CVEs within the amount of time that have been specified so I just feel like we need to be a bit more robust in how we're issuing these badges and when we're revoking these badges and when we're re issuing the badges. Thanks Tracy. I should like answer, I'll probably go with the round robin fashion. Hey, thanks. Yeah, great points. Tracy and Dano. I do want to, it wasn't clear to me whether we were still by default releasing CVEs after 90 days. I think, you know, the automatic release without petition to the TSC is a good thing. As Dano points out, you know, a lot of CVEs are found by researchers and other people that that have incentives to release them. In particular, we've even seen some CVEs brought by competitors that have, you know, lots of financial incentives to release CVEs on hyperledger stuff so you can guarantee that they're going to get released. You know, as soon as the minimum window is, you know, is reached. So, you know, I think by default, you know, we should be releasing CVEs after 90 days. You know, and I also wonder, you know, about the scoring. You know, the scoring is always a little bit subjective. So I'd worry that that could be gained a little bit. You know, so if this were, you know, totally up to me, I would just say, let's release all CVEs in 90 days. You know, sort of no matter what happens, you know, unless people ask for a TSC and if something is very minor, you know, well, maybe you can release it if it's not totally fixed, right? But, you know, that sort of addresses the point here, which is we want people addressing, you know, high severity CVEs, you know, but we should also be transparent about the less severe CVEs. So, so I'd prefer like a mandatory release policy. Because I think in practice, we're going to have to pretty much do that anyway. And there's no reason to hold these back. I'd be curious to hear what everyone thinks about that. Thanks for it. Yes, hi guys. And I apologize. I missed the call. The task force. I since in the reschedule, I don't have it on my agenda. I need to fix this. I actually meant to attend. But so my point on this is that in fact, a bit of follow up to what Dano and Hal said, the, I mean the open SSF recommendation is that you should try to engage with the reporter and try to translate the time frame for the disclosure. And as you know, hot and then said, I mean, they may have their own, you know, timeline, and the experience shows that in fact they are not always nice players. You know, it might be because there is competitive incentives, but there may be all sorts of reasons why people don't necessarily want to respect, you know, to give you enough time to fix the issue. And that's the reality we're dealing with. It's to the point where open SSF is actually now planning on developing a guide for, for reporters, and it's well understood that they may ignore it, of course, but the thought is that maybe if you know, we give them an insight as it's like to be on the other side, they might be more amenable to negotiating rather than forcing their own schedule on on the project, which sometimes can be quite challenging, right? You have to figure out whether this is real, you have to be able to reproduce it, you have to figure out the fix. And this may even with all good intentions from the project, it may still quite, you know, take quite some time. And so I think it's important here to take that into account. And I agree with Daniel that, you know, just saying, oh, 90 days. Well, in some cases, they may be, you know, agreeable to making it longer if, you know, it's a really hard problem to solve. And they might accept to give you more time. And other cases they may just say, well, screw you. I'm going to release it next week. And you just have to live with it. So I think that the, I think our policy needs to reflect that, you know, this is not casting stone and it is dependent on the reporter and their willingness to negotiate or not. Thanks so much. That was a, that was an option we did not know about. Thanks for that. Hey, try. Hey, so just a few thoughts. I think the first thought is, you know, part of this proposal sounds a little bit like information gathering and better transparency. Another part is this the badge concept. And, you know, I'm curious, you know, I'm curious, you know, if the badge part is, is an important aspect of this or just the idea that there should be some easily discoverable information about the CB stats for project. I think, you know, maybe if maybe if the focus was on on the more the transparency aspect and not so concerned about, you know, rule setting about badging that might be easier to get started. The other thought is about, you know, projects like areas that have less and more mature sub projects within them. A badging exercise like this might be fairly difficult, right, whereas, you know, stats gathering would probably be easier. So those are my thoughts here. Okay, I think we have so many questions to discuss and debate about so I'll probably start with you try. So the intention is not to have a badge, but intention is to have it easily consumable and probably incentivize projects to do their best so that the consumers of that project, they feel confident about the project. Right, so that's the intention behind it. So by just probably the easily conveyable an idea for somebody who's just looking into project and they want to know, hey, can I trust this project or is the project maintained to the standards that we expect. And if there are other recommendations apart from badging, then this will come those as well. And probably this ties back to the idea that Tracy was talking about that we may not be good with single type of badge. Because of certain reasons that in a project is incubated they have not done any best practices, it's just that they're starting to work in an open source community. So they may not be, they may not have exposed to certain scenarios which other projects might have already been exposed. Maybe like all their maintenance are occupied doing something else. So I completely agree on that aspect. So if not a best practice in terms of CVE, we can always say that the project is good for last two quarters right in terms of how they are managing their CVEs. So that can be a badge. And that badge definition can go by saying that the project is in good shape for the last two quarters and it's given through these reports and other means and either it had no CVEs reported or it's following its best to address them. So that can be the badge. I mean, again, it can be a badge or it can be any other means of conveying that message. And to another point that spoke about extensions and the minimum, I mean, disclosing it after minimum number of days that are, that's an interesting aspect. And also, I guess that ties back to what are not said in terms of negotiating with the person who has raised that was issued that CVE, right? So I have added that as a comment in the notes. I think the page is not in edit mode. That's why it's not showing up, but we will discuss that in the task force call to see if we need to do anything for now. I think disclosing that after 90 days without having any extensions, because some of them, as you said, it's not in our control. It makes sense. And we can put that up. And I'm not sure if projects would be happy to do it though. At least from a process point of view, we can state that. And did I miss any point? Just from my point, projects like Aries, which are more client frameworks and not blockchains, have multiple projects within them. So these proposals tend maybe not to address that issue that something like Aries may have a very, very fresh sub project versus, you know, a more long running sub project. And it's fairly difficult to have this global rule just for like say something like Aries across the board. I agree. So each repository or each project within Aries is considered as independent one, like that's what you mean. There's like several different frameworks of completely different containers, right? So it's more challenging with that kind of framework project than like say the blockchain projects to have a kind of a global scope like this. Okay. Hey Art. Yeah, I mean, Troy's point makes sense, but there's no reason we couldn't do this sub project by sub project, right? You know, ultimately we still want to, you know, indicate to folks like, you know, whether people are following best security practices or not. And if it, you know, if we need to do it sort of like repo by repo or sub project by sub project, you know, I don't see why that would be an issue. Would that satisfy some of your concerns, Troy? Yeah, I mean, I guess we have to start identifying that a little bit better. But I mean, I think part of my point was just, you know, I think the information transparency thing is easier than, you know, trying to trying to adjudicate badging is just a personal thought as well. So, yeah, it totally agree with you. I would agree with the repo transparency thing doesn't go away with this. I wonder if maybe there's something that would actually help general project discovery if we have the maintainers group repositories and say, these things are all part of one whole. And these things are all each kind of standalone, maybe because they're different implementations of the same protocol or because they're maybe different plugins that are on the sit on top of the core and so vulnerability and one doesn't necessarily reflect on the others. It feels like that organization and that making that hierarchy more visible would help with both the badging and in making the project more approachable. Right. I think going by that right so if. So, for the things which we use as a library as a dependency sometimes we see that, hey, this particular framework has an issue but only in this programming language or so right. One consideration, but again, your question is how do we show that how do we showcase that to consumers point taken. I think I'd like to really highlight and dig in on choice suggestion because I think it's not not going through and so maybe we can state it a different way, which is focus on the data first. Right. What is the data that you want to collect about CBEs and that data is CBE name date reported, maybe the person who reported it the date that it was resolved, which would then allow you to calculate you know how many days was passed, whether it was within the agreed upon days to resolve right so maybe that's an initial sort of capture my point of data that you capture. Right. Once you get all these points of data that you want to capture about a CBE, then you can decide what type of badges right and maybe it's, you know, here's a couple of SQL statements or whatever you want to call to say like, this is the data that you would need to see what the average amount of time it was to resolve CBEs for this project this repo this whatever it is that we're talking about right. This is the, you know, number of times that the CBE was resolved within the agreed upon timeframe. So all of these sorts of data is available then to you after you get that data collected. And from there you can decide what the badges are so let's, I think Troy suggestion is really good and so I want to see if we can focus instead of on badges. What is the data that we need in order to determine whether or not a project is doing good resolving their CBEs. Troy excellent point makes sense. We need to figure out what kind of data we can collect. I think all the data points that you said should be able, we should be able to get those. And I guess I missed one other point. I think you wanted to understand how did we come up with the score seven and what does that really indicate. So score seven as you said for now is a magical number so we just considered that anything greater than seven to be critical. But again we can change it right so that was that was a proposal. I had that in mind when when writing this proposal. And I think right sharing the screen. And whenever somebody reports an issue. They will have to fill through our answer list of questions. And so it's a preset list of questions in the sense that we have to know, like how much of a weightage am I giving for each of these aspects of that issue. And on what a particular reporter is saying we that the calculators like it determines the score of that particular CV. And once it gets reported and probably while talking to them and we can, like, there can be a process which which is established which which where a particular maintain or somebody can go there and talk to them and tell them hey, I see that you have considered this particular aspect of the high, but for from from our definitions, because we assume certain things in the project. Our security threat model does not consider these cases. So that's where we don't think this is high. So we, we will change this to let's say another value. And that can reduce the score as well. So this score gets calculated through this questionnaire that somebody answers. And one of the recommendation that the task force also had pause. Since we are dealing with blockchain technology and multi party systems, if needed, we will bring in additional set of questions into this to have to have influence on the score that gets calculated. Those additional set of questions could be very specific to blockchain technology. And this at least should work for the core protocol projects that we have about six of them in my pleasure. Again, that's not imposed on all the projects and the hyper ledgers. It's specifically for those. I also want to, I was showing earlier for fabric. We have this public dashboard. It shows the number of reports, our policy, et cetera. And you can dig into this and see how many CVs, et cetera. So there's more clicking you can do I will post a link to this in the discord chat. And scoring. I mean, looking at the site, it's github.com is this something that is built into GitHub. And if so, how would we go about making those changes that you're suggesting a room about, you know, if there's blockchain specific types of things that would need to be added. I can answer the first part. This, this is built into GitHub. What I did for this was I started draft security advisory on the governance repo. And just started answering these questions. And once once you get a score here, you can go in here and set this yourself. If you want, I'll give you a walk through at a later date. Right. I see art also raise. Yeah, I would also take a lot of the CV scores the big grain of salt. So for instance, if you have a bug bounty program. You know, everyone wants to extract more money from the program so they generally we see that people try to inflate their scores when possible. And that's one thing. On the other hand, if it's like someone from a project reporting a CV, sometimes they will tend to underreport it. So, you know, we should be careful with the CV scores, particularly for for the bug bounty programs and CVs that are that come through that way. I will say that I spend a lot of time closing basically bogus reports on hacker one. So heart's point about overinflated is. Yes, very much so. I think one other question that you had Tracy was when we have our own set of questions. How do we consider them and here right so that aspect is not exploded. Do you want to see on the screen. Sorry, I think the other question that Tracy had was, and when we bring in our own set of questions, which are other than the one that we saw on the GitHub page. How do we consider those in the scoring criteria. I think that's an open question. So, I would require request the TSC and also the maintainers of all the projects to join in the next security task force meeting on Tuesday. Because that's really the time where we dig some of these questions into deeper and we we do discuss a lot of lot many things. And the summary over here captures. It's probably a gist of what happened in the call. But there's a lot that goes into those calls. Okay. Is there anything else everyone or anybody on the screen task force would like to cover today. I will take that as no. So I guess we will say that we are complete for today. Next week. Bobby will be presenting some of the work that they've been doing in the learning materials working group to come up with some guidelines around documentation. They had a task force going on there. So we'll let Bobby and the team present that to us next week. If there's any other items that people think we should discuss as a TSC, please let me know and we will make sure to get that on the agenda as well. And with that, I will close out the meeting for today. Thank you all for attending. Thank you.