Merging projects

[sjn]

During the on-boarding call yesterday, Peter suggested it might be an idea to merge some of the projects that have major overlap.

Our current projects as of 2023-08-01 are:

• CPAN Privacy and Compliance
• CPAN Provenance & Supply Chain Security
• CPAN Rich Metadata & Dependencies
• CPAN Security Outreach & Information
• CPAN Security Patch Tooling
• CPAN Software Bills of Materials
• CPAN Software Composition Analysis
• CPAN Transparency Logs
• CPAN Vulnerability Index
• CPAN-SEC Governance, Policy & Funding

I'm a bit unsure of what's sensible here, as the current list is something that I and a friend concocted just to get this project rolling. What do you think? Do any of these have enough overlap/natural fit so it makes sense to merge them?

[sjn]

One candidate is...

• CPAN Rich Metadata & Dependencies + CPAN Software Bills of Materials = CPAN Metadata & Software Bill of Materials

CPAN Rich Metadata & Dependencies

Short description:

Evolving CPAN publisher and package metadata so they live up to increased downstream requirements, including PURL (Package URL) support, and updates to CPAN::Meta::Spec.

README:

We work on package metadata specs exploration, including updates to CPAN::Meta::Spec.

This includes the way we track dependencies, where the goal is to update the CPAN ways so that we can produce a complete set of dependency information that is usable across package ecosystems.

E.g. – Imagine a CPAN Distribution that is a shim for another party's compiled C library. How do we specify this dependency in a standardized manner? What other dependencies do we expect to be in place for the software to be reproduced correctly? How about network services, environment or system expectations, or build-time requirements like compiler features or kernel features?

CPAN Software Bills of Materials

Short description:

Tooling for creating and managing standard SBOM objects like OWASP CycloneDX and SPDX, using existing CPAN metadata

README:

Tooling for creating SBOM objects based on CPAN::Meta information and more.

Check also out our discussion channel on the OWASP CycloneDX slack server.

[Ovid]

Isn't CPAN Provenance & Supply Chain Security also kind of a duplicate for the SBOM?

[garu]

Is this really an issue? Why?
Also, did Peter come up with any mergeable candidates himself?

I'd rather we focus on each project's content at the moment. If any of them do overlap, it'll become clear and we can act then.

[sjn]

Not a big issue, just something that came up when I said that we're still figuring out how we're organizing ourselves, and there's always room to improve things if we find something odd (including in how we organize ourselves 😁)

[sjn]

From IRC;

16:17 <@garu> sjn I wonder if "CPAN Rich Metadata & Dependencies" should be merged into 
              "CPAN Provenance & Supply Chain Security". If not, I think "CPAN Provenance & 
              Supply Chain Security" should have a better description

CPAN Provenance & Supply Chain Security

Short description:

Establishing a trusted publishing infrastructure, including tooling and integration with https://in-toto.io/ and SLSA

README:

Here, we look into ways to improve the chain-of-trust in the PAUSE/CPAN publishing pipeline. Possible sources for inspiration include SLSA and in-toto, and The Update Framework.

[sjn]

Maybe we should refer to the definitions in https://owasp.org/www-community/Component_Analysis in a larger extent?

[sjn]

I've ended up merging CPAN Rich Metadata & Dependencies into the CPAN Software Bill of Materials project, and renaming it to "CPAN Metadata & Software Bills of Materials"