OpenSSF Vulnerability Disclosures WG, 12 Apr 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: OpenSSF Vulnerability Disclosures (April 12, 2023)

Description

Meeting minutes: https://docs.google.com/document/d/1mZEi6EvbH2mvn-gHOUIaysAjHlwJXjJdJ7gMlelSkVU/edit#heading=h.u5im5d90xac4

Repo: https://github.com/ossf/wg-vulnerability-disclosures

A

B

Hey, how are you doing I'm.

C

Good, how are you good.

D

C

Have you been following the large thread, a.

D

Little bit yeah, it's been a lot yeah.

C

It has been a lot.

C

Hey Jordan.

B

C

B

C

Can you still hear me thank.

B

C

Perfect hi, Jordan, I, hope, uh I, hope I haven't come across as not liking you in any way it's it's.

B

C

Very passionate about and it's not it's.

B

C

Enough I also want to take your feedback into very serious consideration, because I appreciate that we yeah, we don't want to.

E

To be honest, I'm less concerned with our interpretation of each other and more with bystanders interpretation of either of us but like, um but.

C

E

I I think we're cool yeah.

C

Yeah, okay, cool I want to make sure to make sure that we're not you know, there's no lingering feelings here: okay, cool great! Now we're just talking, yeah, um perfect, um all right! So, let's, let's get everybody in this call. I, don't know how many people we're gonna actually get.

C

um There are meeting, let's see, okay, let me.

A

Let me the APAC call. This is the autofix Sig.

A

C

I presume you've read the document right.

E

No, don't presume that, oh.

C

Okay, you've not read the proposed those specification document, then.

E

No, if you link me to it, I, can scan it right now, though,.

A

C

C

This is the proposed dot. There is a document that is proposed for defining how so there's the there's. The work that like Alpha Omega, is doing.

B

C

This is like a more standardized document defining this work in a way that anybody can consume and use. That's not if not just.

D

C

At a high level, we need to make sure that, like sure we can have policies and processes that that, um like open source security, Foundation or AO has but like we can't assume those same resources are available to everybody, one more style, absolutely right, all right, so let me send out the.

C

um The meeting that meeting.

A

um Notes, if you could.

A

Let me let me do that real fast, because there are people that are not here who are not here. If.

C

You can either gray or uh mark yourself as present by ringing in your name or you know, making your name solid or if you can um uh add your name, if you don't have it in there. That would be great we need to. um In order for this to become an official Sig under the open source security Foundation. We need at least two three weeks of tenants from organizations Beyond.

C

We have to have at least three organizations or two organizations attending any seg meeting in order for it to be consider in order for us to become an actual seg. So.

C

Your attendance and marking your attendance helps us become legitimate.

F

It's true and very useful.

B

C

B

C

Off this week, so I haven't actually been writing any code or barely been joining any Al meeting or not in any meetings practically.

A

C

Josh and let me let me let everybody else know that we're joining right now, we're meeting now all right, I have too many too many Slackers too many slack instances, hello, oh you're, the person I was actually gonna ping. Well,.

G

G

Yeah sorry I missed the calendar notification. I looked up, I was like oh there's notification over there. There.

C

Yeah that also you got I, don't know if you notice this, but you have to copy.

D

That calendar invite.

A

H

A

Copied this damn thing a couple of times copy to generalize you this, oh, does not repeat: why is this not marked? This does not replicate repeats.

A

um Custom, what's every other, every two weeks on Wednesday, okay done save great.

C

Copy and saved um all right, so let's go through the agenda real fast um new friends in intro uh anybody who's new here who's, never attended. This sig meeting want to introduce himself and and uh uh share who you are, and maybe where you work, or you know what how what brought you here.

C

Go for it because they hand up a Jordan.

E

um Yeah so hi I'm, Jordan um I'm Contracting for the open, ssf right now and uh I'm, a overly prolific, npm maintainer, uh and that is where my interest comes from here.

E

um I got into a very delightfully heated conversation about the automatic reporting plan here and uh thought it would be useful to hop into the meeting whenever I can yes passionate exactly.

B

Passionate yes, there you go um yeah, perfect glad to be here. Yeah.

D

Hello, uh my name is Sandra sorby I'm. Currently a student at njt, a senior uh and I, don't know. I was just looking to potentially contribute into. uh You know: securing some open source software in.

I

D

Capacity so uh just looking to see how to to see where I can help.

C

How do you say your name.

D

uh Andres Andres.

C

Okay, all right and you're, not your name is not on the the attendance list. Yet do you need me to send the let me send the link again into the chat. Oh you got, it beat me to it great.

F

I try to be useful.

B

C

You anybody else new who wants to introduce themselves.

I

C

Right, you can hear it, we can hear you yeah.

I

