Encode the origin of the package in PURL

[Shnatsel]

Fixes #501 and #231

Supersedes #69

[kylewillmon]

It's a mistake to believe that this is only used for form submission. This same exact encoding is used to set the query string of a URL (because that's where form submission data goes when the method is GET anyways).

The spec even states that this set will be used for anything in the URLSearchParams class, which is used for generating query strings (or body data in the case of POST form submission).

That is why, for example, the whatwg-url package (which is synchronized with the WHATWG URL spec), encodes these characters when set using the searchParam attribute. For example:

import { URL } from 'whatwg-url';
const x = new URL('pkg:generic/bitwarderl');
x.searchParams.set('vcs_url', 'vcs_url=git+https://github.com/rustsec/rustsec.git@6f82509cb43a')
console.log(x.toString());

Outputs:

pkg:generic/bitwarderl?vcs_url=vcs_url%3Dgit%2Bhttps%3A%2F%2Fgithub.com%2Frustsec%2Frustsec.git%406f82509cb43a

It is fine to use characters such as + unencoded in the query string, but not if you are parsing that query string as search parameters (as PURL does).

[Shnatsel]

Even that cannot be used to produce the official example of ?vcs_url=git%2Bhttps://git.fsfe.org/dxtr/bitwarderl%40cc55108da32, because the application-x-www-form-urlencoded set encodes : and / but they are left unencoded in the official example.

[kylewillmon]

I suppose it would be a question to the PURL maintainers to see if they actually intend qualifiers to be interoperable with URLSearchParams. If so, mandatory percent encoding of + should be mentioned in the spec...

[lfrancke]

@pombredanne is this something you can maybe weigh in on?

[Shnatsel]

Turning into a draft until the reproducibility issues are addressed.

[Shnatsel]

I've implemented relative paths for packages within the workspace to allow for more reproducible builds (at least in PURLs, there are other aspects of the SBOM that are not reproducible).

This needs even more tests but other than that it's ready to go, PTAL.

[lfrancke]

For full reproducability we have another issue

[lfrancke]

The clippy warnings are only in test code but still. Otherwise looks good. Thanks for the tests and the attention to detail!

[lfrancke]

Suggested change

	&Utf8Path::new("/foo/bar"),
	Utf8Path::new("/foo/bar"),

[lfrancke]

Suggested change

	let purl = get_purl(&git_package, &git_package, &Utf8Path::new("/foo/bar"), None).unwrap();
	let purl = get_purl(&git_package, &git_package, Utf8Path::new("/foo/bar"), None).unwrap();

[lfrancke]

Suggested change

	&Utf8Path::new("/home/shnatsel/Code/cargo-cyclonedx/"),
	Utf8Path::new("/home/shnatsel/Code/cargo-cyclonedx/"),

[lfrancke]

Suggested change

	&Utf8Path::new("/home/shnatsel/Code/cargo-cyclonedx/"),
	Utf8Path::new("/home/shnatsel/Code/cargo-cyclonedx/"),

[lfrancke]

Suggested change

	&Utf8Path::new("/home/shnatsel/Code/cargo-cyclonedx/"),
	Utf8Path::new("/home/shnatsel/Code/cargo-cyclonedx/"),

[lfrancke]

Suggested change

	&Utf8Path::new("/foo/bar/"),
	Utf8Path::new("/foo/bar/"),

[lfrancke]

This means #69 can be closed, right?