Add new PURL type: 'githubactions'

[nicorikken]

In the https://github.com/actions/dependency-review-action the packages can be filtered using purls. This includes githubactions: type purls. There was already a pull-request on this topic in: #243

The current implementation in dependency-review-action is case-sensitive which leads to practical issues, so a clear supported guidance would help.

Given earlier discussions in the pull-request, it should be noted that githubactions are unique in the sense that they can refer to a workflow as well, if I recall correctly, so a file within the repository.

[nicorikken]

Looking at how to describe this, the current implementation in dependency-review-action seems to use fie file path in the name section of the purl spec:

pkg:githubactions/myorg/myaction@v1
pkg:githubactions/myorg/myworkflows/.github/workflows/general.yml@v1

Considering the generic PURL scheme:

scheme:type/namespace/name@version?qualifiers#subpath

The name parts would be:

myaction
myworkflows/.github/workflows/general.yml

The difficulty is that the git repo part is case insensitive, but the path part is.

So actually it would be more correct for the purl spec to use the sub_path section:

pkg:githubactions/myorg/myaction@v1
pkg:githubactions/myorg/myworkflows@v1#/.github/workflows/general.yml

I think this makes more sense, aligns better with the other PURL specs, at the cost of requiring the dependency-review-action to re-implement PURL for this specific use-case.

See testcases how it is implemented in dependency-review-action:

• https://github.com/actions/dependency-review-action/blob/56339e523c0409420f6c2c9a2f4292bbb3c07dd3/__tests__/licenses.test.ts#L110
• https://github.com/actions/dependency-review-action/blob/56339e523c0409420f6c2c9a2f4292bbb3c07dd3/__tests__/licenses.test.ts#L347

One could argue that the repository path is actually part of the name, because it addresses a different action or workflow. But in that case the it should be partially case-sensitive.

This was already partially discussed in #243

[nicorikken]

Valuable comment by @matt-phylum #702 (comment)

So namespace would be anything before the last slash, including github repo path to a specific workdlow or acrion directory.

I'm fine to describe it this way, but that would mean that namespaces could overlap for cases like:

pkg:githubactions/myorg/myaction
pkg:githubactions/myorg/myaction/workflows/workflow-a.yml

Not wrong, but it seems odd not to consider only the org (first part) as the namespace and support slashes in the name.

That could be done by URL-encoding slashes, but as far as I know is not common practice at the moment.

pkg:githubactions/myorg/myaction%2Fworkflows%2Fworkflow-a.yml

Also, I didn't read in the spec that name is only after the last slash.

[nicorikken]

Also, the current github definition defines organization or user as the namespace:

purl-spec/types/github-definition.json

Lines 14 to 15 in 505dca5

	"native_name": "user or organization",
	"note": "The namespace is the user or organization. It is not case sensitive and must be lowercased."

This would not align with the principle that only the part after the last slash would be the name, given the examples:

purl-spec/types/github-definition.json

Lines 28 to 31 in 505dca5

	"examples": [
	"pkg:github/package-url/purl-spec@244fd47e07d1004",
	"pkg:github/package-url/purl-spec@244fd47e07d1004#everybody/loves/dogs"
	]

[nicorikken]

I found how to split name and namespace by reading https://github.com/package-url/purl-spec/blob/505dca561f6d6f1f1f0ebb6b5c36c6aa2516d98d/docs/how-to-parse.md There is no flexibility in defining it. Perhaps URL-encoding in the name section would be nicer, but if we uphold the practice of default slashes, it would imply a more extensive namespace.

[nicorikken]

Looking to define the spec, only URL-encoding seems to make sense, even if not the common practice.

[nicorikken]

I pushed an update, removing workflows and focusing on URL-encoding.