raboof commented on issue #614: URL: https://github.com/apache/tooling-trusted-releases/issues/614#issuecomment-3926269259
It would indeed be very good to have stronger conventions around the use of Purl at the ASF. > I do not like the idea of an ASF specific type, it doesn't feel like a PURL type to me. Let's work together on something that works for C/C++ I much agree: * For components that are "part of an ecosystem" like pypi or maven (e.g. Pekko) we should use the ecosystem Purl to refer to those components (e.g. `pkg:maven/org.apache.pekko/pekko-actor`) - we should _not_ introduce other ways to refer to those same components. * For components that are not published "in an ecosystem", like say the Tomcat installation package, I think we should not put energy into defining an `asf` purl, but instead follow the conventions that are developing in https://github.com/package-url/purl-spec/issues/784 / https://github.com/package-url/purl-spec/issues/516 . (I'm not convinced this should be TEA-based (that seems like a circular dependency: TEA should depend on Purl, Purl should not depend on TEA) - but that's something we should discuss there, not here) > Let's not forget the most important two PURLs: the ASF release as a whole Do we have a strong reason to need a Purl for "the ASF release as a whole"? One ASF release can publish multiple components (for example releasing https://github.com/apache/pekko releases `pekko-actor`, `pekko-cluster` and a bunch of others), which all have Purls. I think it would be valuable if ATR could surface the knowledge that "This release includes these Purls", but I haven't seen a use case for a single Purl for that release yet. > and the "official" asf open source release. Similarly, I don't think we need a separate Purl for a 'source release'. As @ppkarwasz mentions above in https://github.com/apache/tooling-trusted-releases/issues/614#issuecomment-3847098025 , source packages for the vast majority of use cases shouldn't have a _separate_ Purl. A Purl defines a 'software component', so for typical use cases it's accurate to say the convenience binary and the source package both 'contain the same software component(s)', i.e. 'contain the same Purl(s)'. If you must you could document finer-grained information around provenance in SBOMs/TEA and such, but that should be the exception, not the norm, and likely mostly outside of ATR. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
