Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jun 18 19:30
    iamwillbar synchronize #108
  • Jun 18 19:30

    iamwillbar on iamwillbar-patch-1

    Fix inconsistent indenting (compare)

  • Jun 18 18:57
    iamwillbar opened #108
  • Jun 18 18:57
    iamwillbar review_requested #108
  • Jun 18 18:56

    iamwillbar on iamwillbar-patch-1

    Add SPDX to users, adopters and… (compare)

  • Jun 16 21:51

    pombredanne on iamwillbar-patch-1

    (compare)

  • Jun 16 21:51

    pombredanne on master

    Formatting of PURL-TYPES.rst F… Merge pull request #107 from pa… (compare)

  • Jun 16 21:51
    pombredanne closed #107
  • Jun 16 21:51
    pombredanne closed #106
  • Jun 16 07:17
    pombredanne edited #107
  • Jun 16 07:07

    pombredanne on spec-separation

    (compare)

  • Jun 15 20:52
    iamwillbar review_requested #107
  • Jun 15 20:52
    iamwillbar review_requested #107
  • Jun 15 20:52
    iamwillbar opened #107
  • Jun 15 20:51

    iamwillbar on iamwillbar-patch-1

    Formatting of PURL-TYPES.rst F… (compare)

  • Jun 04 07:07
    muellerjue starred package-url/purl-spec
  • Jun 02 13:34
    cornelius starred package-url/purl-spec
  • Jun 01 15:50
    bradcupit commented #63
  • May 31 06:38
    lxl5lxl5lxl starred package-url/purl-spec
  • May 29 11:41
    EdinyangaOttoho starred package-url/purl-spec
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.

Philippe Ombredanne
@pombredanne
@DarthHater :wave: thank you!
Jeffry Hesse
@DarthHater
No pronlem!
Philippe Ombredanne
@pombredanne
@stevespringett and @/all I pushed a PR for the split of the specification and type defs that keep the history for each of the files. At last!
package-url/purl-spec#102
Jeffry Hesse
@DarthHater
Hello @pombredanne @majurg , I got this lil PR for you: package-url/packageurl-js#20
Something we noticed while creating golang purls in JS
Jeffry Hesse
@DarthHater
I think I'm correct in what I did, but if I'm not feel free to tell me, no ego bruising :)
Philippe Ombredanne
@pombredanne
@DarthHater Hey ... thank you ++ :bow:
unrelated I pushed the separation of spec and types in tow docs as initiated by @stevespringett ... at last!
Jeffry Hesse
@DarthHater
Rad!!!!
Jeffry Hesse
@DarthHater
I've got some replaces in my code to handle it for now (the forward slash stuff). It's not super bad, but YOU KNOW, haha
Philippe Ombredanne
@pombredanne
@DarthHater your PR makes sense. :+1:
Jeffry Hesse
@DarthHater
@pombredanne any sense of when we can merge it?
Philippe Ombredanne
@pombredanne
@DarthHater any time :) @majurg ^
Steven Esser
@majurg

@DarthHater Your PR was merged and v0.0.5 of packageurl-js published to the npm repos: https://www.npmjs.com/package/packageurl-js

Thanks for your patience

Philippe Ombredanne
@pombredanne
@majurg :+1:
Jeffry Hesse
@DarthHater
Yay!
Thanks buds!
Jeffry Hesse
@DarthHater
@majurg @pombredanne I am also doing a replace for a %2B aka + in versions, would y'all think that would be a decent PR too? Golang versions often have `v3.0.0+incompatible" and that kinda creates a weird situation
Steven Esser
@majurg
@DarthHater Yes that would be welcomed
Jeffry Hesse
@DarthHater
Coolio!
Philippe Ombredanne
@pombredanne
@DarthHater ideally I would like to precise and relax quoting rules in the spec proper.