inedo-engineer

hi @dan-brown_0128,

ProGet simply does not support case-sensitive npm package names. This is a 10+ year old design decision (back from ProGet v3), which we made because npm package were always supposed to be lower-cased: https://docs.npmjs.com/creating-a-package-json-file#required-name-and-version-fields

JSONPath is an invalid package that entered the public registry due to an npmjs.org bug. It's an old package -- latest version version 0.1.2, is 8+ years old -- and according to the package page says that it's "moved to jsonpath-plus to avoid npm problems in dealing with upper-case packages."

ProGet permits these packages, but there are just going to be quirks if you have them in your feed. For example, if you have both jsonpath-1.1.1 and JSONPath-0.1.2 in your feed, then they will generally show up as jsonpath, but in some API queries you may see JSONPath.

We understand this is different than how the npmjs.org registry behaves, but as I mentioned, this was a "day 1" choice that we can't change today. No one's mentioned this as an issue until now.

If npm audit is crashing because sometimes JSONPath is returned in results, that sounds like a bug in npm audit to me? We obviously can't add support for case-sensitive npm packages nor change how ProGet returns data in npm API calls just to work-around an npm audit bug like this.

The easiest solution is to stop using JSONPath and remove from your feed, which it sounds like you already have. It's a really old package, and there are only a handful like this on the public registry.

Best,
Steve

@dan-brown_0128 I understand

So you'd either have to upgrade (where we fixed the code) or reassess it to Low so npm audit won't crash. I suppose you could also patch npm audit so it doesn't crash.

Hi @dan-brown_0128 ,

Thanks for the detailed analysis; we'll get this fixed via PG-2636 in 2024.1 (due later today).

You should be able to assess it as "Low" to work-around it in the meantime. FYI, here is the code that is used to map a vulnerability to an npm vulnerability:

//assessed
if (vuln.Severity_Code != null)
{
    return vuln.Severity_Code switch
    {
        Domains.AssessmentSeverityCodes.Error => npmAuditSeverity.critical,
        Domains.AssessmentSeverityCodes.Warning => npmAuditSeverity.high,
        Domains.AssessmentSeverityCodes.NotApplicable => npmAuditSeverity.info,
        Domains.AssessmentSeverityCodes.Custom => npmAuditSeverity.info,
        _ => npmAuditSeverity.info
    };
}
// unassessed and has a Severity Score
else if (!string.IsNullOrWhiteSpace(vuln.ScoreSeverity_Text))
{
    return vuln.ScoreSeverity_Text switch
    {
        nameof(CVSSRange.Low) => npmAuditSeverity.low,
        nameof(CVSSRange.Medium) => npmAuditSeverity.moderate,
        nameof(CVSSRange.High) => npmAuditSeverity.high,
        nameof(CVSSRange.Critical) => npmAuditSeverity.critical,
        _ => npmAuditSeverity.info,
    };
}
return npmAuditSeverity.none;

Thank you,
Steve

Hi @dan-brown_0128,

I understand that npm is currently case insensitive, but there was a brief period that it wasn't. This led to several duplicate packages being published:

• https://www.npmjs.com/package/JSONPath
• https://www.npmjs.com/package/jsonpath

I don't believe this is possible anymore? Either way, ProGet is case insensitive for npm packages, which means that JSONPath and jsonpath are considered the same package. If JSONPath came first, then that's what the package name is I guess? In either case, the package name should be returned in results as jsonpath

It doesn't seem to cause any issues, except with npm audit?

This is a rare case, so I would just not worry about it. We don't recommend npm audit and you should use pgutil audit anyway. More comprehensive, covers licenses, all that..

Hi @stefan-kiryazov_8753 ,

Thanks for the inquiry; I've updated our Other feed types docs with a link to this thread.

On a first glance, it looks like a CocoaPod itself is just a basic text file that acts as a "pointer" to a GitHub repository. The pod client uses the git client to "download" files and tags for versioning. In other words, there is no package file.

A CocoaPod repository is a Git repository, and the pod client seems to just use git client to commit/push files to the repo. In other words, there is no API for ProGet to implement.

Here is what a CocoPod repo looks like (note how it's just a bunch of files in a Git repo):
https://github.com/CocoaPods/Specs/tree/master/Specs

To make a "private repo", you basically just create a Git repository:
https://guides.cocoapods.org/making/private-cocoapods

This means that ultimately to implement a CocoPods repository, your only option is to create a private Git repository? That's my inital assessment at least.

And of course, we have no plans to add Git source code hosting to ProGet :)

From here, I recommend to ask the developers to research this a bit more, and maybe contribute their thoughts? It just doesn't seem like the iOS devs uses packages - it's all very open-source and just GitHub repositories.

Steve

@daniel-scati we'll also get this fixed via PG-2635 in an upcoming maintenance release (hopefully 2024.2), which is targeted for next Friday.

Hi @daniel-scati , thanks for the analysis!

We'll get this fixed via PG-2635 in an upcoming maintenance release (hopefully 2024.2), which is targeted for next Friday.

@daniel-scati great work finding that :)

The Feed Description is written in the Release Index, and the Debian "Stanza" format is kind of weird like that.

However, newlines should already be replaced...

var desc = FeedCache.GetFeed(this.feedId)?.Feed_Description;
if (!string.IsNullOrWhiteSpace(desc))
    writer.WriteLine($"Description: {desc.ReplaceLineEndings("\n ")}");

A blank line with a space isn't supposed to create a new "stanza", but maybe it is in your version?? We'll look closer; perhaps we should just strip the newline altogether and replace it with a space.

Cheers,
Alana

Hi @lucas-almeida_8120,

This a known issue that we are currently working through. It seems to be an issue with some bad/duplicate data in your database. The current workaround is to downgrade to ProGet 2023. We are hoping to have a fix ready soon.

Thanks,
Dan

Thanks for clarifying, that's good to know taht solved the problem! I looked again and found it. Maybe I was looking in the wrong database

It doesn't look like bootstrap.less is in your feeds, but it is in the PackageNameIds table:

Just because it's in that table doesn't mean you're using it; we use the PackageName_Id as a surrogate ID instead of the package name. There should only be one entry, since NuGet package names are case insensitive.

anyway, I think I found the culprit -- looks like it was added during a vulnerability database update. MAybe there is some bug that didn't properly check the casing

Anyways, that's what we have to clean-up up :)