 Cool Okay, so just a quick reminder to everyone Beijing Hackfest is going to be in about a week and a half June 19th and 20th This is in tandem with the LC3 event happening in Beijing where we will also have a blockchain track Great news. We have already hit a hundred registrations as of yesterday. I believe will be Above that today. So really really excited to see the engagement and interest there Brian it sounded like you were on do you want to just give a quick one minute? Just kind of how we're approaching this and anything that the community can do to help and kind of how the TWGC is engaging in this Yeah, exactly what looks like, you know, we will have some corporate core Maintain our presence there But largely it'll be new developers to the community And so I think we'll skew a bit more towards the kind of introductory kind of talks and and you know Getting helping people get up to speed on a you know developer environment and that sort of thing And and I'll try to lead a session as well on participating in open-source communities The technical working group China has also been engaged in both taking on leadership of sessions and And recruiting as well for the event. So that's been really good to see And yeah, I'm really excited. This will be a great opportunity to bring developers on if folks Just want to watch, you know, the mailing list because there might be or the pull request streams because there might be a higher than average number of Requests or questions coming in That would be that'd probably be pretty helpful But you know other than that I'd say I'm really excited and and I think the folks who are going out of our And traveling to it are are excited too. So yeah Great. Thanks. And any questions from anyone on this? Will there be I can't attend in person will there be ways or you know, is there a need for us to attend remotely So at one point we would we were considering making the like having a hackathon the weekend before which we've decided not to do There was some notion of maybe having the folks from outside who couldn't attend in person help Process the stream of what we were hoping would be like pull requests and other fixes probably not going to see that this time but Nor are we setting up because it is kind of hard to do from a hack bus, you know any sort of remote participation But again, certainly if you see a stream of stuff come in it'd be great If you do want to help being able to be responsive to some of those questions Would I think the be really helpful to the people there? I know it's a time zones are off too, but You know an answer overnight from Monday to Tuesday could still end up being pretty helpful great If if no other questions on that onward looking at future hack hack fast planning We are tentatively thinking August and October would be the next logical timeframes thinking us and Europe as well But it want to understand from the technical community here. What's gonna be valuable in terms of timeframe and location? We do have a couple of companies in in both us and Europe that could potentially host in these rough timeframes But want to understand the interest here first For the TSC members on the call If we were to do something in the August time frame in us or October in Europe are those things that you would attend Yes This is so much. I certainly would Yep Looks like Ben is a yes as well heart Dan Chris October for sure August Okay August is usually the summer doldrums Yeah, that's I wanted I I Think August is Well, I'm on vacation the last I guess weaker we can a half or whatever of August anyway And I suspect a lot of people are taking holiday in August fair enough If we were to push into early September does that sound like that would be a bit better assuming we dodged any of the industry conferences and Labor Day Labor Day. Yes, okay All right Okay Yeah, we could look to that. I know Brian you are gonna be in in New York in in August and Like I said, I'll be there too, but on vacation You know, we've got a heartbeat going of once every two months which has felt valuable to kind of keep to that heartbeat The only thing I'd suggest what August is maybe earlier on the August side I do recognize it's when all of Europe goes on vacation for the entire month so having it in Europe, I know that might be not not the best time to have it there but a You know mid we could we could do it mid-August these coasts But we could also delay it by a month so we can skip by a month I tend towards the idea of sticking to the heartbeat but and and you know At no time is it ideal for everybody But that you know, it's you start slipping or can't or skipping It just becomes too easy to lose the momentum as my concern So I think we can do it pretty inexpensively in mid-August on the east coast with a number of the options that we have So I I just make the pitch for for mid-August east coast The heartbeat is all right, but the point is that the conference that hack fuss may not have a heartbeat then Because nobody They may not have a pulse is what you're saying So, you know Would it be useful to be more Would it be useful to be more systematic about this by having kind of a pole and and Driving, you know, like with a range of dates and locations and then driving the TSC and and others to to kind of flush out It that's but but in theory kind of thing Yeah, if you could sort of you know, if we could do a doodle pole and You know pick a date don't don't ask for dates, but you know Just sort of pick a date and see if we can get you know, 50 people or something and maybe that's worthwhile Cool, I'll get a doodle out for Looking at the US version kind of spanning a couple options August and September and then we can look at Europe as well and We'll move this forward, but it sounds like in general terms our interest more just kind of Optimizing on the date for it And I think you know, we just wanted to do a check-in and make sure that the TSC found value in Kind of a regular face-to-face gathering like this Not just for outreach, but also for core maintainers and for cross-project collaboration And you know, we could always find ways to associate it with say consensus or with other larger conferences Some of us are likely to be at any ways, but I just wanted to make sure yes, there's still desire There's still there's still energy for for this kind of thing All right. Well, I can get a doodle pull out we can we can gauge interest that way as well And circle back next week with some of the results that we see from that and hopefully that'll spur some discussion too, right? Chris if nothing else do you want to move on to the security bug handling process stuff? I know we chatted on that a couple weeks ago and a revised draft went out Do we have a quorum? We are a quorum now Greg is here. So we've got 8 of 11 Perfect. Okay. Yeah, so I guess is Tracy gonna reviews a Sure, I can do that Chris. So the Proposal that Dave has put on to the Agenda is to have a process for reporting security bugs And that process in general Does two things it specifies that each of the projects has to have two members To maintainers that can handle security bugs and be on the security team And then the second piece is to actually define what the process is and that process is taken Looks like verbatim from the Apache process for reporting security bugs And then what happens after that bug is reported? Whether it's accepted rejected and how it's handled as far as Committing code and making sure that nobody knows that it's for a security issue and how we go about reporting it After the fact through the CVE process. So that's really what this Proposal is about it has been brought up here before and Has been put out on to the list for review and I think Think what we're looking for is is really do we have agreement that this is the right process to go forward? for reporting security bugs So I had a quick question about this So I asked last time what we were doing to define a security bug versus a non-security bug And so the definition of a security bug here is you know any bug that adversely affects the function of a functioning of the software product So this kind of seems like any bug to me Is there any way we can delineate more clearly what's a security bug and what's not? So I think Dave had in the document and it's I read it this morning But it was basically a bug that allowed any actor whether trusted or not to make the system To compromise the system right and so I'm not I'm not sure What we would do to kind of make that more specific Any Yeah, I'm sorry Tracy. I Some degree. We're at the mercy of the bug reporter making a judgment call as to whether that bug represents a violation of access You know and fits fit the definition that probably we should try to have I mean certainly we should have the Process posted publicly and fairly clearly so that even somebody not deeply involved in the development processes So our different projects knows how to report a security vulnerability when they find one And so given that it's clear it probably will also state those criteria But we're still somewhat, you know, you know depending upon that that reporter to report it accurately And I think we just have to live with that with prospect of both non-security bugs coming in through this channel And with security bugs coming in through public channels And and just rational ways to respond to this And the other thing that the the process did say is that the security team would review each of the security bugs as they came in And either accept or reject The bug so I think you know not only is it the reporter. It's also the security team. That's being formed that's going to have kind of a Decision-making over whether or not they think this is truly a security bug Yeah, so I'm confident the security team will get it right. I just I just want to make sure we have place So that public bug reporters You know do like a reasonably good job in determining whether a bug is a security bug or not I Think though the heart what you're really getting to is what that The group that's triaging has more work to do if people are putting in things that aren't really security bugs Yeah, exactly So I mean bad things happen both ways right if people put it if every bug becomes a security bug then the security triage team has to figure out what's real and what's not and If kind of everyone just submits bugs through the public channel, then that's not good either, right? Well, right, but we can't Make people I think in practice it hasn't become a problem for most for any project that I know of and I'm willing to consider problems, you know situations I don't know about but Generally, you find Especially if it's phrase correctly on the website, you know that that neither neither extreme gets hit and If if you do see lots of non-security bugs coming in that's a sign you need to tune the language more clearly But I think that is that's a risk to take or price to pay for the security team is to recognize They may have to filter, you know stuff that isn't security related. It's a price to pay to get the stuff that truly is the only the only thing that I would I Think that you know Brian that what it does suggest though is that whatever page we direct people to from this and I was just looking to see what You know where we actually sent people and I don't know if it's just a function of I mean I get directed to Jira hyper ledger.org slash secure slash dashboard and That puts me at the fabric dashboard, which is probably not where we want to send people. I Don't know if there is another dashboard or if the secure dashboard is It's my default dashboard. So I guess what I'm saying is whatever page we direct people to it should be open to everybody and There should be a way when I tried to create a bug There should be a way to designate that this is a security defect in The bug creation step and we should be giving them specific instructions if it's a security bug do this otherwise do that Right there when they come to the page so that they are at least presented with Some instructions we can't again. We can't make them but we can certainly try and lead them to the trough Oh It should be as streamlined and as few choices as possible like it should be here's here's the the hot button Then to describe the problem what you tried to do to reproduce, you know And maybe goes straight into Jira in a secure You know group, but it shouldn't just dump somebody onto a dashboard or something They have to then navigate to figure out it should be you know time is of the essence at that point So I think I think that's right. So I don't know I mean, I can you know, we can certainly have I mean Tracy Maybe you and Dave could work with rye to figure out how to Get it so that we can actually have a link off of each projects page that takes them to the appropriate So when I click the link it it takes me to something like slash secure slash dashboard and that happens to just bring up things that are In my sawtooth cue Yeah, that's that's the user right Right it brought up my default dashboard, which is the fabric dashboard. So it's doing the same thing for you Yeah That's not like that would be fixed it's fixed and by the way a small Suggestion maybe you should put the what is a security bug before you start talking about reporting security bugs in the document You know in the document Then I think it's wherever we put a thing Yeah, I know I know you're talking about how to how to drive people into the right place where to put the security bug But even since we started off the document, I'm saying, you know, what is the security bug should come Before you say anything about reporting security bugs or security bug triage or any of that stuff that Oh, so moving what is a security bug up to the top? Yeah That's what I will you frame what it is about so from the get go That's easy enough guidance towards reporting You know with it starts off right in this document and maybe Maybe some more quite. I mean, I don't know how much more you can say about what is a security bug? I mean like hard mentioned just like Pornography we know it when we see it Well, you know again, I think you know as as as Brian said It'll there's no way to make it perfect, right? I think the the simplest definition is going to be the one that makes the most that has the most effect and Most people when they want to report the security vulnerability, they know what they're doing Right. I don't I agree. I mean, you know Somebody is going to report something in JIRA and not market as a security bug and somebody else is going to go Oh my god, and then quickly they're going to annotate it and say it's a security bug and it comes off The visibility from everybody else and then it gets dealt with right. I mean It's that's just how these things have to work Sure, we have to be practical Yes So modular modular needing to have a streamlined security bug reporting form and Modular some documentation notes or some changes to how it gets described on the public website. Are there other Comments on the proposal, you know hold it from being approved I Don't have a problem with the process itself. I do think though that we want to make sure that Somebody is addressing the actual reporting mechanism and I think that the other piece of it Brian would be that we want this to be on the Hyperledger.org slash project slash saw-tooth slot, you know Pages Yeah, it should be very prominent. So Project wide and per project. Yeah, I mean I have a hyperledger wide and per project So So I have no no problem with the basic mechanism, but I had a question about process The very first section mentions, you know users can file bugs to JIRA But I was thinking won't that make it public if the goal was to keep it private until it's fixed Sorry, there is a flag that has been added to the JIRA reporting mechanism That allows somebody to choose whether or not it's a security bug If that flag if that flag is check Then only the security team has access to it and it is not public to the rest of the world now as Chris mentioned right if somebody didn't click that then We're going to have to make sure that we see that and click it to hide it from the world Right, but my point earlier Was Tracy was that there's no flag on the create issue There's not I thought that had been added. I don't see it. Okay, I'll make sure that I'll talk with right about that because I thought I mean unless we're defining a new type of Issue called a security bug, but that's not a choice either. Okay, I'll check Because I thought he had put that in there. So I'll check with him. Well, there is a if you go to a created Defect, then you can click it. No, you can't click it, but it's there Which is, you know, okay Stop splitting hairs Chris You're a security a member of security team for fabric. That's why you can see it Um, well, but that um Actually, it's not on everyone. That's what it was. I seen it. I I know I've seen it But I know I also couldn't touch it. Maybe it's bugs created after a certain date security level not a security issue Edit issue type bug reporter components priority There is no way that I can see to edit that field So it can't be edited and Um And it can't be set. So I don't know where I don't know how this is happening So from a process perspective, I don't have a problem from a implementation perspective needs work Gotcha I don't know Todd you want to take a does anybody else have any comments or concerns about the Let's just focus on the process and then obviously I think um Tracy and and and Dave have a little bit of work to do To implement it. Okay, Todd Want to roll. Yeah, uh, okay. Uh, so with those few tweaks, um, running through our know Yeah, no, I think this is good. We may have to do some tweaking down the line But this is no different than anything else. So for now, I'm in support of this for sure Cool, uh, bin Uh, yes Chris Yep, Dan Yes, Greg Yes, heart Yes, Mick Yes, Richard I saw Richard on the earlier Uh, Tamash Yes, all right, uh, Richard would have been nine. So uh with uh, Tamash that is a which is quorum and uh, unanimous Kyoki, thanks guys um, any other topics anything people want to Bring up that we hadn't already I just wanted to mention there's a doodle poll out for the performance and scale working group times. Um, and if Team leads of other working groups could make sure that there's someone from their team on the performance and scale working group That would be great Thanks more by the way, Dan We've been looking at your sawtooth page and we're very jealous. So we're here at the fabric team Oh, thanks I guess we're um Going to give half an hour back to everybody. So everybody Uh, enjoy your weekend Yeah