Proposal: New working group for source package ecosystems

[jchestershopify]

Folks involved in RubyGems, PyPI and npm have been informally swapping notes over the past few months as we have each pursued our own goals. After some back and forth, we joined a single call and began to more seriously compare experiences and problems.

From that meeting has arisen the idea that we would like to form a proper working group, in order to maintain momentum on sharing ideas, designs and solutions to obstacles. This seems to be a good fit for the OpenSSF, as source package systems represent a very large fraction of the overall software supply chain.

I see this working group being less about end-to-end security (for which Supply Chain Integrity WG is already responsible) and more specifically scoped to source package managers. We have a lot of nitty gritty details to discuss that would bog down existing working groups, but which nonetheless are profitable to discuss regularly.

My request is:

1. TAC signals whether or not such a working group would be acceptable in principle, and
2. What conditions or requirements must first be met in order to adopt such a working group into the OpenSSF's oversight.

[dlorenc]

I am strongly in favor of this! The process is documented roughly here: https://github.com/ossf/tac/blob/main/working-group-lifecycle.md#to-become-incubating

In short, you can just get going with public meetings and notes. I'm happy to help "host" it under the Supply Chain Integrity WG until you get the five meetings done and are ready to propose the actual group.

[jchestershopify]

I think there's enough to discuss that we might need our own dedicated time. From my reading that means we go ahead and keep meeting, and then when we reach 5 meetings we come back and bump this issue.

[dlorenc]

I think there's enough to discuss that we might need our own dedicated time. From my reading that means we go ahead and keep meeting, and then when we reach 5 meetings we come back and bump this issue.

Yeah sorry - I didn't mean to cover it in the existing meeting, just from the OSSF "sponsorship" angle if you'd like to use the shared calendar, slack and zoom while you make it through those 5 meetings.

[lukehinds]

Would be nice to see a problem statement come out of this and what the call to action would be. What are the pain points the group would seek to address.

[bobcallaway]

I'm strongly in support of this - sharing experiences, design challenges, and cross-package-manager community feedback makes a lot of sense. I agree with @lukehinds on scoping out a problem statement and scope would be great.

[AevaOnline]

I'm also in support of encouraging collaboration between package manager ecosystems.

I'd like to see a "mission statement" or "scope" for this effort, and then see how it grows over the next few meetings, to help figure out where to locate the work within the OpenSSF.

[MylesBorins]

I'd love to participate in the work as a representative of npm and GitHub. We are currently working on support webauthn + enforcing 2FA and speccing what OIDC support would look like for the registry. It would be great to have a neutral place to collaborate across registries and try and make some of these experiences consistent (if possible).

[Eh2406]

I would love to know when meetings are. I will do my best to attend. I am on the Cargo Team helping to maintain Rusts package manager.

[betarelease]

+1 I would love to join meetings and share what we are learning as well. Please share engagement details here.

[MylesBorins]

Speaking to @AevaOnline's ask

I'd like to see a "mission statement" or "scope" for this effort, and then see how it grows over the next few meetings, to help figure out where to locate the work within the OpenSSF.

I'd like to propose a mission of

"A vendor neutral space for the stewards of source package ecosystems to collaborate and share learnings and roadmaps to better align."

For scope I think it would be good to stick to:

• Sharing of roadmap and implementation specifics
• Identifying problem spaces and planned solutions
• Identifying opportunities for shared infrastructure or implementation
• Identifying opportunities to align on policies and the "role" of the ecosystem steward
• Ensuring that the "last mile" of software distribution is secure.

What I would like us to avoid is "design by committee" solutions to problems.

[trevrosen]

+1 have been in the informal meetings and happy to join formalized group as a representative of GitHub.

[pete2160]

Would like to attend one of the informal meetings to see how we can participate / contribute from a ProdSec perspective and if it is corresponding to / with other working groups.

[simi]

Hello, I'm contributor to RubyGems/RubyGems.org projects. I can attend one of the initial meetings to evaluate my usefulness as well.

[trishankatdatadog]

Very cool! So how should we go about the first meeting?

[di]

I can just make our recent call a recurring meeting if that sounds good to everyone.

[jchestershopify]

For context, that first meeting was 9am-10am North American Eastern Time, or 3pm-4pm CET.

[di]