uh My name is Abbas chitri and I'm a second year undergrad student from Nepal uh and I was just looking for fun stuffs. You know open source contribution and stuff, so I thought I was interested in security. Also, so I found open, SF and I just joined it. Thanks welcome.

C

uh So awesome, thank you um so.

C

Well, okay, um yes, do we have anybody who wants to help scribe our meeting today.

G

I can volunteers tribute I guess thank.

C

You Josh appreciate it. Okay, do we have any opens anybody want to talk about anything, that's um not on the schedule. I mean maybe but yeah. um Does anybody have any like open topics? They want to bring up.

C

Okay, so the people that are new here um at a high level, this um working group, this sig. uh So this is a Sig under the um so Sig stands for special interest group under the vulnerability disclosures working group- and we are focused primarily on discussing the topic of automating vulnerability, fixing at scale um predominantly through um uh both lower Quest generation uh or in some form, trying to bulk, generate contributions to fix security vulnerabilities at scale across all open source.

C

This um uh work at a high level uh is the continuation of um some of the work that I've been doing um in for starting in 2020 through uh last year, where I was the first Dan Kaminsky fellow and bulk generated uh several hundred pull requests to fix security.

I

Vulnerabilities.

C

Such as zip slip, uh partial path, reversal, temp directory hijacking and I've generated in my career north of 7 000, pull requests to fix various different security vulnerabilities across open source, um and so Alpha Omega has hired myself and Yesenia uh under AO to try to focus on fixing security vulnerabilities at scale and instead of Alpha Omega kind of just going in to this work. You know not engaging with the open SF and just doing our own thing.

C

We kind of want to accomplish a set of standards and best practices for doing this work in a way that um uh is inclusive of both security, researchers and also um maintainers um and I'm. Not the only one. That's been doing this work, um uh trellix and Casimir who's on the call has also engaged in this sort of work to generate pull requests at scale to fix security. Vulnerabilities um GitHub is engaging some of this work in the past.

C

To do this, when there was a cve in a popular C library that got re-ventored in a lot of libraries, and so they used a bot that I wrote, um but we want to come with a set of policies and and processes um to establish Norms around how we can do this work in a way that minimizes harm to maintainers, um but still actually gets the vulnerabilities fixed and still, um uh uh but but at the same time, also keeping in mind that, like we are dealing with vulnerabilities at scale, for example, Casimir you generated what 60 something thousand pull requests.

C

J

000, if you have something like that.

C

Yeah 65 000, Polar, Express and so trying to keep in mind that humans getting involved in that sort of scale, is a very tedious process, especially when you don't have a large company or organization behind you. If it's just you doing this work, how can we enable others to do this kind of work at massive scale and have a positive impact on the security of the industry, but do so in a way that's respectful of maintainers?

C

So that's the that is the high level sort of overview of this saying. Does anybody have any questions off of the tail into that.

E

Thoughts but I can wait. It's fair.

C

um uh So they're in that, in to kind of give an overview in that endeavor, we have a specification dock which is linked in the in the meeting notes where we are intending or attempting to Define um what is a um uh what is defining like what is an open source security, Foundation, compliant automated vulnerability, fixed campaign, so creating a set of standards that Define under a set of constraints. What the open source security Foundation considers to be compliant with what we, what we want to see others in the industry, doing.

C

Thank you. So in that context, uh Jordan you have some opinions and perspectives and I. You know I want to open the floor up to anybody who has or has not read this document to to make comments, points, questions anything before it.

E

Yeah, so the document overall I think looks great I think that the.

E

Where I think a motivated by perhaps some philosophical differences or priority different priorities, right I, think that the way that y'all may be approaching, it is slightly different than the way I would approach it um and that what I would probably think to do is say: okay, how can I divide, there's tons of projects uh and tons of maintainers?

E

How can I first like divide those up into chunks and be like which chunk is going to be the most effective in in terms of getting the fix landed, but also like leaving the maintainer with a good taste in their mouth so that they want like, like not just so that they like openssf or whoever's doing the campaign, not just so that they want to fix vulnerabilities, but so that, when they think of security, they have a positive connotation um and it's very easy for maintainers to get a negative connotation about security right now and that mental like that attitude shift is what I think I think that that's one of the things that makes that causes the most insecurity in the ecosystem is when people don't have positive, like warm fuzzies about security and so I prioritize that rather highly as a result.

E

So, for example, um to the stuff some of the stuff, Jonathan and I were talking about today, and yesterday is um for a maintainer who has enabled PBR on their repo. It's sort of a no-brainer right like they have explicitly turned on a programmatic mechanism to receive vulnerability.

E

