Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parts of purls that should be percent-encoded are not correctly encoded #46

Open
malice00 opened this issue Aug 19, 2023 · 1 comment
Open

Comments

@malice00
Copy link

I've been working on some issues for cdxgen with generating Gradle purls for projects. My issue is that Gradle prefixes project names with a ':', which should imho not be an issue if the name would actually be percent-encoded. I noticed during testing however, that this is not the case.

Checking your code, you do actually use encodeURIComponent, but then explicitly turn '%3A' back into ':'. When I then feed the generated purl into your fromString-method to validate it, it fails, because of the ':' in the purl:

let [scheme, remainder] = purl.split(':', 2);

Now, for a top-level project in Gradle, I could remove the ':', but then the question becomes how to handle sub-projects. These have the ':' not just at the front, but inbetween the layered projects as well (eg. :a:b:c:d). Currently, cdxgen removes the initial ':' and changes the remaining ':' to a '/', which unfortunately with the way your code works, makes all parts before the last '/' part of the namespace! This could then generate a purl that identifies multiple projects, eg:

  • Namespace 'a/b/c', name 'd' --> purl: 'a/b/c/d'
  • Namespace 'a/b', name ':c:d' --> purl 'a/b/c/d'

I would expect when using a name like :a:b, to get a purl looking more or less like pkg:maven/namespace/%3Aa%3Ab@version.

In case the current behavior is not an error, but actually expected, I think there is need for a discussion about how to make purls for Gradle (in case there hasn't already been one).

Also, in case this is an error, there's more places in your code where specific characters are explicitly decoded -- maybe worth taking a look at those as well...

@steven-esser
Copy link
Collaborator

v1.2.1 released with fixes for #45 and #52. Is there still an issue on your side @malice00?

If so, would love to figure out what else is left to fix.

steven-esser added a commit that referenced this issue Nov 9, 2023
* remove unneed exception raising for the version param
* do not skip URL encoding `:` and `+` characters
* add test cases from old issues

refs: #45, #46, #57

Signed-off-by: Steven Esser <me@stevenesser.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants