Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Philippe Ombredanne
@pombredanne
@TG1999 the reference JSON test file is in the SPEC
and is supposed to be the one file shared by all implementations
the one in the python repo is just a copy and the master should be kept in sync (and normally/ideally updated first)
Tushar Goel
@TG1999
Now I am getting the flow, :p I will add them quickly :D
Tushar Goel
@TG1999
Requested changes are done package-url/purl-spec#77
Haiko Schol
@haikoschol
submitted a tiny PR: package-url/packageurl-python#29 . merging this would save a bunch of confusing back and forth between PackageURL and str in nexB/vulnerablecode#152 (e.g. https://github.com/nexB/vulnerablecode/pull/152/files#diff-b1145824c474d7ced1f3c9d3742cd707R294)
Philippe Ombredanne
@pombredanne
@haikoschol thanks! and I merged it
Haiko Schol
@haikoschol
:ok_hand:
Tushar Goel
@TG1999
@pombredanne @stevespringett package-url/purl-spec#77
Please review these :)
Steve Springett
@stevespringett
@pombredanne Can I get a review of package-url/purl-spec#79 please? The pull requests for purl types are starting to pile up and it would be great to be able to separate them out from the core specification before we get too many.
Philippe Ombredanne
@pombredanne
reviewing now
Philippe Ombredanne
@pombredanne
I will do a diff with the original REDAME ANd post comments over the week end :P
Nisha K
@nishakm
o/
Nisha K
@nishakm
Hi folks, I'm trying to figure out how to describe a package that was not downloaded via a package manager but was packaged using a tool. Eg: a jar or war file. Any help?
Steve Springett
@stevespringett

@nishakm. If the jar/war is available in an organizaitons internal repo (nexus, artifactory, etc), then you’d simply represent it like this:

pkg:maven/groupId/artifactId@version?repository_url=myrepo.example.org

If you want to try to describe a random file on the filesystem, PURL was not designed for that, but it can be done.

pkg:generic/logo?repository_url=/home/nisha/documents&file_name=logo.png

This is perfectly valid, but certainly non-standard. Both repository_url and file_name are reserved qualifiers that can be used with any PURL type.

Nisha K
@nishakm
The specific use case I was trying to describe is cloud native buildpacks, where a buildpack is a recipe that could download a prebuilt artifact such as a jar file from a S3 bucket. Since there are several hops across domains to get this artifact (using the pack CLI which invokes a buildpack which downloads an artifact from a S3 bucket defined in the buildpack's recipe) I was wondering how I would describe this particular artifact using pURL. How about pkg:cnb/jvm@sha256:deadca66a9e?repository_url=cloudfoundry.org? In this case, a distributor does not know the exact URL the artifact was downloaded from but does know who supplied it (cloudfoudry.org)
Philippe Ombredanne
@pombredanne
@nishakm hey :wave:
we can definitely have a package type for them
otherwise you can always use pkg:generic/jvm@sha256:deadca66a9e?download_url=https://cloud.org/jvm.tgz
Nisha K
@nishakm
@pombredanne well, that's the issue, the download_url is often times not known.
suppose the jvm.tgz is hosted on a content addressable storage system, then you only know the digest and the name of the supplier's client tool.
Philippe Ombredanne
@pombredanne
@nishakm the key point would be if there is an overall well defined "protocol" to get to the package data and files?
(say for Maven you have a repo, a pom format, JARs, XML files in the repo, etc.) ... same for a Docker registry
Nisha K
@nishakm
@pombredanne isn't that what the package_type is supposed to indicate? Like pkg:oci/mongo@sha256:deadca66a9e?repository_url=docker.io for containers hosted on Dockerhub and pkg:oci/mongo@sha256:deadca66a9e?repository_url=quay.io for containers hosted on quay.io
for CNB they don't host containers but raw tarballs which they assemble on the client that has the cli pack installed
so maybe in that case the repository qualifier is not needed?
Philippe Ombredanne
@pombredanne

isn't that what the package_type is supposed to indicate?

exactly :)

Nisha K
@nishakm
OK, I think I understand now. Thanks much @pombredanne!
Philippe Ombredanne
@pombredanne

so maybe in that case the repository qualifier is not needed?