Reports privately like great you're good, like report them and anyone who's turned that on, like you should just like those are all repos that are no-brainers, because somebody has yeah I think he sent me for clarifying the acronym, um but but like that's somebody who knows enough about security to have turned it on and who, like is prepared to receive the reports theoretically and we'll probably fix it, um and there is then a separate group of folks that doesn't have it turned on and also doesn't have a security policy declared, and this is the group that doesn't know probably about security as opposed to having opinions or thoughts or whatever, uh and this is the group where you'd want to like with the PVR group.

E

You can just kind of be like you have this turned on here's a report like how can we help um with the group that that is completely like unaware?

E

um You know you would probably want to file an issue and be like hey there's. This thing called PVR and here's. Why it's great and here's why you should use it and we have a vulnerability to report, but we don't want to do it publicly for reasons. For these reasons and like you know, so, it's sort of more of a like education thing and it's very automatable, but you'd still want to craft it in the form of like.

E

um Let me teach you how this can be better for you and your users um and if you just click this button, we'll notice it and we'll send you your report and then we can fix it.

E

Yay, right and so, like those are two tranches that require slightly different approaches, but seem like no-brainers to me and then, but then, when you get, the the trunch that I've been passionate about is the folks who may not have PVR enabled sometimes because they can't enable it because you you need admin or maintain access, possibly on a repo to be able to enable it, and not everyone has that on projects they maintain former employees who still maintain their.

E

uh You know their previous employers projects, for example, or somebody who maintains the project of somebody else. That's still on their user account and that user, like doesn't pay attention to their computer anymore, but the project is still maintained very well um things like that. So, but then those users prior to PVR existing the overwhelming best practice and what all of the players in the industry have been encouraging for a long time is hey, go, please add a security policy.

E

Please tell us in an English like a prose document where to send these private vulnerability, vulnerability reports and it could be an email address, it could be go to Titleist or sneak or could be go to hacker1 or whatever right, um and it is certainly a failing in the ecosystem that that's the best we had and PVR is better um but like. If somebody has taken the time to do that, especially bigger projects or busier maintainers that have built a process around.

E

That um I think it's important to try to respect that, even if it incurs the cost, like the trade-off of um being less automatable.

B

That's my little rant: I will be quiet now.

C

uh Anybody else have any perspectives they want to share on this. This topic.

C

I think that the one thing that I think that we're generally in agreement I think the one thing that um uh the one thing that I struggle with is that, given that PBR is such a recently added feature- and um it's actually only coming out of beta uh this month, like within the next couple of like the next week or two, it's still been a beta.

H

C

Right, the security.md format has been a has been a feature of GitHub for several years now, um so there may be a lot of projects that establish the security of that NB file prior to this feature being available, and so they may not at that point, consider turning on PVR and so trying to.

C

um Go through a disclosure process following a process that was defined before PDR was even enabled and a possibility for them to enable when it could just be as easy as asking them hey. Can you enable PVR? So you can we can report there yeah? That seems like uh an additional lift that, especially when you're trying to automate.

H

C

Right, if you can ask them to open to turn on PVR and then they say, no, that's a no that's one thing, but if they say yes, then you've added one more project to the list of projects that you can. You can automate for without too much overhead on your behalf. As the person running this campaign.

E

Yeah and you may even get more than one if, if it's all under an org right, so, for example, the reason that I started paying attention to this is uh I, don't think it was related to this specific campaign. But somebody filed an issue on like 12 different npm repos um that I watch because I like suffering- and um they basically say please, you know, like I- have a vulnerability I like to report it.

E

Where do I do it and um the they were all closed with a link to the security policy by annoyed, overworked maintainers um and certainly.

E

An issue filed on one issue: one notification to the npm people somewhere. That says: hey turn on a PVR for your org and we can report all these vulnerabilities that we have would be valuable, um but 12 is uh counterproductive and so, like I I, don't know how to balance that, because, like like, like my example, is I have 400 projects but they're spread across less than 10 organizations and users, and so, if I got 10 notifications, I'm going to be a lot less annoyed than if I get 400.

E

um And so maybe that's a way to balance a trade-off, so like I agree with you, enabling PBR is a good thing, but like I also would hope that as GitHub moves this out of beta, that they just enable it by default for all new repos and like upsell, pretty heavily hey. Please click this button and turn it on um or, alternatively, that they just turn it on for everyone, um but, like you, know, we're not in control of what they do with their product.

F

So you're you're suggesting that when we submit a poll, pull request with a fix, it's at top level of the project demonstrating all different locations that it is so that way, you're not getting. Let's say: 400 you're getting one per per repo with the different locations and fixes I. Don't.

E

Think so, unless yeah.

E

I'm yeah I'm, talking about like a like a PR is, is I mean if it needs to fix 400 places, then I need 400, PR's right, like it's more of it like if you're gonna be notifying me and asking me to do work without contributing anything. Like an issue saying hey, please turn on PBR um like I'm, basically saying it would be nice if the identity of the humans receiving the request was taken into account, meaning like, for example,.

