purlkit's golang profile requires a namespace, so single-segment Go modules mint as pkg:generic and lose vulnerability matching #67

Found while verifying the maturity plan's definition-of-done criterion 2 against a real self-scan of bomly-cli. Worth looking at before 0.9.5 is cut.

What happens

typeProfiles in purlkit/typeprofile.go marks golang as namespaceRequired: true. A Go module path with no / therefore fails Validate, and node construction falls back to a generic identity:

sdk.NewDependencyNode({Ecosystem: go, Name: "go4.org", Version: "v1.0.0"})
  -> "pkg:generic/[email protected]?bomly_source_type=golang"

purlkit.Validate(parse("pkg:golang/[email protected]"))
  -> invalid package URL: type "golang" requires a namespace

For comparison, github.com/google/uuid and gopkg.in/yaml.v3 mint correctly as pkg:golang/....

go4.org is not contrived — it is a real module in bomly-cli's own go.sum, and it is the single component out of 317 in a self-scan that comes out as pkg:generic.

Why it matters

The identity is the node ID, so this propagates everywhere: scan JSON, SBOM exports, baselines, diff. The concrete harm is vulnerability matching — OSV is queried by package URL, and a Go module published as pkg:generic will not match a pkg:golang advisory. A vulnerable single-segment module would be silently unreported, which is the failure mode this tool exists to prevent.

The ?bomly_source_type=golang qualifier on the fallback shows the code knew the ecosystem and emitted generic anyway.

Why the rule looks wrong

• A Go module path is not required to contain a slash. go4.org is a valid, published module; a rule that makes it unrepresentable as a golang purl cannot be what the spec intends.
• packageurl-go imposes no namespace requirement on golang — its structural validation covers only chrome-extension, cpan, julia, otp, swift, vcpkg and vscode-extension. So the requirement is this table's, not the library's.

Please check the golang row against the purl-spec PURL-TYPES text. If the spec marks the namespace optional, the row should be dropped from namespaceRequired.

The wider point

This is the delegation rule's own worked example, in the same shape as the Streebog digest case that motivated it: a hand-transcribed specification table that was plausible when written and is quietly lossy in production. It is worth asking whether the whole typeProfiles map wants a differential test against the spec's published type list, so a wrong or stale row fails a test rather than silently degrading an identity.

Suggested acceptance

• pkg:golang/[email protected] validates.
• sdk.NewDependencyNode mints pkg:golang/go4.org@... for a single-segment Go module path, with no bomly_source_type fallback qualifier.
• A test enumerating each namespaceRequired row against a real published package of that type with no namespace, so the next wrong row is caught by a test rather than by a self-scan.