-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Apply to donate vuln-reach to the OpenSSF #388
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Louis Lang <[email protected]>
Has the group been speaking with our Security Tooling WG, and that group endorses this motion? We'll want to see evidence of public meetings and minutes as the project would move over to the foundation. |
Yes, we've been having discussions with the Security Tooling WG. This project was presented to the group on 2024-08-09 and is in the meeting notes under the bullet |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for making this pull request! In this pull request can you also add vuln-reach
to the Projects table on https://github.com/ossf/tac/blob/main/README.md#projects?
Is development of this project primarily happening on https://github.com/phylum-dev/vuln-reach in the main
branch, or elsewhere? There doesn't seem to be a lot of recent activity.
To be clear, recent activity isn't a requirement for becoming a sandbox project, but sometimes people think "oh, I'll donate this to the OpenSSF, and they'll figure out how to get contributors!" and I just want to make sure we're on the same page - projects are responsible for figuring out how to get community participation.
Craig is listed as a maintainer but according to GitHub he has never contributed to the project. Can you go into more detail what he's a maintainer of? Beyond that I do think this project is good for openssf. |
Yes, of course.
We began this work some time ago as part of our proprietary product. We got it to a steady state for Javascript/Typescript, before shifting our core product focus a bit. We recently decided to open source this.
I wasn't personally involved with the initial presentation to the WG, so I'm just going with what was passed along to me. As I understand it, Craig was interested in supporting the project. I will follow up with our team to get a better understanding on this specifically. |
I think there are two things being conflated here. Let's break them up.
|
Thanks Ryan. Re: #2 correct. We want to ensure that as projects develop and grow that they have a thriving community around to support them (hence the desire to house them within a like-minded/focused working group). Having multiple maintainers is critical to the long-term viability of a project as it allows for things like code reviewing, dual-control, etc., and helps share the ongoing burden that maintenance and community engagement. We also prefer those maintainers to be from different organizations to help weather any challenges that could arise from organizational changes that impact the maintainer (that in fact is a requirement at higher levels within the TI lifecycle). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please identify additional maintainers based on comments about engagement from Craig at Stacklock. Are there any blockers the TAC can provide in helping you navigate this?
+1 To needing to address the diverse maintainership requirement. @louislang Some ideas to potentially engage some more folks from the community: 1) put out a call for contributors in the OpenSSF Slack channels ( |
We are applying to donate
vuln-reach
to the OpenSSF. We believe this meets the criteria for a sandbox submission. This project aims to commoditize determining whether or not a vulnerability is reachable in a given codebase.