H

E

Have more than one notification queued up for this org? Let's only notify one place and if we have further notifications, let's edit that issue and be like it also applies to these repos and bullet point lists and like and in that way, you're sort of you're not you're, still notifying the right people, but you're, not overloading them with notifications.

E

um Something to that effect. You know that might be a compromise right.

C

That works. um It works really. Well, if it's an organ, if it's a company but I have worked inside I've been a part of organizations. For example, the angular UI organization was a mixed bag of a bunch of people from a bunch of different projects that didn't cross talk at all, and they had just ended up in the same I. Don't know how they all ended up in the same organization, but.

I

B

C

Central leadership over that organization right just a landing page for a bunch of projects and so like if you would have gone to the dot GitHub or that project and said hey here in the dot GitHub. Please.

E

Open it that's a good place.

C

Right, you're, there's probably nobody watching that repository, except for the one person that created it to put a put up something in there.

E

But the that's fair, um I I do think that's probably a rare case, but also like, even in those cases it's not destructive to enable. So it's like all you need, is one org owner to see that and be like yeah. That's a good idea and then go click a button and like it's on for everyone in the org, regardless of whether they're Central leadership and that's not going to stop an individual project from then going and turning it off.

E

But like that's at that point, it's less like yeah and unfortunately I doubt there's any way to see if it's turned on at the org level versus at the you know, what I mean like like I doubt that as a non-owner of an org you'll be able to see if an org has automatically turned it on for new repos or has clicked to the enable all button or, like you know what I mean so.

C

Well, at least for, for uh there are certain things like you can I think there are certain things that are universally applicable. For example, if you have the setting like open Assistant has a setting. That's like require sign, commits right when you're committing um the web UI and then all the summer projects. You can't turn it off, but it shows you that it's set as an org level permission or an order level setting sorry the hiccups levels, yeah.

E

And that would make sense if it was a requirement, but the way that GitHub is currently implemented at the org level is that you can check a box that sets the defaults for new repos, but then there's an enable all disable all button that just stamps the setting onto everything. So if you click enable all and then somebody turns it off like there's you'd have to infer that you wouldn't be able to actually like determine that. That's what had happened.

E

I, don't know I I you're right, like there's going to be for anything that that's weak, there's going to be edge cases right it's um or like counter examples. So I, don't know what the best solution is. It's just kind of um I think that.

E

How would I put it um maintainer burnout is a very big topic in open source and um like so is a security and I I think that we we can't have one without addressing the uh we can't address one without addressing the other in both cases and like in both directions, and so, like I, think it's it's worth delaying a tranche of projects in getting fixes or reports if it avoids adding to the burden on maintainers.

E

That's a judgment calling on off degree on right, but um that's my my intuition here.

C

I was still muted.

A

C

Else have any opinions on this uh from their own experience, maintaining large organization projects or been being part of organizations.

G

I wouldn't say large, but um it's a hard thing to balance. um The ideal thing would be if the repository hosts, like GitHub gitlab Etc, just supported having this be a more integrated feature and also having it be enabled, by default, um the future being the private vulnerability, reporting.

G

I feel like from the maintainer perspective. If you have it be, opt out and it's a one-click opt out. That's a reasonable balance, um but I would say that requires support from whoever the host is so.

G

And there's also the question of what do we do in the meantime before these are implemented for the different platforms.

C

Do you Jordan, do you have any opinions, as this relates to um other other than GitHub, or is this all GitHub Central I.

B

C

E

Just checking yeah I mean I think any a solution is always nice when it's not tied to a single provider or company um and there's lots of ways. I want GitHub to be less like, like the single source of failure or whatever in open source ecosystem, but GitHub like open source is GitHub right now. So it's like that. That's not a justification for ignoring gitlab and friends, it's more just like. uh If we don't have GitHub, we haven't achieved anything and if we do have GitHub the rest are like often a rounding error.

E

So it's like it's important to bear that reality in mind. Even if you're not happy about it.

C

um Okay, so the ask here is that, let me just read it repeat it back to you. The ask here is that.

C

You were I I struggle with the single report, I hear what you're saying where you're you like you end up, for example, right depend about right. You have a bunch of projects that I'll use the same dependency set, and then you end up with, like five depend about pull requests across six repositories that, like you, know across you know, X number of repositories that are all fixing the same vulnerability right.

C

You can similarly end up with the same situation where you have the same report coming into multiple organizations that you all maintain that can just get annoying, especially when it's please enabled PBR right. Please enable PBR, PBR.

E

