go: valid purl but incorrect name

[Mikcl]

The purls syft generates for golang are valid but provide the incorrect name

---

Example:

https://pkg.go.dev/github.com/russross/blackfriday/[email protected]

Syft generates the purl: pkg:golang/github.com/russross/blackfriday/[email protected]

When parsed according to the purl spec, the namespace of this package is github.com/russross/blackfriday and the name is v2

You would expect the name (after decoding) to be github.com/russross/blackfriday/v2 rather than just v2

---

The purl is incorrect as the name field is wrong.

The correct name field is:

A module path is the canonical name for a module

Via https://go.dev/ref/mod

The module path must uniquely identify your module

Via https://go.dev/doc/modules/gomod-ref

To work around this "bug", you could use the following formula to get the name.

namespace "+" name = canonical-name

but this is calculating the canonical name which syft should provide in the purl.

why does it matter what's in name vs what's in namespace?

Every downstream user needing to workaround it (and the implications of possibly using the wrong name in databases/searches).

From reading the literature, it seems the action to take is to:

• not using the namespace in golang purls, besides they're optional.
• Percent encoding the canonical name.
• Other tools like ORT already do so.

There is perhaps the question of what value a "namespace" would bring? however I think this is a mutually exclusive problem

For even more references see:
https://go.dev/doc/modules/developing
https://go.dev/doc/modules/managing-dependencies

[tgerla]

Hi @Mikcl, thanks for the report. We have looked into this and there are definitely some edge cases around purl generation that affect us, and we aren't exactly sure how to handle them based on our read of the purl spec. We will put this into our backlog for further investigation. We'll keep an eye on your linked issue (package-url/purl-spec#63) -- it looks like there is some active discussion now, and we will watch for consensus there. Let us know if anything else comes up!

[Mikcl]

Hi @tgerla , thanks for responding.

The linked issue in package-url/purl-spec#63 has had more discussions.

I think a lot of the "facts" and research has been mentioned in the issue.

However it seems like there is no consesnus yet.

I would image that the syft's team input in that issue will be highly welcomed, and may help to form a consensus.