SCM URLs for `git@server:repo` (without an explicit schema like `ssh://`) do not render right

[jimklimov]

Current Behavior

In my SBOM documents I have "components[] / externalReferences[]" as lists of objects like { "type": "vcs", "url": "scm:git:git@server:group/repo.git" } where the URL-ish part git@... does not have any schema like git+ssh:// or plain ssh:// (its just is as it comes from pom.xml files).

In Dependency-Track web-ui such links are rendered verbatim, e.g. scm:git:git@github.com:lukas-krecan/JsonUnit.git/json-unit-assertj so the browser leads nowhere - and there's even no schema prefix to register a handler for, I think (musing about scm:git:// prefix for users to somehow deal with if desired, or smart rewrite into the more standard git+ssh://git@github.com:lukas-krecan/JsonUnit.git/json-unit-assertj right away?)

Also note that URL entries mis-written as just git@... without an scm:git:... prefix are rendered as relative links under the Dependency-Track server root URL (e.g. http://localhost:8080/components/git@...), I suppose these links should always be absolute even if useless.

Steps to Reproduce

1. Upload a BOM file with some non-HTTP VCS URLs for components
2. Go to Component details in Web-UI
3. On the right, open a drop-down for links; explore those marked VCS

Expected Behavior

• VCS URLs are always emitted as absolute in HTML markup (VCS link strings relative to DT server are certainly useless)
• If possible, ensure a standard schema prefix that applications/browsers could register OS handlers for, and open a suitable client application/IDE/...
• Perhaps (have a toggle to) assume that git@... links without a prefix/schema mean git+ssh:// in fact

Dependency-Track Version

4.11.7

Dependency-Track Distribution

Container Image

Database Server

PostgreSQL

Database Server Version

No response

Browser

Mozilla Firefox

Checklist

• I have read and understand the contributing guidelines
• I have checked the existing issues for whether this defect was already reported

[nscuro]

For well-known patterns and hosts we can probably re-write those links before rendering (i.e. git+ssh://github.com -> https://github.com. However that will not always work, for example if the VCS host uses non-standard ports for HTTPS or SSH. Rewriting git+ssh://example.com:2222 to https://example.com:2222 might simply not be correct.

In cases where we don't recognize the protocol as "linkable", and we also cannot re-write it, we should probably render it as non-clickable string instead.

[jimklimov]

I suppose different toggles can be made (or sed-like replacement regexes for users to edit), but I did not mean rewriting ssh git URLs into http(s) at unspecified ports - not out of the box.

Internally we use client certificate based auth for HTTPS GitLab, so checkouts over HTTP are a no-go with standard client; over SSH are easy however. So no schema replacement here.

What I meant was to add a schema prefix (maybe guess per ^git@.* match, or use the ^scm:SCHEMANAME: info from valid BOM entry contents) for VCS "URLs" that had no schema originally.

If the href is currently unclickable - so be it (that's something that URL handler registration in browser/OS can address independently of DT).