Well, depending box, a little like please enable PBR is one thing, but the the fixes right, like the reason dependabot, is annoying and people turn it off. A lot is because it affects every level of the depth graph, because there's lock files everywhere, instead of just having lock files at the app level so like, but the.

E

But in this case you no matter if it's 100 Levels deeper two, you will still only have one PR doing the fix, certainly releasing the fix would trigger dependency, update wave but like I I think the fixed PRS or the even the the reports of the vulnerability themselves are going to be targeted and not suffer from that problem. Right.

E

um It's just the the please enable PDR thing is the one that I think could be spammy and like, but I I actually am not even that worried about that. If, if I have a repo that has no security policy and I have PVR off, and then someone says hey turn this on so I can report stuff, I'm gonna be like oh thanks, like I didn't realize. I had no way to do that, um and so, even if it's annoying, because there's a lot I'm gonna be like all right.

E

Well, I should have already done this. You know, but like the I'm, not gonna, have the same group magnanimity. If you know I laboriously put a security policy into hundreds of repos and then I still have to go click another thing, even though I already told everyone how to do it. You know how to record things. You know. That's the sort of so like a fix is fine.

C

So you're saying that if you have, if you've, multiple multiple vulnerabilities in a single organization- and there is a reporting policy at the org level- then open the open, an issue only at the org level. Oh.

E

No I'm so honest I I'm, like so there's the three tranches I've talked about and the only tranche that I think is a question is: has a security policy does not have PVR what.

H

C

H

E

C

Does it matter so does it matter if the PVR is coming from the org level or the repository level, because if it's coming from the repository level, instead of the org level, doesn't that indicate that the project has a certain level of autonomity from the parent organization that is not causing it to be part of a standardized General policy set at the org level?.

E

No, it might mean that the repo admin turned it on, but is not an org owner.

C

I'm saying the security of that MD file: oh oh presence of the security of that NB file being at the org level versus being in the repository individually.

E

I have security.nds that are in repos that predate GitHub, supporting an orglevel.github repo and then I also have a GitHub org level, dot GitHub repo with this security policy, so sometimes I have both just for legacy reasons. But yeah I agree if there's no org level policy and there is a repo level policy that suggests that um I don't know that that that that that's worth considering differently I, don't know exactly what it suggests yet.

C

Because I mean and also the problem is like what, if there's no dot GitHub organization to right like there's, no Central reporting location, then right, it's like that's true,.

E

C

E

Think you could also just file one issue and be like. It's also applies to these projects like what do you want us to do? Right, um I,.

C

Don't know yes because, like for well take, for example the Apache software Foundation right they have like. Can you still hear me? Okay? Take, for example the Apache soccer Foundation there is. There is like there's that, like at least a thousand repositories right, yeah and they're all run by different.

E

I think that is a very unique special case. I I would probably hard code Apache like in it with its own logic, I.

C

Mean I mean there's also the eclipse foundation and there's probably other ones that have similar behavior, that I I don't know about right. Like you want you, you may want to hard code special cases, but at a certain point your special cases don't work, because there are things you don't know about yet.

E

Right I mean I, think I. Think the number of Foundations or organizations that have truly in like a lot of truly autonomous projects is like I. Think that's not going to be that many um I mean maybe double digits, but like not triple.

C

Yeah, probably um but I mean that includes large organizations like Google and like am like those, because those projects are probably run under a single organization, but each of those teams could be very wildly disparate from foreign.

E

Yeah I mean I would expect, though, that Google would enable PVR at a company level and or or would have a company-wide security policy right, like I. Think, like I, think the foundation argument, like example, is, is one of the few cases where there wouldn't be an org-wide policy. Somehow right.

E

I mean it's good to bring this up right like it's, it's important to account, for you know the different different cases.

E

It's just kind of like the open source is about the long tail of things which largely is going to be an org with one to five projects or a user-owned repo, and so it's like I think optimizing, for that is important right, like the the number of Open Source projects that live inside and Enterprise companies, GitHub org is, is probably not actually that larger percentage, even if it is the Lion's Share of the popular ones or something.

E

um I, don't know, I mean I, have no data, so I'm just.

C

Talking about it, okay,.

B

C

B

Gonna screen share screen.

C

This document recently had legal come through it, um which uh means.

B

C

Of the stuff got uh uh munged interesting ways: okay, vulnerability, messaging disclosure systems.

C

A

E

Yeah I think what I'm talking about currently goes in that hand wavy sentence, you should assess what this.

E

C

Private disclosure- you know they can't yeah if the US s software hosting supports.

E

um Just a programmatic means of private reporting.

C

E

And to what Michael was saying in slack as well, if separately, anyone like whether it's openness is ever not came up with a structured format for security.md that could Point people programmatically at a disclosure mechanism that would suffice as well. It's just that doesn't exist right now.

C