The idea is to always use the bare minimum info :) I do not know enough of cnb though :P

@stevespringett BTW, I am late reviewing your PR for the spec... but I will come to it eventually :P
Ghost
@ghost~5da7ddb2d73408ce4fce1c5e
In [1]: from packageurl import PackageURL                                                                                                                                           

In[2]:p1=PackageURL(name="foo",type="bar",version="7.14-2+deb7u12")                                                                                                             

In [3]: p1                                                                                                                                                                          
Out[3]: PackageURL(type='bar', namespace=None, name='foo', version='7.14-2+deb7u12', qualifiers=OrderedDict(), subpath=None)

In [4]: p1.version                                                                                                                                                                  
Out[4]: '7.14-2+deb7u12'

In [5]: p1.to_string()                                                                                                                                                              
Out[5]: 'pkg:bar/foo@7.14-2%2Bdeb7u12'

Notice how the + in version gets converted to %2B when the PackageURL object is converted to string, is this the expected behaviour?

Due to this, we are ending up with versions like 7.14-2%2Bdeb7u12 written to VulnerableCode's DB . Please suggest workarounds.

Ghost
@ghost~5da7ddb2d73408ce4fce1c5e
Nvm I figured out a workaround, the problem was https://github.com/package-url/packageurl-python/blob/00b7df61173be3c19eb65ce166271aed0e9ae00c/src/packageurl/__init__.py#L150 , which I have patched up in the models at vulnerablecode. Seems like it was an expected behaviour.
Philippe Ombredanne
@pombredanne
:)
Philippe Ombredanne
@pombredanne

from https://github.com/ossf/wg-vulnerability-disclosures/issues/18#issuecomment-678810137

[...] but if we frame that discussion in this context, PURL is a superior identifier as it lacks the friction of SWID.

:)
Tushar Goel
@TG1999
Nice :)
Steve Springett
@stevespringett

There has been some interest in supporting SWID as a valid PURL type as well.
For example:

pkg:swid/tagid@version?name=Product%20Name&tagVersion=1&patch=false

or

pkg:swid/tagid/Product%20Name@version?tagVersion=1&patch=false

This provides a 1-to-1 mapping between PURL and the SoftwareIdentity element of SWID. The most important of these is the tagId which can be used for vulnerabiity analysis use cases. The CycloneDX spec supports SWID in a similar way https://cyclonedx.org/docs/1.2/#type_swidType and I believe SPDX 3.0 will support something similar as well.

However, it would be really interesting to be able to support the SWID identifier use case solely using PURL. The overwheling majority of SWID use cases that I see are solely for software identity and entitlements. Identity is hugely important for various forms of risk analysis. If we can extract the identity capability from SWID and represent identity in a standardized format, I think it would be highly beneficial, even though strictly speaking, SWID is not a ‘package’.

I have not submitted a PR for this as I’m waiting for package-url/purl-spec#79 to be accepted and merged before committing to supprt additional PURL types.

Anyway, what is everyone’s thoughts on this?

Philippe Ombredanne
@pombredanne
@stevespringett Sorry for being late on my review and merging of package-url/purl-spec#79
I will do it this week at last :P

Anyway, what is everyone’s thoughts on this?

Re: swid, yes this makes a lot of sense :+1:

Jeffry Hesse
@DarthHater
Hello friendly purl friends!
I have a PR for the packageurl-js project, just for the TypeScript typings (so no major code changes): package-url/packageurl-js#17
Steven Esser
@majurg
@DarthHater Thanks for the contribution. Your changes have been merged and v0.0.3 of packageurl-js have been published to the npmjs repositories :)
Jeffry Hesse
@DarthHater
RAD!!!
Thank you!
I had a bunch of code that was doing .substr(0, purl.toString().length - 1) and was like LOL why AM I DOING THIS
Steven Esser
@majurg
yeah very ugly and a good catch. I am surprised that no one else had come across this bug. But thanks for the PR!
Jeffry Hesse
@DarthHater
Another one for y'all, this is just implementing part of the purl-spec: package-url/packageurl-js#18
Steven Esser
@majurg

@DarthHater Thanks!

Its been merged and v0.0.4 of packageurl-js and been published to npmjs with your addition.