Utility does not pass a valid iri-reference as value in `externalReference` url field

[qwelol]

Describe the bug

The value "http://private%20package/" is a valid iri-reference.

Screenshots or output-paste

Problematic part of the SBOM file:

  {
     "type": "library",
     "name": "utils",
     "group": "@mui",
     "version": "5.14.17",
     "bom-ref": "pkg:npm/%40mui/utils@5.14.17?vcs_url=git%2Bhttps%3A//github.com/mui/material-ui.git#packages/mui-utils",
     "author": "MUI Team",
     "description": "Utility functions for React components.",
     "licenses": [
       {
         "license": {
           "id": "MIT"
         }
       }
     ],
     "purl": "pkg:npm/%40mui/utils@5.14.17?vcs_url=git%2Bhttps%3A//github.com/mui/material-ui.git#packages/mui-utils",
     "externalReferences": [
       {
         "url": "https://github.com/mui/material-ui/issues",
         "type": "issue-tracker",
         "comment": "as detected from PackageJson property \"bugs.url\""
       },
       {
         "url": "git+https://github.com/mui/material-ui.git#packages/mui-utils",
         "type": "vcs",
         "comment": "as detected from PackageJson property \"repository.url\" and \"repository.directory\""
       },
       {
         "url": "http://private%20package",
         "type": "website",
         "comment": "as detected from PackageJson property \"homepage\""
       }
     ]
   },

Util output:

Expected behavior

Validation passed

Additional context

At first I thought that the problem was in the sbom file generator, and created a issue for it. Perhaps it will also be interesting

[mrutkows]

@qwelol The utility is validating (using a JSON, draft 7 schema validator lib.) against the the JSON schema file published by by the cyclone DX Spec. repo. ... the utility is just reporting the error as returned by the validation library the utility uses when passed a field with:

"format": "iri-reference",

for fun we can look at what IETF says (as it is hard to believe that using the http protocol in your example does not have restrictions for what goes in effectivelt the domain name (or iauthority):

According to IETF docs: https://www.ietf.org/archive/id/draft-ietf-iri-3987bis-13.pdf whose ABNF indicates:

IRI = scheme ":" ihier-part [ "?" iquery ] [ "#" ifragment ]

ihier-part = "//" iauthority ipath-abempty 
                      / ipath-absolute
                      / ipath-rootless
                     / ipath-empty

where:

iauthority = [ iuserinfo "@" ] ihost [ ":" port ]
ihost = IP-literal / IPv4address / ireg-name
ireg-name = *( iunreserved / sub-delims )

and

iunreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" / ucschar
ucschar = %xA0-D7FF / %xF900-FDCF / %xFDF0-FFEF
/ %x10000-1FFFD / %x20000-2FFFD / %x30000-3FFFD
/ %x40000-4FFFD / %x50000-5FFFD / %x60000-6FFFD
/ %x70000-7FFFD / %x80000-8FFFD / %x90000-9FFFD
/ %xA0000-AFFFD / %xB0000-BFFFD / %xC0000-CFFFD
/ %xD0000-DFFFD / %xE1000-EFFFD

sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="

noting that percent sign is:

x0025

[qwelol]

@mrutkows Hmm, i tried to create issue on validation library. But it seems to no longer maintained. Maybe try another tool?

[mrutkows]

@qwelol

@mrutkows Hmm, i tried to create issue on validation library. But it seems to no longer maintained. Maybe try another tool?

There really is no other library to use and the ABNF shared above suggests the assertion that encoded space chars is valid for an iauthority may not be valid (esp. when using http as a protocol prefix).

[mrutkows]

@qwelol Please read the article which clearly explains it without involving specification interpretation: https://thedomainrobot.com/blog/can-domain-names-have-spaces/

It’s a common misconception that spaces can serve as separators in domain names, akin to their function in written text. However, this is fiction. The fact is, the technical specifications of domain names, as outlined by the Internet Corporation for Assigned Names and Numbers (ICANN), specifically disallow spaces. The reasoning is twofold: to maintain a uniform navigational system and to prevent the potential for errors when accessing websites.

If not using an http or https protocol prefix as part of and IRI and perhaps using another protocol prefix, may bring in other specifications (schemas which reflect in library-specific impls.) that narrow what is considered "valid". I am not saying strict IRI validation should impose additional restrictions, but can speak with some confidence that an externalReference is intended to have a value that is network addressable (allowing for security creds. and ACLs for https).