It doesn't, there is a Paul there's something that uh Luigi's working on in.

H

That department, um Json.

C

Specification but I think the problem with that is that it still has the multiplicative, like you also have to Define adapters for every single different disclosure mechanism, hacker one bug crowd but then, like even taking into a mind, jira right. Every single, like every single organization, is running their own instance of jira. It's not bitbucket's Central jira instance, so you can't log in account for jira and Report via that channel. You have to create an account for every single like Jenkins. Is one and apache's one like all that, and that's that's that again scale.

E

Yeah I mean it, but you could make the the such a schema, just not work for anything that isn't anonymously, programmatically, submittable or something like like it requires you to create an account. You don't put it in the schema, because it's not good enough right, like schema, is just for scalable, programmatic, private vulnerability reporting. So that's either like a post, endpoint or an email address, or you know um some static thing that says: use GitHub, PVR I, don't know like whatever.

E

Maybe GitHub has a thing um yeah, because yeah I mean I think the reality is that if a project requires somebody to sign up for jira to get to get a report, they're just not going to get reports anyway. So yeah.

C

Is not enabled on the on the.

E

Vulnerable repository or something yeah, and it doesn't matter for this sense, it doesn't matter where the enablement comes from. It's just is it on or not yeah.

C

A public issue.

E

um Like advising of the existence of yeah yeah requesting yeah but like I, think it's useful to point out that the issue can advise that there is a vulnerability without saying what it is like. It's important that it must not disclose the vulnerability and it should imply. You know it should say that there is one right.

C

You know um the programming means of reporting is not enabled in the vulnerability your product uh of a programmatic means of private reporting. Okay, the program means of private private reporting.

C

Reporting is not enabled, then the public issue requesting the feature being enabled on their deposit.

C

F

I don't know if there's a I can't see because the little bubbles there you go. Oh.

A

I'm not muted, no you're, not muted,.

F

I was just talking to myself, I couldn't see, but it because everyone's like typing I, was like over. What I was writing I was like did I have out of space or something.

B

Like that, yeah.

C

C

uh At this point,.

B

Three dot a.

H

B

C

Have we have the um so? How do we want to start? Because you have a you, have a thing you want to communicate, which is like.

C

How to so okay, if the vulnerability impacts, multiple projects under the same GitHub or the same, so you shouldn't.

E

I typed a sentences. Well, you can use.

E

Like, like I, think it's I, don't think we need to prescribe this as the advice for other people as much because in like, at least until we've tried it and know what works but like it's basically just saying like we.

C

Should think about it, we shouldn't make a policy that they have to follow the flow of like check for security.md in the organization. Then, like then, you're saying that that Paul, that should be only added after AO, tries it but yeah, and that's it exactly okay. So then it should be.

E

But just I don't know, and we can provide examples like, for example, like um okay and.

E

E

So I don't know something like I'm just kind of spitballing but like like you can't we can't proscribe anything. You prescribe anything here because, like we don't even know what the objective create, Like rules would be and we haven't even tried it out so like, even if we came up with something that might be terrible right, um but like it's useful to kind of talk about here, as so the spirit, I think and the intent isn't in there and like as Alpha Omega gets better at figuring this out.

E

We should of course tighten up these sorts of documents, but, like I, don't know, what's what what's stronger I would put in here that wouldn't be like Overkill. You.

C

Know, I I think that, as that sentence is currently it's overly vague, okay, that's fair. Just.

B

Like it I don't know, I don't know what it adds and it.

C

Just more adds confusion to my, in my perspective. From my perspective,.

E

I guess I mean that's fine and if you want to delete it, go ahead, my thought is of what it adds is that it um like okay, so I'm coming at this from a JavaScript spec angle.

E

A little bit here is um there's non-normative notes in the JavaScript spec that, like engine implementers, don't have to follow, but they clue in people to the intent of something or the possibility of optimization or of like an edge case to be aware of so they don't optimize themselves into a bug and stuff like that, and that sort of should should and non-normative have the same semantic right and so that's sort of what I'm thinking is like so being like. Hey try not to be a dick here, and this is something to be aware of.

E

F

Not just being a dick, it's also like it's not something most people would think about they're. Just like hey. Let me just submit all these and I. Don't I don't realize it's.

B

F

Retainer across the projects, so I think it adds a value of like hey, think of your use cases and your edge cases, but also these are other ways that they have already described how to communicate to us. So the security.md file and I think you had mentioned another one earlier of what's to check, but I think it just helps folks point to so.

C

F

Locations, yes,.

C

I agree: I think that I think that this sentence is more useful if it provides an example. That's.

E

Totally fine, like I, said it is just spitballing like we can.

C

100 be more okay, all right so before it gets me.

E

Fleshed out and I'm happy to try and do that over time and yeah go ahead.

