by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Aug 12 18:39
    mrparticle starred package-url/purl-spec
  • Aug 12 09:48
    athos-ribeiro opened #89
  • Aug 03 20:36
    bradcupit commented #63
  • Aug 03 17:52
    stevespringett commented #84
  • Aug 02 13:00
    gotthardp commented #59
  • Aug 02 12:58
    gotthardp commented #59
  • Aug 02 12:48
    gotthardp commented #63
  • Aug 02 12:13
    gotthardp starred package-url/purl-spec
  • Jul 30 20:16
    adrian-sufaru starred package-url/purl-spec
  • Jul 27 19:29
    JosiahParry starred package-url/purl-spec
  • Jul 24 09:03
    athos-ribeiro opened #88
  • Jul 09 13:43
    sschuberth unassigned #21
  • Jul 08 07:52
    d3v3l0 starred package-url/purl-spec
  • Jul 06 02:58
    highkay starred package-url/purl-spec
  • Jun 24 07:23
    RikardLegge commented #87
  • Jun 24 00:19
    jdillon commented #87
  • Jun 23 18:01
  • Jun 23 13:32
    stevespringett labeled #87
  • Jun 23 09:46
    RikardLegge opened #87
  • Jun 12 00:56
    FirasHojirat starred package-url/purl-spec
Steve Springett
@stevespringett
@pombredanne . Ok, 14:00 UTC Wednesday. Here’s the zoom. https://servicenow.zoom.us/j/355981701
Tushar Goel
@TG1999
I have added support for Cargo PURLs in Python, but in purl-spec the documentation regarding the same is not present right now, so should I add a PR for it too ?
Steve Springett
@stevespringett
A Rust implementation does exist https://crates.io/crates/packageurl although its not part of the Pacakge URL GitHub org. Looks like the cargo examples are missing from https://github.com/package-url/purl-spec/blob/master/README.rst. Follow the format of all the other examples and remove cargo from the list of proposed types as well. We should likely also add cargo to the test suite as well.
Tushar Goel
@TG1999
Cool will be making a WIP PR
Tushar Goel
@TG1999
package-url/purl-spec#75 added cargo in purl-spec, please review it :) & thoughts on this please so I can start working on it package-url/packageurl-python#25.
Philippe Ombredanne
@pombredanne
thank you :+1:
Tushar Goel
@TG1999
Cool I will open a PR for Hackage soon :+1:
Tushar Goel
@TG1999
Hi @stevespringett should I also write purl-spec for hackage PURLs I have added a PR for it's implementation in python package-url/packageurl-python#26 and it's passing tests too :D
Steve Springett
@stevespringett
Yes please. That would be great. Thank you
Tushar Goel
@TG1999
Cool on it :)
Tushar Goel
@TG1999
Done @stevespringett package-url/purl-spec#77
Tushar Goel
@TG1999
Hi @pombredanne please review it package-url/packageurl-python#26 and if this is good to go, I will like to start work on CRAN PURLs
Tushar Goel
@TG1999
Oops @stevespringett did some mistake in the PR for spec :p, will correct it tommorow :D
Tushar Goel
@TG1999
Done @stevespringett package-url/purl-spec#77 now its good to go :D
Tushar Goel
@TG1999
Hi @pombredanne I have addressed your comments, just wanted to have a review on implementation before adding tests in JSON file package-url/packageurl-python#26 :D
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
Shivam Sandbhor
@sbs2001
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.

Shivam Sandbhor
@sbs2001
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
:)