Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Rhys Arkins
    @rarkins
    image.png
    A couple of observations from implementing:
    1. I find that escaping the @ but not escaping the / in namespace to be a bit inconsistent
    e.g. with a typical npm package I can't simply encodeUriComponent(depName)
    (2) I already have implemented "fullname" as an unofficial result of the parsing, e.g. namespace=@foo, name=bar, fullname=@foo/bar. I understand why someone in the issue tracker was asking why to have namespace at all
    Philippe Ombredanne
    @pombredanne
    @rarkins re "I find that escaping the @ but not escaping the / in namespace to be a bit inconsistent"
    --> how so? the @ sign is the separator for the version "component", so it has to be escaped. In contrast, the / is the separator for the ns/name components so if escaped it becomes inconsistent
    Rhys Arkins
    @rarkins
    I mean escaping it within the namespace, assuming you are allowing "namespaces that look like hosts" etc
    e.g. Docker image namespace includes host
    any short names are just aliases
    foo/bar -> docker.io/foo/bar
    everyone else has to live with full names
    Philippe Ombredanne
    @pombredanne
    @rarkins is this something that's an issue? or just a remark? :P
    Rhys Arkins
    @rarkins
    Well, is this example from the readme outdated? docker:gcr.io/customer/dockerimage@sha256:244fd47e07d10
    I assume it should be pkg:docker/gcr.io/customer/dockerimage@sha256:244fd47e07d10
    And if so then I'm wondering about the pros/cons of making it pkg:docker/gcr.io%40customer/dockerimage@sha256:244fd47e07d10 instead
    Per the package.json spec, new package "must not have uppercase letters in the name", therefore the must be lowercased.
    ^^ Yes but old packages that still may exist are case-sensitive
    BTW I've rolled out my use of purl into production today, but it's only used internally and not necessary to expose to users yet
    Steve Springett
    @stevespringett
    @rarkins congrats on rolling it out. OWASP Dependency-Track has over 5K Docker pulls after a short 3 month release so far, so a bunch more people are using it as well. The only modules that I know of that use purl is the CycloneDX node module. But this module does not do any parsing, rather it constructs valid purl based on metadata in package.json
    Philippe Ombredanne
    @pombredanne

    Well, is this example from the readme outdated? docker:gcr.io/customer/dockerimage@sha256:244fd47e07d10
    I assume it should be pkg:docker/gcr.io/customer/dockerimage@sha256:244fd47e07d10

    good catch ... that's a "bug"

    @rarkins re:

    Per the package.json spec, new package "must not have uppercase letters in the name", therefore the must be lowercased.

    ^^ Yes but old packages that still may exist are case-sensitive

    --> is there one case you know where the there would be a conflict: i.e. an npm that both UPPER and upper in the registry?

    BTW I've rolled out my use of purl into production today, but it's only used internally and not necessary to expose to users yet

    --> awesome! do you feel like contributing your JS implementation? that would likely be quite useful to a few project

    Rhys Arkins
    @rarkins
    I did a "JS 101" implementation that is pretty horrible
    and it's parse-only for now (was too easy to hand-craft the strings)
    and I also decided to make qualifiers be an object rather than raw string, so that's probably non-compliant
    happy to contribute it under permissive license if you think it's worth it as a starting point
    Philippe Ombredanne
    @pombredanne
    @rarkins qualifiers would be an object alright IMHO in JS
    once parsed
    and yes that would be worthy!
    if you can for a PR to https://github.com/package-url/packageurl-js that would be A+ neat!
    Rhys Arkins
    @rarkins
    I don't know of any upper case npm packages btw
    Philippe Ombredanne
    @pombredanne
    @rarkins neither do I ... that's wy I was asking this more in a rhetorical sense :P
    does not seem to work if you require('jsonstream');
    Philippe Ombredanne
    @pombredanne
    good catch! but does it work when you use the lowercase "jsonstream" in your package.json? I think it is... and in the registry it is lowercase afaik
    Rhys Arkins
    @rarkins
    I haven’t tried that, away from computer right now
    Steve Springett
    @stevespringett
    Wanted to lets folks know about https://www.owasp.org/index.php/Component_Analysis. Also, there are some outstanding spec questions and with increased momentium and adoption of purl, it makes sense to attempt to get to state of 1.0. About half of Dependency-Track installations for example are using CycloneDX BOM specification (Maven, NPM, Python, NuGet) which includes Package URL support natively. So realistically there’s a few thousand orgs using Package URL today.
    Philippe Ombredanne
    @pombredanne
    @stevespringett hey :wave: that's awesome.
    I do not think there is much left to call a 1.0 version.
    Philippe Ombredanne
    @pombredanne
    @stevespringett the Component_Analysis page is very nice
    I reckon there is also some discussion with https://www.ntia.doc.gov/SoftwareTransparency ... correct?
    Steve Springett
    @stevespringett
    I’m part of two of the NTIA working groups, but we have not discussed this page specifically - it’s a bit outside the scope of what they’re trying to do.
    Philippe Ombredanne
    @pombredanne
    @stevespringett I am a bit at loss with what their actual scope is? Any insight?
    well their web site has plenty of docs. Let me skim this
    Steve Springett
    @stevespringett
    Currently, NTIA working groups (there are four of them). I’m on the groups looking at use-cases as well as formats. The use-cases group is really interesting as there are a multitude of uses that all revolve around creation, publishing, distribution, modification, etc in the supply chain, and how these steps are chained together to form various uses across industries. The formats group is a bit more interesting except they’re talking solely about SPDX (RDF/Tag) and SWID, neither of which are really good at the use cases the other group is coming up with. We’re currently spinning our wheels a bit, not making as much progress as we should be. Good news is that NVD wants to get rid of CPE, but they don’t have a replacement for it yet. They are really interested in SWID, which doesn’t solve many of the problems we have, and it’s behind an ISO paywall, so myself and the rest of OWASP will likely never support that as OWASP is all about transparency and being open. Everyone seems to be behind Package URL though. I’m a bit upset that its taking over a year to get it into SPDX, but hopefully it’ll be available soon. SWID will also be adopting Package URL. Sonatype is a big proponent of Package URL. I’ve talked with Snyk and hopefully they’ll be implementing it in the future. The Retire.js and .NET Retire projects are also adopting Package URL. We should actively encourage every source of vulnerability intelligence to support Package URL.
    Steve Springett
    @stevespringett
    @pombredanne also note, that the website isn’t entirely up-to-date. None of the working group notes are posted to my knowledge.
    Steve Springett
    @stevespringett
    @pombredanne I received the invite from Kate Stewart for tomorrows session. Looks like you’ll be presenting Package URL. Congrats. I will not be able to attend as I’ll be in-flight at that time.
    Steve Springett
    @stevespringett

    To give you an idea of how Package URL is being used today:

    • Organizations are automatically generating CycloneDX BOMs from their builds. These BOMs contain Package URLs for every direct and transitive dependency.

    • BOMs are imported into Dependency-Track which performs vulnerable component and outdated component analysis.

    Dependency-Track uses Sonatype OSSIndex which uses Package URL (instead of CPE) to identify vulnerable components. Dependency-Track also integrates nativelly with various ecosystems (maven, npm, pypi, nuget, rubygems) to obtain oudated component information. Package URL provides the information necessary to perform both types of analysis in an automated way.

    Philippe Ombredanne
    @pombredanne
    @stevespringett thanks ++

    hey are really interested in SWID, which doesn’t solve many of the problems we have, and it’s behind an ISO paywall, so myself and the rest of OWASP will likely never support that as OWASP is all about transparency and being open.

    Same here. Unless there is no ISO paywall for the spec and no centralized pay-for-play assignment of SWID (e.g. AFAIK tagvault), SWID is not a solution to me.