C

For example, all right sure, for example, um uh instead uh many issues across multiple.

E

In the same order or something.

B

C

C

I mean users: don't have dot githubs. Do they? Yes, they do. But can you have a security policy there? Yes,.

E

C

E

um I may be part of the reason that GitHub has that that, nonetheless, to have it cool.

C

All right, um multiple roles is, in the same within the same user organization, I, think appropriate for um a single issue.

B

B

A

B

Or GitHub this would be that dot.

B

F

For a little bit, more clarity, I just I, think um it could be at the top or something but defining what an organization is, because my folks, most most folks might think of it as a company and not think of a foundation as an organization um or not realize that some source code management tools have separate organizations just.

H

C

I'm, just using that I'm using the colloquialisms that are associated with GitHub do other source like just get lab bucket, use, different terminology, they use organizations and repositories. That's.

F

A good question I can check.

E

Yeah I mean I, think it if that's a. If that's a term that is going to be confusing to anybody, then I would say that all of openss documents should probably link to somewhere. That defines it in detail yeah just the first time that they use the word organization, and then we can kind of solve that problem for everyone. There.

C

Is a discussion um yeah there is a discussion within the open, S stuff of creating a uh like a glossary or something glossary. Yeah.

F

So get lab does but nothing in bitbucket in regards to an organization.

E

But like they might call it user or scope or namespace or I, don't know whatever I can spit out the source words, but like I'm sure they have some discrete like they have a two-part Slug and I'm sure they have a name for the first part right, GitHub actually holds an owner in the API I believe yeah.

F

I think it's just because you I keep hearing uh and during the conversation organization, I keep thinking company. That's the first thing that comes to my mind and I was like. Maybe we should, but a glossary is 10 times better because we don't have to maintain it.

E

Yeah right well- and it's also like every document- will have the same problem. Yeah.

A

Our dog, the opennesses, have.

C

Stock get up is empty. Is there a documentation about the doc GitHub feature that I can link to in this line?

C

um Probably, let's.

B

C

E

Hard time tracking it down yeah it's hard to search for things with a dot in it. Let me I'll, find it and drop a link. Thank you.

E

E

Apparently you can security.mv can be in the repo root, the docs or the dot GitHub folder. So there's three places.

E

um So here is a document about their default community help files, I'll put it in Zoom I, saw that one but I didn't um and I I got to that from the adding a security policy document which is here.

C

um Well, I'll just link to that for now.

E

Yeah so yeah, because that one talks about security policy per repo and that has a link to the default one for the order. User.

C

All right, we are currently uh eight.

B

C

To the top of the hour.

F

uh Matt has his hand raised, go.

C

For it, hi Matt welcome.

J

Yeah I'm, sorry, I, I'm, sorry, I, joined late and and pardon if this has been asked already. But you know I know that there's a lot of talk about the Sterling tool chain and I know that um workflows are assumed to be part of it in you know, despite talking about GitHub, and you know, GitHub actions are going to be preeminent play part of it as well.

J

So can this be viewed as part of like a a workflow file, a security workflow file, not maybe not just a top level file as well and be part of the Sterling tool chain. Where we declare what things you want: open, ssf, open, ssf, specific workflows to look at or you'll be allowed to do.

C

You're saying for whether or not like so open source projects are publishing a file pretend or putting a file in their repository that are defined. That is defining how the open ssf can interact with that Repository.

J

Well, I think that that's part of this customer on a sterling tool chain is that the assumption is we're going to take tools that we're using like Alpha and Omega and or and things to prove, salsa compliance and they'll include good of actions that are there for approving salsa prominence Etc. That is something that the direction is is going to be a workflow that runs one or more actions um to prove different compliance or different aspects around different things.

J

So maybe Auto Effects can be part of that Sterling tool chain you opt in by you, know, adding you know, actions or whatever they can take. The form of you know if you use subversion or some proprietary thing or a different runner for your CI process. That's fine, but there could be a you know, still a signal file that runs your workload and even if you choose for your workload to be run by an external Runner, that file still could be put picked up as part of a workflow. So.

E

B

E

Well, yeah I, just I, feel like part of the Sterling tool chain tool chain would have to be like something to the effect of Follow Your ecosystems, best practices for metadata, like a package son or a gem file, or whatever and.

I

Similarly, they don't have a.

E

License have a security policy right like like, in other words, there has to be something in there that talks about the various forms of metadata that are necessary for the tool chain to operate and.

H

I would assume that that.

E

Also includes enable private vulnerability reporting if your platform supports it, yeah.

J

Hi Jordan, so you know that's what we're working towards in the openjs foundation right, so we'll have prescriptive. So it would be great if that overlap were developed like if we develop. You know tool chains that those include you know profile tool, chains for different languages or ecosystems. Absolutely, but it's not, it would declare you know that would be programmatic, it would be declared and it could be automated through through a tool chain. So yeah the.