Yeah sorry - I didn't mean to cover it in the existing meeting, just from the OSSF "sponsorship" angle if you'd like to use the shared calendar, slack and zoom while you make it through those 5 meetings.

Dan and I tried to set up an event on the shared calendar w/ myself as owner but it didn't work. Is there someone from the TAC that could help with this?

[MylesBorins]

What day would the meeting be planned for?

[dlorenc]

I think we need to ask the LF staff to create it correctly. I'll start a slack thread.

[joshuagl]

For folks following this thread, it looks like the first meeting is scheduled for tomorrow March 2nd at 7am 6am Pacific.

[jchestershopify]

My calendar shows it as 9am-10am ET, which would be 6am-7am PT in my reckoning. 2pm-3pm GMT and 3pm-4pm CET.

[MylesBorins]

Is there a public calendar I can reference for details and to confirm time?

[jchestershopify]

It looks like it was added to the OpenSSF calendar, which you can get from here.

[joshuagl]

My calendar shows it as 9am-10am ET, which would be 6am-7am PT in my reckoning. 2pm-3pm GMT and 3pm-4pm CET.

Thank you

[di]

We also have a #securing_software_repos channel in the OpenSSF slack as well (https://slack.openssf.org/).

[david-a-wheeler]

Figuring out a scope/mission is an important step. I suggest that the first meetings work out, in part, at least one specific result the nascent group wants to accomplish.

Don't get me wrong, I think discussion & coordination is important! But having something concrete to work on is also important. We don't want this to just be "jawing with no action".

For example: The group could create a combined list of security mechanisms or properties that at least one repo or package manager has, determine which other ones have/don't have the mechanism/property, and then propose adding those mechanisms to the other ones where appropriate. It doesn't have to be that specifically, but I'd like to see a concrete result eventually getting produced.

[dlorenc]

I normally agree @david-a-wheeler, but think this one might be a special case because this group is made up of maintainers of existing registries. Simply giving them a neutral space to talk is very valuable, and they're already doing the entire ecosystem a huge service and producing concrete results, just separately.

I really like @MylesBorins's suggested mission:

"A vendor neutral space for the stewards of source package ecosystems to collaborate and share learnings and roadmaps to better align."

If we find opportunities to collaborate, then great! If not, then they at least get a place to discuss common problems. I don't think we should try to force anything.

[trishankatdatadog]

Hmm, this is a difficult one: while we don't want to force repositories what to do, I think we should at least agree on things like common signing formats (e.g., DSSE) and solutions so that there is some interoperability, not to mention ultimately shared strengths. While each repo can begin with different solutions as they see fit, I think some level of shared convergence is important so that, for example, we can write open source tooling that can access supply chain security for packages without resorting to different logic for each repo. Imagine if each website implemented TLS differently, so that browsers had to write different logic for different websites: it would be undesirable to have that situation for codesigning. Perhaps this is something we should discuss in the first few meetings.

[brianf]

Jumping in from the Maven Central & Sonatype side...

[iamwillbar]

I think this a great proposal and fully support it. When I was at GitHub we hosted a PackCon event and invited package manager/registry maintainers to discuss common issues and approaches. Security was a large part of this discussion and despite the significant implementation differences between package managers there was a significant overlap in the underlying problems trying to be solved.

[bobcallaway]

FYI - a new repo for the proposed WG has been created at https://github.com/ossf/wg-securing-software-repos

[MylesBorins]

thanks @bobcallaway. How do folks go about requesting membership? Is the membership list of working groups displayed publicly anywhere?

To be clear I think it is good to document this kind of stuff publicly, just curious process as I'm unfamiliar

[simi]

I'm wondering as well how to join Slack for example, since I don't have email at allowed domain.

[dlorenc]

thanks @bobcallaway. How do folks go about requesting membership? Is the membership list of working groups displayed publicly anywhere?

Since meetings are open to the public there's no real concept of a "member". Some WGs choose to maintain a list of participants which are basically just people that choose to add their name to a public list.

[jchestershopify]

It's open in practice, but the proposed CHARTER.md does require a named list of "Maintainers" in order to function. One of my action items for this week is to pull out attendees of >2 meetings from the minutes to form the basis for that list.

[di]

@simi There's an invite link, I've made a PR to add it to the WG README: ossf/wg-securing-software-repos#5

[bobcallaway]

The creation of the WG was approved on April 13, 2022, so closing this :)