 There we go. All right. Welcome to the November 18 technical center and can we call. Just to start with obviously the antitrust policy notice that everybody on this call has seen many, many times, since we don't have any guests. Just know that you should comply with that as well as the code of conduct that is linked to from the agenda. So get started with the announcements. As always, the devil weekly newsletter goes out each Friday. So if you have anything that you'd like to add to that, please consider doing that today and get it into the the next step weekly newsletter. Also, as a reminder, we won't be meeting next week due to the US Thanksgiving holidays. So we've canceled next week's meeting. And then, yeah, anybody else have any announcements that they would like to make resounding silence says that nobody else has any announcements they'd like to make. All right, so we do have the three reports that have been on the agenda for a few weeks now. I haven't seen anything new added to any of those reports other than maybe just some discussions that have been kind of back and forth with the with the submitters. So I don't think there's any outstanding questions but I do want to give people the opportunity that if there is any outstanding questions that they'd like to ask they bring it up now. Again, resounding silence says that everybody's happy. We'll let those three fall off. So this week, we will, Dano has reached out already to Silas on the the borough report. So we will hopefully expect to see that soon. We do have expected in the next meeting that we have what we should have hopefully for new reports from grid transact cello and quilt coming up. Let's move on to the discussion. So the first item that I have on the list here is the security process proposal that Rai has put out. There has been some discussion on that but like to open the floor to have further discussion on this particular proposal. Oh no. Thank you. So, I mean admittedly I should have started this before I put a comment earlier today but given the time difference. You know I don't think anybody really had much chance to look at it but I mean essentially I on the proposal itself I think this is going the right direction. And what to do with the current documentation we have so right scroll down I put a link. Well you can kind of have it there too but in particular, you know, so we have it from that point of view I think you know we we can give ourselves some kudos on the fact that it's not like we've never done anything in this regard and so we actually have documentations with, you know, with regard to what how we handle security issues and, and even a fairly detailed process on how to respond, respond to, to linearly reports. But so the proposal doesn't say anything about, you know, the current documentations. Basically, the main change seems to be a we update the security MD file in all the repositories. And I'm, I think we also need to have a look at the defect response page. So I didn't do a thorough review of it but I looked at it to a certain degree. There are certain things that I noticed that you know where there's like the trip and see differences between what's being recommended now, and what we have. And just to name a few that I spotted going through kind of side by side or after rereading the guide. And how they suggest to do this. For instance, they say you should early on negotiate with the reporter on an embargo period, because some may not want to even respect any embargo. Some will be more tolerant and negotiate with you agree on, you know, giving you some time to try to address the problem before they make it public. And then there are things like when we, when we create a CV, the recommendation is to offer the reporter to be named to so that they can, they can be involved in the process creating the CD and be given credit if they choose to. And so I think these are like, you know, small details that I've seen and passing that I think we could definitely, you know, get more alignment to because I think alignment on, because I don't think that you know, there is any reason not to follow in a good way, basically. So. Thanks for now. Right. So you had your hand up. Did you want to comment or Sure, I did make. If you look at the history of the page I did make a couple edits to remove some of the stuff that was juris specific. But I agree, the rewriting of this page. And it's implied. It's not stated. I think this needs to be rewritten. And that's all I gotta say. All right, thanks for that. So to give some more weight to the need to rewrite some of this, let's say hypothetically, a maintainer finds a bug that was shipped and that is worthy of a CVE vulnerability. It doesn't really fit that well it's this process it's all focused on an external bugger for it doesn't answer key questions such as, who do they have it to disclose it to before it goes public. You know, what sort of oversight if you're going to make this would be needed or is there no oversight, if it's found within the main tanners and kept within the main tanners and fixed. And I think that's actually a weakness that, you know, if you find something that you feel it's worthy of the designation of a security bug. Reading through this you could have very keep it entirely internal and never tell anyone to just fix it and hope it goes away. I don't think that's a good thing. I think there should be some speaking about, you know, what, what level is relevant. You know, look below a certain level yeah it's de minimis it doesn't matter just just fix it. But above a certain level I think there needs to be some level of oversight and what is that well, it's probably going to be a fairly high level. You know, not just you know something that you know you could with the right, you know, compiler options you could break something that's not worth it but if it's going to result in chain splits. It's definitely worthy. So I think that's those are some things as we were right this we need to keep in mind. Nathan. I think that updating this is a really great idea. It also helps protect the community in case one of the partners in the ecosystem doesn't want something disclosed or wants to delay something being disclosed having a clear written policy. And that's just follow the policy and keep away from any controversy, especially where you know like the antitrust policy says we are a collection of competitors that are doing different things. I would also like to ask anyone from fabric, has hacker one been working out for you I mean, some of the other projects have done some hacker one, and hadn't really gotten a lot of valuable response I mean we got a lot of like things logged about, you know, on a public domain website, like your DNS settings, you know, stuff like that, not. We never really saw much substantive response on. Yeah, Nathan I had that same question on the hacker one. I think rye had responded in the notes that there has been some input from hacker one but maybe not number detailed as far as. What's out there. So, that was a concern that I had as well surrounding that proposal number two if you will, Dave. Yeah, so we've had probably I'd say a decent number of hacker one reports, most of them have been pretty minor things like people trying to take over the read the doc site things like that. I guess I think it's mostly people trying to cherry pick and find bounties easily. We haven't had anything too substantial reported most of them have been very minor things that we didn't think we needed to do CVE for but I think the process itself has worked out pretty well. Other other comments or thoughts on what's been proposed by rye. If not I feel like maybe where we're at is that we might need to put together a task force for some of these items for this, you know specifics around what it is that we're trying to accomplish with this. You know, I think more than anything it boils down to, what are we doing with the existing hacker one what are we doing with the existing kind of wiki pages that we have. I think this is the right process. And so, while I think all the proposals are good at a high level and do you think maybe it's a question of how do we get to the specifics and the detail behind it. And I just wanted to show this as this is a recent report from three days ago that came in to illustrate David's point that this is. This is actually a really good example of a valid report that in the end has no value. And it's valid what they're saying, but there's no change in fabric that's needed to to mitigate this. So, and if anyone on the TSC wants to be added to the hacker one program as an observer I will invite you. Just let me know. All right, do we have any volunteers and to run a task force on this. I can have a build on this. Okay. Anybody else interested in participating on the task force. Let Arun know, I guess, and get something set up to to run through and walk through the specifics. Are there any, any kind of comments or thoughts that people would like to add as a task force kicks off on this. Are there any concerns with the direction that this is headed. Anything that, you know, people would like to make sure that the task force really takes a little deeper into. I'll be happy to participate in the task force. I don't, I don't know if I is not said anything. Because he's, you know, he thinks does the stuff he doesn't need to volunteer but I think you'd be really good to have right on this because he has probably the most, you know, background on how things have been going so far. I'll be there. I figured that was that was implied. And there's, there's a ton that's that's not captured here that these are issues that have been kicking around the TSC for a long time. Like, we have, I think, two or three projects that have people on the security mailing list. That number is far too low. Right now we have a valid, what appears to me to be a valid report of an issue in a project from hacker one. Hacker one only covers fabric, but I'm not going to just delete the response I've been trying to get some of from that project to engage on hacker one. I can't get any response. And then we have another issue on the same project that was filed by a member of the community directly via email that I forwarded to the security list. And trying to get people to engage is like pulling teeth, pulling teeth is probably easier, honestly. So I think that is missing is like, what does the TSC want in terms of membership of the security, the security team, and what does the TSC expect I mean our outline on hacker one says we will respond within 72 hours or something I think we've missed every one of those deadlines. So, Nathan. I think that all sounds like well within the remit of what needs to be addressed I think refreshing the security mailing list membership is probably something we have to do much more frequently than we have. And I'm not sure if there's a way we can measure some of our response times. It feels like we have a few different places where we tell people response times are important on responding to issues on responding to emails and other things. I'm not sure the current LF analytics lets us measure that sort of a thing but that that's something that we might be able to help us know when we need to trigger, you know, adding or changing membership on some of these committees. Yeah, so I think in terms of you know engagement from the projects, we've got to be able to say look at least for a project that I've graduated, you must have one of your maintainers on this list on point, you know ready to respond if this concerns your project. I mean, if we can't enforce that we might as well go play something else. And I know the TSE doesn't have much power in practice but it seems to be. And for those who are not quite up to date on this and maybe I'm being more sensitive and easily because I'm not engaged in a in a peer project to the hyperledger within the next foundation called the open SSF which is where this guideline came from. And, but the issue of, you know, security and vulnerabilities regarding open source is becoming a major topic of discussion in the industry and around the world governments are taking a very serious look at this. So we've got to do our part. Yeah, definitely I think you know, as Nathan mentioned having this via remit of the task force makes some sense right as far as how do we ensure that we're going to get projects involvement how do we ensure that we're going to get the response times for the security issues. And I think all of those sorts of things fall into kind of the revamp of the security processes that we have in place for for hyperledger. All right, I see you brought this up. This is just FYI for us as far as the all time medium time to response meeting time to triage that sort of thing. Right, just the question was, like, we don't have, how do we get the statistics, we can get some of them from hacker one. We could get them out of Jira, but it's not easily available. And beyond that, I think we'd have to. We'd have to manually make some CSVs. How much. This hacker one report is specific to any hyperledger project or is cover all hyperledger projects. This covers all submissions to the hyperledger program. The only funded projects are fabric IBM. It's been a long time IBM directed funds to hacker one for this program through hyperledger. So hyperledger has funded this, or this program. We get reports from everything we get we get reports for every Linux foundation project. Okay, but like I suppose here a hyper here so like the high fabric in these are two or it cover all the projects right. This covers all submissions, the only ones that we pay out on our fabric. Okay, okay, okay. And, and this is publicly available or is a new need some credential to view this report. It's not yet publicly available I guess it could export the PDF and make that available. I'll see what I can do in order to make this. What I don't want to do is publish stuff that's in progress so give me an hour or so and I'll get a version of this, either on the wiki or on GitHub, one way or the other. Okay. And I don't know if this URL is publicly available. I don't know if you have to be authenticated to see that or if you have to, I don't, I don't know. But I will make it available I'll make the data available anyway. Yeah. Thank you. Alright, any further discussion on this before we move on to the next topic. So, I re added the inclusive naming proposal to this I wasn't sure whether or not the DCI working group have met the day after we last talked, and what the updates or status of that was so I did include it for us to get more information to see, see the outcome and see where we're at with this particular one so grace if you wouldn't mind. Just giving us an update on this. I didn't know she was going to be called on. So, just might be looking for her new button. She might not be able to come off it. Peter, were you at the call the DCI working group call. I was not at the last one. Sorry. It's okay. I was at the last DCI group call. Did you guys make any progress on this particular proposal from the discussion that we had in the last year. Not specifically on that one. We were talking about forming task forces within the DCI work group. But we haven't yet gotten to the proposal itself. The only announcement that I had as an update is that the same one that I gave a couple weeks ago maybe that I have finished the guide for the DCI tool so that there's now a step by step screencast type of deal where people can configure it on their project and pretty much just a few clicks. So we will include all into that in the proposal as well. And that was my update. So, it sounds like we haven't moved in from the discussion that we had last week on this particular item. So, if that's the case, I guess that was the end of the agenda. Was it not. Is there anything else that anybody would like to talk about or cover. So, at the risk of sounding a bit obsessed with security now. I just wanted to raise attention to another tool or another project that's being led by the OSSF, and it's called scorecard. We basically are working on developing a tool that allows that that provides a way to scan repositories. And with a whole bunch of different heuristics, they are trying to assess the level of, I mean the risk, you know, for vulnerabilities into a repo. It's an interesting tool that is very much in the works. But I encourage people to have a look and try it out against their repo. I started doing that. And I actually found the bug completely unrelated. It was interesting nevertheless. We had a shell script that had a syntax error in it, and that the program found out, but it's not really designed for this is just, it just, you know, showed up in the report. And in any case, I think this is the kind of tool that we will be called to use more and more to again improve the security overall of open source projects. So I encourage people to have a look. It's called scorecard. It's a small program. There are different. It comes in different forms. It's a go project to go lang. So you can just grab the source code and compile it but also there are different binaries available it comes as a Docker container. And it's a pretty simple setup. Just basically, you can run it locally in the machine just give it the URL of the GitHub repo and it will just speed out a report fairly quickly. And it's again, you know, it's by no means perfect. Nobody claims that it is, but they are working on trying to improve it over time. And it's better than nothing and they felt like, well, we've got to start somewhere. So let's do it. So, maybe add a link to the TSC chat on that particular tool so that people can take a look at it. Yeah, yeah, absolutely. I'll be happy to do that. All right, thanks. And then was that our room that was going to speak. Yeah, I was just curious, which language does this tool support so it's only for is it only for the goal and so it could be anything. No, no, no, no. Okay, they're trying to cover as many languages as possible. It does things like Python and then Java and C++ and, and again, I mean, it's very much work in progress so they are adding as we speak, right, more and more for all sorts of things. I'll put the link to the project in the TSC chat. And you can start looking at it and they get a sense of what it does. And it gives a score. That's interesting. It's not just black and yellow, you know, yeah, it actually tries to give a score with regard to different tips types of tests that they run. It gives you a level of, you know, confidence with regard to how good or bad you are doing. And I, I'll be honest, transparent. When I ran it against the fabric project, it gave us a score of less than five over 10, it was full point something which I'm like, okay, I hope we can improve because that doesn't look too good. Yeah, and one thing that I thought about was the not related to security but just that an update on the task force for the chat. We did have our first meeting yesterday. And it was quite, quite a good meeting where we talked about kind of requirements that people have for a chat system. We talked about things that we think are currently missing from our chat system we talked about things that are good with our chat system. I would encourage anyone who has some thoughts on, you know, things they like about what we currently have things they don't like about what we currently have with rocket chat to let the task force know there is a wiki page that has been created to start to capture that information. But you know if there's, if there's the opportunity that you have to, to discuss this with other people in the community and get their feedback as well. Please do that. I think that the task force is going to try and come to some of the project meetings and have a conversation with with people around what it is that they, they like what it is they don't like so. Thanks for bringing the wiki page up. This is the wiki page that is kind of the start of the discussion. We really focused in not on question zero but really on question nine with the requirements that that we think should exist and kind of who the audiences are for the different sorts of people who come to the chat. So, again, if you have any thoughts or would like to add to this this task force we are meeting again two weeks from yesterday. So two weeks from Wednesday which I don't know what the date is sometime in December I believe. So, feel free to check that out. I think the invite went out to the TSE mailing list so there should be a great opportunity to come to and join that particular task force. Anything else that anybody would like to bring up or discuss. Before I let you have some time. I'm very quiet group today. All right, well if there are no other comments, then I will let you go. For those in the US enjoy the holiday next week. Everyone, we will see you in two weeks. Thank you. Sounds good. Thank you. Bye.