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