C

Idea behind this standard right, these the specifications we're defining an open source security, Foundation, compliant automated vulnerability, fixed campaign. These campaigns are designed to be targeted and Beyond the scope of the projects that are aware of the open SF um to include all open source projects across all open source. Right like this, is not just products they're aware of of the Sterling tool chain. This is any project that is open.

C

Source can receive a pull request or some sort of contribution to fix a security vulnerability in a way that is defined by this process or by the specification yeah.

J

It might so my mind declaring that I want this workload for run. As on certain events, that's not my opt-in, I declaratively, put in a programmatic work directory structure, a workflow saying you know open ssf run this run my autofix workflow I. That's my explosive permission to do that.

C

So yeah, so we're we're the design behind. This is an opt-out mechanism where maintainers can choose to opt out of receiving um uh these reports and receiving automated fixes.

A

C

This but they're opting out of receiving reports or automated fix like this, will still result in them, will still result in the vulnerability becoming public right. They're opting out doesn't mean they won't receive it or they're opting out only and they will will not receive it, but it will mean that their vulnerability immediately becomes public.

C

That answer your question.

J

uh Yeah, well that eliminates me on what what your, what the positioning is, but I, also I I, if you opt out, is the mechanism and github's gonna back it. Then that's.

C

Cool's not backing that. It's like the way that we're thinking about leaning so the way that I've done opt out for bulk Warcraft generation in the past is asking people if they want to opt out to create a DOT GitHub file.

C

um Sorry uh inside of their dock GitHub directory in their repository, they added a file um called bro gh-robots.txt and it lists which which robots they want to not allow to interact with their repository, um I'm, leaning towards moving away from that standard and then there's a new standard, that's being developed by Luigi um path, uh security, email signs, I think.

J

Yeah I mean I worked with Luigi and Michael scavetta before Alpha Mega open. We talked about these things, so yeah opt out is just kind of A New Concept for open source.

C

um Yeah, it's a New Concept for security too, but we're trying to move that one forward too.

J

Understood I'm just saying that.

C

J

You're saying I'm forcing you this on the population, you will get resistance. Oh.

C

Yeah, yes, oh yes, no! No, we are in complete agreement on that and I have art I've been I'm, so something that I mentioned earlier in the talk. I'm 7 000, pull requests, uh automated security fix, pull request into this, and it crossed my career so very familiar with that, um and that's part of the reason we want to include maintainers in this discussion is to make sure that we're doing this in such a way that is respectful of the maintainer and doesn't you know like it, won't be?

C

It won't be opt-in, it will be opt out, but we want to do it in such a way that decreases the likelihood of them trying to opt out of it.

J

Yeah I mean I'll, look to Jordan, representing because he's the voice of the individual in the openjs foundation and package communities. So if you know, if he's okay with it, then I'm? Okay with it right.

C

E

Problem we're working on being okay with it.

C

Yeah yeah the biggest bit of the biggest pushback I've gotten from any organization. I've I've been targeting mostly the Java ecosystem. With my work and the Apache software Foundation, those maintainers have not been, everybody else has been very receptive and positive, and just you know thank you for the polar pressed and moved on the the most negative reactions. I've gotten is from the ASF Main maintainers.

C

um So there's this pull request. um The security Insight spec, which is adding uh Luigi, is proposing to add um some of these fields um like except spot pull requests I'm going to try to move away from the term bot, because um bot has a negative connotation in the industry um and we want to go towards automated pull requests um because I'm, not a bot, I use my real account to generate these pull requests.

C

I use automation against my account to do it, but it is coming from me and if you post a comment saying what the hell are you doing, I will actually respond saying. No, no I am a real person like this is actually me, but, like I, had to use the automation to generate these pull requests.

J

I would say that, as long as there is no identity, this will help with your opt out there's as long as there's clearly an identity saying with a person behind it, saying email this person there's somebody saying you know contact this person, look at the person behind it. Yeah, yes,.

C

um Let me put this in the um here uh Josh: can you put this I lost track of the um the notes? Can you put this in the meeting notes where's the chat there. It is. This is the there we go found it. That's the link to.

E

That I actually need to drop. So thanks.

C

Everyone I'll see you next time all right see you guys in two weeks. Thank you all for coming soon, bye um and Matt. If you wouldn't add um your um uh uh uh name to the um I, did attendees. Thank you all.

J

Right I also yeah I also fixed the date. The date was copied and pasted for today's.

C

Thank you I. Thank you now that you mentioned I. Did that I did that wrong, you're right! Thank you. So much I appreciate that thanks yeah. Thank you. All bye.

F

All right, yeah.