Add purl specification

[voltone]

Would you be interested in formally defining and documenting the purl format for Hex packages? I believe this could help with SBOM tooling and vulnerability tracking.

[ericmj]

Is it only a specification or would we need to do something to implement this?

[voltone]

It's just a specification. Once the purl format for Hex packages has been formalised, tooling can be developed outside Hex that builds on it: for instance a Mix task that builds a CycloneDX BOM for use with OWASP Dependency-Track, or a Dependency-Track plugin that can deconstruct Hex package purls to query the hex.pm API to check for updates.

[voltone]

Maybe @sparrell or @GriffinMB want to weigh in as well, as we've been discussing supply chain security in the EEF Security WG

[ericmj]

This sounds like a good addition. I will read up on the specifications and your links and get back to you.

[sparrell]

I think providing ability to generate SBoM is a good idea. I predict this will be a requirement at some time in the future for anyone wanting anything claiming to have some security. It already is a requirement in financial industry and some others. Since we are a naturally more secure ecosystem, I think promoting security aspects will increase adoption of our ecosystem - so doing it is good marketing as well as good security.

In general I do think we should provide an SBoM with all software. What format could be debated (purl/sdpd/swid/cyclonedx) but the more complete the better (ie full tree not just one hop). At what point in tool chain could also be debated. I'm for doing whatever can be done easily at this point and we'll build on it.

[sparrell]

Should this be an issue instead of buried in a comment? I had trouble finding this since I looked for it in issues - which is just operator error on my part, but I might not the only one,

[voltone]

@sparrell this is a PR, that's why it doesn't show up under Issues. The changes, if approved, would add purl for Hex packages to the Hex specs. I imagine we'll then want to create a PR to add it also to the official purl repo, alongside the definitions for NPM, Maven and RubyGems.

At that point others can take over and create SBoM tooling, such as a Mix task for building a CycloneDX file with both Hex and NPM packages (calling cyclonedx-bom for the latter). I don't think such a tool needs to be an official Hex thing, it can be a 3rd party package that people can add.

[voltone]

(sorry, must have hit an unexpected GitHub keyboard shortcut)

[voltone]

I'm implementing a CycloneDX generator Mix task, and find myself wondering whether names (package, organisation, repo) are case sensitive. In practice it seems package names are case insensitive, while organisation and repo names are case sensitive, but I can't find any reference for that in the specs.

[ericmj]

They should all be case insensitive.

[voltone]

Ok, I'll update my purl proposal to reflect that. But please note that this does not appear to be implemented consistently in the tooling: both dependency resolution and the web UI treat the organization as case-sensitive...

[voltone]

FYI, I just published this package to generate an SBoM for a Mix project in CycloneDX format, with 'purl' package identifiers according to the spec proposed in this PR.

And yes, I realise I'm using one or two internal Mix and Hex APIs. If this tool proves useful I may want to have a chat with the Hex and Elixir maintainers to properly expose the necessary APIs.

[voltone]

I've been wondering whether to add an 'arch' qualifier, for packages with native code, e.g.:

pkg:hex/bcrypt_elixir@2.0.3?arch=amd64

[michalmuskala]

Usually packages themselves don't contain compiled binary code but just sources so I don't think it would be appropriate

[voltone]

@michalmuskala the files being pulled in during the build process are not architecture dependent, but the build artefacts (e.g. a release) are, and that's what the SBoM describes.

I don't think it's terribly important, but it is at least theoretically possible that a vulnerability only applies to certain architectures, and thanks to Nerves Hex packages get built for more than just x86/amd64...

[ericmj]

All nerves packages that are architecture specific have the architecture in the package name afaik.

[ericmj]

@voltone Is this ready to be merged?

[voltone]

Yeah, it would be great to make this official. Once it's merged I'll create a PR against the purl spec's Known purl types section