Add new spec for go package URLs

[zpavlinovic]

Hi folks. This proposal is the same as #338, but I don't know how to commandeer that pull request.

The current PURL specification for Go was created before Go 1.11 modules and thus has namespace inconsistencies and lacks semantic versioning.

Although in many cases a module path corresponds directly to the URL of the hosting repository, that is not always true. The URL formed from the module path may be an endpoint that serves a redirect to the true host. This indirection protects projects that for whatever reason must change their hosting provider: their module names will continue to work. Consequently, it is undesirable to encode any aspect of the underlying hosting system as part of the PURL.

In essence, all Go modules form a single namespace. Since it is used by the majority of Go programmers, we propose to represent this namespace by the empty string. Though not included in this commit, other namespaces could be possible and would represent package managers and/or build tools that are alternatives to the go command.

The go type proposed here fixes the current issues by removing the namespace, using valid Go module versions (including pseudoversions), and adds some extra functionality to encode optional information about specific builds (GOOS, GOARCH, etc).

If accepted, all tools maintained by the Go project (such as govulncheck and pkg.go.dev) that surface PURLs will use this new type to provide canonical PURLs for Go modules and packages

To bring everyone up to speed, I wanted to summarize discussion on #338: 1) what this proposal brings to the table and 2) major concerns as well as how those concerns might be addressed. We can add and cross things in this post to keep track of the progress.

Proposal main points

Adding a new PURL type go where we:

• Use only namespace for module information. It is hard and sometimes impossible to figure out what the name should be. As of writing this, there are >57k Go modules that do not start with github.com. In general, there seem to be plenty of modules for which it is unclear what the name is. Special-casing on these will not scale, especially since we can also expect new modules in the future. Some of these examples are particularly tricky, one such being gotest.tools.

• We will use stdlib as the module for artifacts in the go command or standard library. Consistency with other Go tooling breaks the tie with std option.

• Use only versions produced by the Go tooling (or no versions at all). This includes pseudo versions. Hashes should not be allowed. The go command will soon stamp effectively all binaries with a pseudo-version, even in the presence of pending changes and no tags. Though, we will also support (devel) for legacy reasons.

Concerns

• This can be accomplished by updating documentation of golang type. It is not clear how this can actually be achieved. At the very least, it seems that addressing #308 this way would be a breaking change.

• This introduces a breaking change. There are differences between golang and go PURL types such that replacing former with the latter can introduce breaking changes. Let us put aside that this is technically not a breaking change. The golang type predates Go modules. Just as Go as the language and ecosystem evolved, so should its PURL spec. There is sufficient evidence (#63, #196, #294, #308) that golang PURL type creates problems and there should be a type that addresses its shortcomings. If name is the problem, the newly proposed type might also be called gomod?

• Namespace are percent-encoded and that will make things hard to read for users. We feel this is a small price to pay. Further, tools rendering go PURLs can pretty-print the namespace to users.

@jkowalleck @matt-phylum @pombredanne

[jkowalleck]

hello @zpavlinovic ,

This proposal is the same as #338 [...]

so the diff would be : maceonthompson/purl-spec@new-go-spec...zpavlinovic:purl-spec:new-go-spec

---

To be honest, i dont see any need for copying an exiting PR.
if you have things to add to an existing PR, you could simply comment on them or annotate the file changes.

if you have change suggestions on an existing PR, you could annotate the changes alike so

```suggestion
my suggestion here
```

---

I'll vote for closing this very PR, as it simply duplicates an existing one.

[zpavlinovic]

hello @zpavlinovic ,

This proposal is the same as #338 [...]

so the diff would be : maceonthompson/[email protected]:purl-spec:new-go-spec

To be honest, i dont see any need for copying an exiting PR. if you have things to add to an existing PR, you could simply comment on them or annotate the file changes.

if you have change suggestions on an existing PR, you could annotate the changes alike so

```suggestion
my suggestion here

I'll vote for closing this very PR, as it simply duplicates an existing one.

Ok, if you are a maintainer and can update the pull request, I can add the diffs and perhaps you can apply them? Just note that I did this as I am taking over this proposal effort.

[jkowalleck]

I can add the diffs and perhaps you can apply them?

I could, but they would need to be triaged/discussed first. :-D

Just note that I did this as I am taking over this proposal effort.

What do you mean?

[jkowalleck]

Suggested change

	------
	-------------

---

⬆️ this is a demo how a change suggesttion looks like; it is not meant to be applied
the exact "code" i used:

```suggestion
-------------
```

[zpavlinovic]

I can add the diffs and perhaps you can apply them?

I could, but they would need to be triaged/discussed first. :-D

Just note that I did this as I am taking over this proposal effort.

What do you mean?

This proposal and the original one come from the Go team.

I can add the diffs and perhaps you can apply them?

I could, but they would need to be triaged/discussed first. :-D

Just note that I did this as I am taking over this proposal effort.

What do you mean?

Both the original proposer and I are from the Go team, but the original proposer is no longer able to continue with this work, so I am taking over the effort. I don't think there is any way for me to commandeer the original PR itself to make the changes, so I created a new one. Happy to take whatever approach you would like here.

[jkowalleck]

Both the original proposer and I are from the Go team, but the original proposer is no longer able to continue with this work, so I am taking over the effort. I don't think there is any way for me to commandeer the original PR itself to make the changes, so I created a new one. Happy to take whatever approach you would like here.

the original proposer could grant you write permissions on their fork/branch.
this should enable you to take over.

Since you are from the same team, could you ask @maceonthompson for the needed permission?

[maceonthompson]

Happy to grant permissions as needed! @zpavlinovic

[zpavlinovic]

Happy to grant permissions as needed! @zpavlinovic

Ok, let's try that. Thank you Maceo!

[zpavlinovic]

I am having some issues with this, so perhaps somebody can help me out. I cloned the repo of the origin pull request, made the changes to the PR branch (new-go-spec), and then did git push origin new-go-spec. This is what I get:

ERROR: Permission to maceonthompson/purl-spec.git denied to zpavlinovic.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

I apologize if I am making an obvious mistake here.