1 reply
Anyone know why the python package isn't letting me get a url from a purl?
@app.command()
def get(purl: str):
parsed = PackageURL.from_string(purl)
typer.echo(f"Grabbing {parsed}")
typer.echo("A", purl2url.get_url(purl))
typer.echo("B", purl2url.get_url(parsed.to_string()))
typer.echo("C", purl2url.get_url(str(parsed)))
typer.echo("D", purl2url.get_url(parsed.to_string()))For this I've tried the two following PURLs:
And for both of them I successfully parse and can print the purl, but the A, B, C, D echos after that are all empty (but don't crash).
What is the preffered way to contribute? Should I open an issue to discuss my ideas, discuss them here or start writing the specifications I think are needed and then discuss in the PR?
Specifically I'm looking into creating an SBOM for a Windows 10 System and would like to add a type for Store Apps. The data you can get on those is very uniform and it should be easy to create a specification for those.
Appearantly there is https://lazyadmin.nl/it/install-microsoft-store-apps-without-store/ ^^
So you can download it apps without using the store, but it gets a bit involved ^^"
I'm attempting to create an open-source universal downloader of sorts, based on PURL's. I've done this before in another life, and it was a PITA to come up with all the different URI's for the various artifact providers, the package-url spec seems very similar to what we ended up creating in house, and I'd love to build ontop of it.
Couple of questions:
- is there already a known tool that will download artifacts given a PURL? (preferably a standalone binary written in Go?)
- my first use-case is to download a github release asset (
scrutiny-collector-metrics-windows-4.0-amd64.exeattached to this release https://github.com/AnalogJ/scrutiny/releases/tag/v0.4.8), is there a existing PURL format for something like that? - if not, which of the following would make the most sense?
pkg:github/AnalogJ/scrutiny@v0.4.8?file_name=scrutiny-collector-metrics-windows-4.0-amd64.exe&type=release_assetpkg:github/AnalogJ/scrutiny@v0.4.8?type=release_asset#scrutiny-collector-metrics-windows-4.0-amd64.exe
@AnalogJ Hey :) looks great!
is there already a known tool that will download artifacts given a PURL? (preferably a standalone binary written in Go?)
That's a goal of https://github.com/nexB/fetchcode/ (in Python)
my first use-case is to download a github release asset (scrutiny-collector-metrics-windows-4.0-amd64.exe attached to this release https://github.com/AnalogJ/scrutiny/releases/tag/v0.4.8), is there a existing PURL format for something like that?
Not really, but we can invent one.
if not, which of the following would make the most sense?
IMHO, the first one would be the closest. A default one would be:pkg:github/AnalogJ/scrutiny@v0.4.8?download_url=https://github.com/AnalogJ/scrutiny/releases/download/v0.4.8/scrutiny-collector-metrics-windows-4.0-amd64.exe ....
We could spec and update the spec for release assets:
could be something such as:
pkg:github/AnalogJ/scrutiny@v0.4.8?release_asset=scrutiny-collector-metrics-windows-4.0-amd64.exe
(and obvious) since here a specific property of GH release assets is that a name is unique within a release, so we could leverage this and have something compact and unambiguous
@AnalogJ is this for https://github.com/PackagrIO/fetchr ? :P
@AnalogJ you may be interested in package-url/purl-spec#139 which is to be merged anytime and https://github.com/nexB/univers which is in Python, not Go... but a Go vers would be awesome
Awesome, thanks for the help @pombredanne !
Yeah, fetchr will be a go library & cli for downloading artifacts using purl urls.
in my past life, we did run into an issue with our universal downloader that I havent seen discussed in the purl issues/repo -- immutable vs mutable references.
with a docker image its pretty easy to see that alpine:latest is not guaranteed to be immutable (vs alpine@sha256:12345abcdef) however referencing the image by digest is not always possible in the destination -- ie a helm chart references the image as alpine:v1.2.3
this also applies to git repos (where tags are mutable) and other artifact types.
We solved this by adding the ability to query and embed immutable refs in our "purl-like" identifiers.
something similar to:
pkg:docker/smartentry/debian@dc437cc87d10?immutable_ref=sha256@abc12345
pkg:docker/alpine@v1.2.3?checksums=sha256:dc437cc87d10
github.com/argoproj/argo-events/sensors/artifacts as shown in this Snyk vulnerability. Should everything go to the namespace and name portion like this pkg:golang/github.com/argoproj/argo-events/sensors/artifacts or go to subpath portion like this pkg:golang/github.com/argoproj/argo-events#sensors/artifacts?