pURL not accepted as PackageDownloadLocation

[rnjudge]

I am trying to create an SPDX tag-value document for a container. In Tern, we represent a container image as a package in the document. In trying to represent the PackageDownloadLocation for the container, I am hoping to use the pURL as mentioned here:

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

Contextual Example:
pkg:docker/debian@sha256:2f04d3d33b6027bb74ecc81397abe780649ec89f1a2af18d7022737d0482cefe

When I do that, the tooling gives me the following error:

Analysis exception processing SPDX file: Invalid download location pattern 
pkg:docker/photon@sha256:fbdae32f534858727fa855af8d548dfa5d98872ef81f466790f7c302a46e8384.   
Must match the pattern ^(NONE|NOASSERTION|(((git|hg|svn|bzr)\+)?(http:\/\/www\.
|https:\/\/www\.|http:\/\/|https:\/\/|ssh:\/\/|git:\/\/|svn:\/\/|sftp:\/\/|ftp:\/\/)?
[a-z0-9]+([\-\.]{1}[a-z0-9]+)*\.[a-z]{2,5}(:[0-9]{1,5})?(\/.*))|
(git\+git@[a-zA-Z0-9\.]+:[a-zA-Z0-9]+)|(bzr\+lp:[a-zA-Z0-9\.]+))$

Is there an error in the validation tool or is my understanding of the spec wrong? Should I just use NOASSERTION for the PackageDownloadLocation since I can't represent it using "locations in version control systems such as Git, Mercurial, Subversion and Bazaar, and specifies the type of VCS tool using url prefixes: git+, hg+, bzr+, svn+ and specific transport schemes such as SSH or HTTPS."" as the spec asks here?

[goneall]

Is there an error in the validation tool or is my understanding of the spec wrong? Should I just use NOASSERTION for the PackageDownloadLocation since I can't represent it using "locations in version control systems such as Git, Mercurial, Subversion and Bazaar, and specifies the type of VCS tool using url prefixes: git+, hg+, bzr+, svn+ and specific transport schemes such as SSH or HTTPS."" as the spec asks here?

Puurl can be used in the ExternalRef field (not to be confused with ExternalDocumentReference).

For example:

ExternalRef: PACKAGE-MANAGER purl pkg:docker/debian@sha256:2f04d3d33b6027bb74ecc81397abe780649ec89f1a2af18d7022737d0482cefe

The packageDownloadLocation doesn't take a purl format according to section 3.7. It only accepts specific version control schemes.

[rnjudge]

Thanks @goneall! Sounds like NOASSERTION is our best bet for this particular use case.

[rnjudge]

@goneall is there any chance of proposing that package download location accept purls? For the container use case especially, this is highly relevant.

[goneall]

is there any chance of proposing that package download location accept purls?

This would be a change to the spec - certainly something to be considered.

In the 3T SBOM discussions, we talked about a separate dedicated property called ArtifactURL. That way you could have a download location where the code could actually be accessed and a separate purl property. Would this work for the container use cases?

[rnjudge]

@goneall ArtifactURL that holds a purl value for packages will work for the container use case. Thanks! Will this be in the 3.0 spec?

[goneall]

Will this be in the 3.0 spec?

I expect it will be in the 3.0 spec.

[goneall]

@rnjudge Since this looks spec related, I'm going to go ahead and close this issue