Mentorship Opportunity for CCC Projects

[Salkimmich]

Description of the feature

Mentorship Opportunity for CCC Projects

I'm reaching out to let you know that the Linux Foundation can fund three-month mentorships to support technical and documentation efforts for CCC projects. This is an excellent opportunity to enhance project development and attract new contributors.

Benefits and Flexibility

• Flexible Timing: Start the mentorship at a time that fits your project's schedule.
• Enhance Your Project: Accelerate development and increase project visibility.

Getting Started

1. Draft Your Project Idea: Utilize the Project Idea Template to clearly outline what mentees will work on.
2. Submit Your Idea: Use our Mentoring Guidelines to navigate the submission process.

Have Questions?
Feel free to ask any mentorship-related questions right here in this issue thread for a prompt response from CCC. You can also join the CCC Slack channel #mentorship_program for general mentorship topics.

Why Gramine should implement it?

This will allow you to implement new features or refactor from a technical contributor with Linux Foundation support.

[mkow]

@Salkimmich: Please don't ignore our issue templates, we use GitHub issues only for tracking bugs and feature requests.

fund three-month mentorships

What does this mean, exactly? Is the mentor being funded, the mentee, or both?

[Salkimmich]

Apologies on placing this in 'features', this is the better spot for this discussion. Generally, we can continue this thread here and/or on the CCC project leads mailing list. I'll be sending updates here so I don't spam your repository with general updates: https://lists.confidentialcomputing.io/g/ccc-project-leads

Historically, the CCC has had "Project Mentors," who are representatives from the CCC TAC. These individuals offer their expertise and assist in engaging projects within the Linux Foundation. To avoid confusion with our newly introduced mentorship program, we are considering renaming these roles to "Project Liaisons."

Our mentorship program, funded directly by the Linux Foundation, is designed specifically to bring new contributors into CCC projects. This program funds contributors for a three-month period during which they will engage in scoped work. This work can range from developing new features to helping complete OpenSSF Best Practices Badges to 100%. It's an excellent opportunity to integrate reliable, new contributors who can significantly benefit your project.

As this is our first time trying to bring a formal mentorship program to CCC, we welcome any questions or clarifications that can make this easier for you to engage with. Our goal is to support and assist maintainers effectively, so let us know how this would work best for you!

While the LF mentorship program only sets aside funds for mentees in this program, I would love to highlight CCC project's success. In 2022 when I worked with CNCF projects to raise their security scores, we were able to get $50,000 from Alpha Omega to provide additional projects to the projects that participated. If I can get the entire CCC portfolio to raise their scores, that's something I can voice out to the broader LF, and would bring the kind of positive visibility that pulls funding in.

[woju]

Exactly 2 years ago, on this day in 2022, we've answered one potential mentorship candidate this way: https://groups.google.com/d/msgid/gramine-users/YsSzqzaOgoT00Fds%40invisiblethingslab.com .

From our side I don't think the situation changed, every maintainer has priorities set by our respective employers/organisations, and any limited time for mentorship we might have we spend on mentoring interns inside our organisations (or teaching students, in case of Uni professors among us).

[mkow]

+1 to what @woju said, and additionally:

As much as I'd like this to work and see more meaningful contributors, I'm rather skeptical it will succeed, because:

• Gramine is a pretty hardcore low-level project, 3 months is usually what is needed just to onboard to it and be able to meaningfully contribute. I doubt you can develop and finish review of any non-trivial change in that time as a newcomer.
• It's quite hard to find people competent enough to contribute to Gramine without actually causing more work on our side than as if we just did that work by ourselves - usually because of security issues introduced by contributors, bad design, etc.
• All of us work on Gramine through contracts for specific work being done and we're already really low on resources. Spending time on mentoring will make this even worse.
• "helping complete OpenSSF Best Practices Badges to 100%." - A bit off-topic, but I really don't like the approach of security via checking some generic tick-boxes. I'm fine with using such documents as an inspiration of what we could change, but I don't really care about the tick-box percentage we have. What I'd really like to see from time to time is a proposal like "let's do XYZ, because that would have prevented [GRAMINE_ISSUE123, GRAMINE_ISSUE456, ...] bugs from being introduced" (where XYZ can e.g. be "change some conding convention to something", "enable this GCC warning", etc).

TL;DR: Sadly, we probably aren't a good project for newcomers who want to learn something over a short period of time.

[Salkimmich]

No problem at all: this makes sense for your project as well as several others in the CCC portfolio. LF loves to see new contributors as a metric (they do love ticked boxes): but that fails to acknowledge both the security risk and maintainer burnout of bringing new contributors to this type of project. This written feedback/context is extremely helpful, and will allow me to explain to the LF why we should support/engage with security projects very differently from other subfoundations in the LF.

Appreciate and agree with the feedback on the OpenSSF Best Practices Badge, it's hesitance I've gotten even from non-security projects. It's a rational concern to spend maintainer time doing security check-boxes instead of working on your project's focus, especially with limited time/resources.

From LF's simplified view, the OpenSSF badge is the only "security" metric they can standardize across subfoundations and use as a baseline across the entire LF portfolio. From my point of view, it's a great way to bring positive awareness to a project with only about 30 minutes of work. The projects within the CNCF that completed their scorecards in 2022 were able to receive additional funding from Google's Alpha-Omega Security program in 2023, specifically because they demonstrated compliance to the scorecard. If I can get a majority of projects within the CCC to hit those check-boxes to about 90%, I can make a real argument that these are active and security oriented projects - the OpenSSF Badge is tailored to prevent the supply chain risks of large contributor communities: a whole set of problems that the maintainers of security projects usually don't have, by design.

Overall, I fully agree that our support and engagement strategies for security-oriented projects should be tailored more thoughtfully, recognizing the unique risks and demands they have. I will ensure your feedback is communicated clearly to the LF so that we can explore more appropriate and effective forms of support for projects like Gramine - I'm happy to close this specific issue at this time, but would love to continue this conversation around appropriate metrics and support from LF for security projects across the CCC portfolio. Let's get Gramine the support it needs!

[mkow]

Thanks for your understanding!

but that fails to acknowledge both the security risk and maintainer burnout of bringing new contributors to this type of project.

Ah, and maybe one more thing here: we already have a large number of contributions from non-senior developers, which means that we are already doing a lot of mundane reviewing - people don't read our CONTRIBUTING.rst and the styleguide, make a lot of errors and don't fully understand the problem they are trying to fix (and thus the change submitted turns out to only be a workaround). This doesn't work well in low-level projects written in C, which prioritize security. So, that's one more reason why I'm skeptical about bringing more non-senior people to the project. We'd gladly see more senior contributors though, or at least more diligent :)

Appreciate and agree with the feedback on the OpenSSF Best Practices Badge, it's hesitance I've gotten even from non-security projects. It's a rational concern to spend maintainer time doing security check-boxes instead of working on your project's focus, especially with limited time/resources.

Just to be clear, I'm not against the OpenSSF Best Practices Badge recommendations (I think I agree with all of them), and we even got that most basic ("passing") badge, because we were already doing all of that. It's just not a priority and what really matters are the details missed there (e.g. the quality of the memory sanitizers used, etc). E.g. we have the "static analysis" checkbox ticked because Intel runs them, but their output is 99% false positives which just burns our time (the reason for that is that these static analyzers are pretty bad with C coding conventions, and in C you can't convey too much information in the type system, e.g. passing object ownership).

would love to continue this conversation

Sure, I'm open to discussion about this :)

[...] conversation around appropriate metrics and support from LF for security projects across the CCC portfolio. Let's get Gramine the support it needs!

I think the problem with metrics is that evaluation of any reasonable metric requires some actual work, not just checkboxes. A meaningful metric could be e.g.:

• A graph of fixed security bugs vs when they were introduced - this verifies whether the current workflow actually improves the codebase and whether contributors don't introduce more bugs than they fix (i.e. how good is newly committed code). It also shows how long the bugs live. A prerequisite for that is having the project actually audited / reviewed regularly, so you have some detection for the vulnerabilities.
• Categorizing found security bugs, their origin and what could have prevented them - those statistics could show some weak points in the development process, e.g. if most of them come from a specific subsystem, author, or follow a similar pattern.
• What percentage of the security bugs were actually exploitable, and if not then why - this shows whether the hardenings used actually fulfill their role.

This is just a quick list of ideas for statistics from the top of my head, it for sure can be improved. And it's also separate from the discussion what a new contributor could do to improve security, there are a lot of other ideas for that.