Posts made by sebastian...

@atripp said in Problem with PGV-22381O7 (tree-kill1.2.2 incorrectly flagged vulnerable):

Anyway, ISL is managed by a different team, so I'll submit an internal request to review. It doesn't seem so urgent, just inconvenient/incorrect and easy to workaround in ProGet. But let me know if I misread that.

You are correct; it's not an urgent problem, because I can just choose a different assessment for that entry (we have a special assessment "Manually Unblocked" for cases like that). The other two entries are correct (i.e. they display the affected version as < 1.2.2 or <= 1.2.1).

As for "Withdrawn" vulnerabilities... we're open to ideas for what to change in ProGet 2025. There used to just be a handful, but there are a lot more now. Our original was to just delete them from ProGet, but instead we just showed the icon. Maybe we should delete them.

My guess is that PGV-22381O7 wasn't updated after it was withdrawn, so when version 1.2.2 of the package was released (and GHSA-mxq6-vrrr-ppmg updated "affected versions" to <= 1.2.1; again, I'm just guessing that that's what happened), the PGV entry didn't really reflect that.

It would expect one of the following two things to happen with withdrawn vulnerabilities:

1. The team at Inedo Security Labs should update withdrawn packages, especially when they flag "all" versions of a package as vulnerable.

2. There should be a special treatment for withdrawn vulnerabilities within ProGet. Maybe not deleting them (because I'm pretty sure there will be cases where I will be looking at a package and think "I swear this one had a vulnerability, but now I can't find it?" ), but maybe auto-assess a special status to it.

Hi there,

I'm not sure if this is a ProGet issue, a problem with the ProGet Vulnerabilities Database or something completely different, so I'm just going to post my observation.

The npm package tree-kill has been flagged as vulnerable in all versions - including the latest version 1.2.2 - due to PGV-22381O7:

There are several problems with this.

First of all, as you can see on the second screenshot, that vulnerability has been withdrawn, which raises the first question: How should ProGet handle withdrawn vulnerabilities?

However, the main problem here is that PGV-22381O7 claims that "all" versions of tree-kill are affected:

That statement is incorrect. In fact, tree-kill fixed the problem with version 1.2.2.

PGV-22381O7 seems to be based on https://github.com/advisories/GHSA-mxq6-vrrr-ppmg, which is a duplicate of https://github.com/advisories/GHSA-884p-74jh-xrg2. While the first one only claims that versions <= 1.2.1 are affected (but does not display any information on patched versions), the second one clearly states that version 1.2.2has been patched:

One more thought on this: Is it generally a good idea to flag "all version" of a package as vulnerable? Wouldn't that affect any future version of that package as well, regardless of whether it has been patched or not? Or is the idea that those entries will be updated as soon as there is a patched version of the package?

@apxltd

I thing it looks pretty good, to be honest. It's simple enough and has all the information I would be looking for.

Only minor adjustment maybe for people who have a lot of projects/build affected by a certain license would be to make the list sortable by "Project" or "Package", so it would be easier to scroll through larger lists.

Hi @apxltd

first of all, sorry for the badly cropped screenshot. In this specific scenario, I'm interested in the projects using libraries that are under GPL-2.0 or PolyForm-Noncommercial-1.0.0 license (but they were too far down on the page to fit into the screenshot). So what I'm really looking for is that one project that uses a PolyForm-license and those seven projects that use GPL-2.0 licenses (some of those are internal projects, which would be OK, but I want to make sure no other projects use packages with those licenses).

The /sca/compliance-report isn't really useful for us at the moment, because I can only see a handful of entries, none of which mention one of the two licenses above. I assume that this is due to the "max. 1,000 builds" limit in the package analyzer. That's why the "License Usages Overview" is so helpful (and would be even more helpful if it had a way to quickly navigate to the affected projects/builds/packages ).

@stevedennis said in License Usage Overview - Non-compliant Licenses in Use:

That said, the Licenses Overview page predates Policies, and I don't think the "License Usage Issues" makes a lot of sense anymore. The old model (block/allow) was much simpler with a basic Allow/Block rule. However, Policies are quite a bit more complicated.

We're very open to ideas on what to do in its place, or if you have any suggestions on what could be improved in general in the SCA UI. It's very easy for us to "see" what you're talking about, since we have the backup now :)

If you don't mind me hijacking this thread: The Licenses Overview page already shows the number of affected packages, builds and projects per license:

Wouldn't it be nice to be able to actually get a list of those packages, builds and projects? For example, each of those numbers could be a link and clicking on it would open a popup or another page with the complete list. Basically like the "Usage & Statistics" page for packages.

We currently have our own little tool which does exactly that (reading the data directly from the ProGet database), but it would be nice to have this build-in in ProGet.

@apxltd said in Linux Performance & SQL Server Issues:

Expected Problem: Too Many Requests

A single, underspec'd machine can only handle so much load, and I wanted to find out what those limits were, and what errors I would get in "new user evaluation" scenario.

On Linux, with my test scenario, this manifests with basically the same, "error 35". I believe it's socket exhaustion, but who knows? In most production cases, we see SQL/network timeout - this is because the database is usually filled with a ton of data, and is taking a bit longer to respond. In my test scenario, it wasn't.

Non-solution: Slow the REquests

When I added a client-slide throttle - or even spaced out issuing the requests by 10ms - there were virtually no errors. If only NuGet and npm clients behaved that way...

Solution : Concurrent Request Limit

Under Admin > HTTP/S & Certificate Settings > Web Server Configuration, you can set a value called "Concurrent Request Limit". That made all the difference after warming up.

25 Requests worked like a charm. No matter what I threw at the machine, it could handle it. The web browsing experience was terrible, which makes me think we may want to create a separate throttle for web vs API in a case like this.

250 Requests caused moderate errors. Performance was better while browsing the web, but I'd get an occasional 500 error.

I wish I could give better advice, but "playing with this value" seems to be the best way to solve these problems in production. For our evaluation machines, I think 25ish is fine.

This doesn't seem to be Linux-specific. We've run into performance issue with Angular projects (restoring several hundred npm packages all at once when building from scratch) in the past on our Windows server. The problem seemed to be the pool size of the SQL client.

Our solution was to set the Concurrent Request Limit to 100, which seems to be the default pool size for the MS SQL client in .NET.

Before setting the request limit, npm install was 4x slower than connecting to the original npm registry.

After setting the request limit, connecting to our ProGet server was even faster than connecting to the original npm registry.

This is on a virtual 2 Core, 8 GB RAM Windows Server 2016 hosting ProGet 2023 and the corresponding MS SQL Server 2016 Express Edition, if anyone is curious.

Hi everyone,

I stumbled upon this thread because we have been faced with a similar problem in the past (missing packages due to projects not yet configured to use ProGet as a proxy, especially for npm packages), and I was wondering whether this whole process could be simplified with a specific webhook notifier for missing packages (or at least for inconclusive packages). There already is an event type called "Noncompliant Package Discovered", so it would seem rather straight forward to add another event type called "Inconclusive Package Discovered" or "Package Not Found During Analysis".

Such a webhook could be used for two things:

• Trigger a download of the missing package from ProGet, resulting in the package being cached there (basically the solution that has been discussed in this thread, except that it's now done on demand) and the SCA analysis being able to handle the package correctly the next time it runs.
• Notify project owners that their project apparently is not configured to use ProGet as a proxy for all package types or that there is some other kind of problem.

Or maybe this is already possible with one of the existing webhook events and I'm just reading the documentation wrong?

@stevedennis
Any chance that this will get fixed in ProGet 2023? We can't upgrade to 2024 at the moment due to the "1000 active builds" limitation.

Hi @stevedennis

We updated to 2023.35, and while OR expressions now seem to get recognized, I think the interpretation of those combinations is now incorrect. In earlier versions of ProGet, when a package had an allowed and a blocked license (combined with "OR"), the package itself was not blocked, which was OK because at least one of the licenses you could choose from was compliant. Now those packages seem to get blocked, which seems incorrect.

Let's take a look at the npm package jszip 3.10.1 for example. Its package.json entry is "license": "(MIT OR GPL-3.0-or-later)". This somehow translates to "(MIT, GPL-3.0-or-later)" on the package's Metadata page:

The individual licenses (MIT and GPL-3) are correctly identified. What's incorrect, though, is that the package is being blocked due to it using the non-compliant GPL-3.0-or-later license:

While that license is indeed configured as non-compliant (and any package solely under that license would correctly be blocked), the MIT package is configured as compliant:

Thus, that package should not be blocked from being downloaded. However, not only is the package blocked, it also shows up as as issue in our SCA reports:

What's even more weird is that on the package's general page (the non version-specific under "URL/feeds/FEEDNAME/jszip/versions") it says that the MIT license is actually the one that is non-compliant, which is definitely incorrect.

Note that this problem is not specific to jszip or those specific licenses. Another example would be the npm package node-forge, which is dual licensed under BSD-3-Clause (compliant) and GPL-2.0 (non-compliant). The corresponding license expression is (BSD-3-Clause OR GPL-2.0), but the package is blocked, its usage shows up as an issue in our reports and BSD-3-Clause is incorrectly shown as non-compliant on the package's page:

Hi there,

detection of license expressions containing more than one license (e.g. (MIT OR Apache-2.0)) was introduced to ProGet last year and it seemed to work fine. However, I'm currently looking at a few npm packages with SPDX tags like (AFL-2.1 OR BSD-3-Clause), (Apache-2.0 OR MPL-1.1) or (BSD-3-Clause OR GPL-2.0) and none of them seem to be detected.

Here is a list of npm packages and their license expressions, none of which seem to get detected correctly:

Here is a screenshot for one of those packages within ProGet:

Strangely enough, for Nuget packages it seems to work fine:

Any ideas? We are currently on ProGet 2023.34. I'm pretty sure this worked in an earlier version. I mean, looking back at the other thread, I apparently tested this in ProGet 2023.1 and it worked fine. So something must have happened between 2023.1 and 2023.34.

@rhessinger said in Proget: Documentation of 2024 Projects Preview feature:

With all that said, you can customize these build stages by navigating to Reporting & SCA -> Projects and then hover over the multi-button in the upper right corner and select "Build Stages".

Thanks @rhessinger, this is what I was looking for! Looking at settings page really helps understanding what they are doing.

I have one follow-up question: There is an option called Set status of promoted build to "Released" at the stages' settings page, but it does not seem to be set on any of the four predefined stages. What's the effect of that option?

Hi there,

I was wondering if there is some documentation of the 2024 preview feature "Projects" within the SCA reports available. I found this new entry in the documentation, but I doesn't really answer my questions (yet). At the moment, the article basically just says that stages exist, but doesn't really go into details.

Here are some of the things I was wondering about:
What's the actual effect of a version being in one of the predefined stages? Am I correct in assuming that only active builds and versions in the "Production" stage are being analyzed? What's the effect of a version being in "Test" or "Integration"? What's the number of versions/builds per stage? We usually have several versions in production (i.e. customers use them in production) at the same time, but it seems that promoting a build to "Production" will move older builds to "Archive" (allowing only 2 build in Production). Is there a way to prevent this or increase the number of builds per stage? The article also mentioned that it would be possible to define our own stages, but I couldn't find that option yet (using ProGet 2023.31).

Hi @rhessinger

Thanks, but I don't think we will need a pre-release. The remaining problem is basically a convenience issue (getting from the report to the package's info page with one click). Everything else seems to work as expected with the latest pgscan version.

@rhessinger @atripp
I don't think the remaining problem is a pgscan issue. The latest version of pgscan (v1.5.12 including commits eb61208, bc663c4 and 28e60ad) should handle the @ within scope names correctly. Here is a little sample from a generated SBOM file:

<component type="library">
  <group>@angular</group>
  <name>common</name>
  <version>17.0.9</version>
  <purl>pkg:npm/%40angular/common@17.0.9</purl>
</component>

<component type="library">
  <group>@angular</group>
  <name>compiler</name>
  <version>17.0.9</version>
  <purl>pkg:npm/%40angular/compiler@17.0.9</purl>
</component>

<component type="library">
  <group>@angular</group>
  <name>core</name>
  <version>17.0.9</version>
  <purl>pkg:npm/%40angular/core@17.0.9</purl>
</component>

The problem seems to be on the ProGet side. The %40 is correctly displayed as @ in the UI, and packages seem to be identified correctly as well.

The only remaining problem is that the /packages/from-purl API endpoint seems to have problems with two @ characters. Btw, both of them are apparently encoded as %40 within the URL. Here is an example URL: http://proget-host/packages/from-purl?pUrl=pkg%3Anpm%2F%40angular%2Fcore%4017.0.9. The endpoint seems to convert both %40parts back to the @ character, which results in the error message "pkg:npm/@angular/core@17.0.9 is an invalid purl".

Without knowing too much about the code within ProGet it's hard to speculate how to solve this, but my guess is that either the endpoint needs to be able to handle two @ characters within a purl, or the purl itself needs to be encoded differently when passed as a parameter with another URL. When I change the example URL of my previous example in a way that the % of the first %40 encoding is encoded as well (i.e. replacing %with %25, I get the following URL, which actually works: http://proget-host/packages/from-purl?pUrl=pkg%3Anpm%2F%2540angular%2Fcore%4017.0.9 (%40angular has been replaced with %2540angular).

Cheers,
Sebastian

Hi Alex,

thanks for the feedback and the sneak peak at Proget 2024. Just a little background on how this came up: A developer actually came to me the other day and asked "Hey, can I use packages with license XYZ?", and my initial reply was "Well, just check what our Proget server says about that license" (we also have a written policy on how to handle the most common open source licenses, but it's not as frequently updated as our Proget license rules), but then I realized "Oh wait, you probably can't see whether there is an explicit rule about that license, because you don't have access to the license rule page..."

I'm looking forward to those new features in Proget 2024, and I'm pretty sure they might change some of our workflows. If after testing Proget 2024 I still feel like there is a need for developers to see details about rules, even though they can't edit them, I will update this post.

Have a nice weekend!

Proget visually indicates whether a license is blocked/allowed (or more precisely: whether packages with that licenses can be downloaded) and also whether this is due to an explicit rule or just by default. However, this is only done at the "License Types & Rules" view (Reporting & Software Composition Analysis (SCA) > License Usage > License Types & Rules):

The "License Usage" view just states whether used licenses are allowed or blocked, but it does not indicate whether a license is blocked by an explicit rule or by default:

Same goes for SCA reports or for package information pages: they indicate very prominently whether that packages can be downloaded based on its license, but doesn't reveal whether this is due to an explicit rule or just by default.

The feature request is for Proget to indicate whether there is an explicit rule for a license in all of the views mentioned above.

Why is this needed?

Developers regularly have to add new packages during development of new products, which means that every now and then they will stumble upon a license that hasn't been used so far. Proget has exactly two ways of handling "new" licenses: block or allow.

If we set Proget to block all licenses that have not been explicitly allowed, a developer who is faced with a blocked download currently has no way of knowing whether this is because someone has already made the decision that that specific license cannot be used, or if it's just because nobody has made a decision about that license so far.

If the information whether or not an explicit rule exists for that license was indicated on a view that developers have access to (regular developers do not have access to the aforementioned "License Types & Rules" view), they could go to to whoever is in charge of making that decision and ask them to please review license XYZ and set up an explicit rule for it in Proget.

Hi everyone,

just created a PR to improve support for both the old and the new file format.

File format 1 & 2 ('dependencies'): Added code to also read sub-dependencies.

File Format 2 & 3 ('packages'): Added code to deal with the new way of handling package alias. Apparently, there is an optional 'name' property. Couldn't find anything about that in the format's specification, so this is purely based on observation of our test projects.

@shayde

The code looks good to me

Hi again

Two more things I noted while looking into this: It seems that the current implementation (reading the dependencies property) doesn't consider transitive dependencies at all. Take the package chalk as a example. I have one package that has a requirement of the form "chalk": "^2.0.0", which is resolved to the following dependency

    "chalk": {
      "version": "2.4.2",
      "resolved": "https://registry.npmjs.org/chalk/-/chalk-2.4.2.tgz",
      "integrity": "sha512-Mti+f9lpJNcwF4tWV8/OrTTtF1gZi+f8FqlyAdouralcFWFQWF2+NgCHShjkCb+IFBLq9buZwE1xckQU4peSuQ==",
      "requires": {
        "ansi-styles": "^3.2.1",
        "escape-string-regexp": "^1.0.5",
        "supports-color": "^5.3.0"
      }

However, I have some more packages with requirements like "chalk": "^4.1.0", which are resolved to sub-dependencies like this:

        "chalk": {
          "version": "4.1.2",
          "resolved": "https://registry.npmjs.org/chalk/-/chalk-4.1.2.tgz",
          "integrity": "sha512-oKnbhFyRIXpUuez8iBMmyEa4nbj4IOQyuhc/wy9kY7/WVPcwIO9VA668Pu8RkO7+0G76SLROeyw9CpQ061i4mA==",
          "dev": true,
          "requires": {
            "ansi-styles": "^4.1.0",
            "supports-color": "^7.1.0"
          }

Those sub-dependencies are not scanned at all, if I'm reading the current implementation of NpmDependencyScanner correctly. This results to only version 2.4.2 being reported into our SCA reports. Version 4.1.2 is not listed.

The packagesproperty of the new file versions 2 and 3 seems to list all packages in a flat list, putting information about relations between packages on the top level. This leads to entries like "node_modules/chalk" (resolving the version 2.4.2), "node_modules/critters/node_modules/chalk" (resolving the version 4.1.2), "node_modules/eslint/node_modules/chalk" (4.1.2 as well), ...

So if we extract the correct name of the package and add to corresponding version to it, our SCA reports should now (correctly?) report both versions of the chalk package.

The second thing I noticed here: we will get multiple entries of the same package/version combination. This probably won't bother ProGet, as I guess those entries will be considered identical, but I guess it wouldn't hurt to put a Distinct()in somewhere on the client side. Like, maybe changing the line

            return new[] { new ScannedProject(projectName, ReadDependencies(doc)) };

to

            return new[] { new ScannedProject(projectName, ReadDependencies(doc).Distinct()) };

or maybe changing to code of the ScannedProject constructor from

            this.Dependencies = dependencies.ToList();

to

            this.Dependencies = dependencies.Distinct().ToList();

Cheers,
Sebastian

@shayde
I added two comments to your PR. I think transitive dependencies need to be handled differently, otherwise you'll get concatenate package names like @angular-devkit/build-angular/jsonc-parser 3.2.0, @angular-devkit/core/jsonc-parser 3.2.0, @angular-devkit/schematics/jsonc-parser 3.2.0, [...] when it should probably really just be jsonc-parser 3.2.0.

@shayde
I can't speak for @atripp and the folks at Inedo, but I can tell you that we have submitted PRs for pgscan via GitHub in the past and they have all been accepted. Caterina and I actually already discussed implementing this, because it doesn't look too complicated, but we probably won't get a chance to look into it closer for a few more days. So if you want to go ahead, I think this would be much appreciated

@atripp
You are correct! I can download the package directly entering the corresponding URL in the browser, so it seems that this indeed just a UI problem.

Hi @atripp

I have tried changing the global rule to "block" and then back to "allow", but it did not change anything. I also tried different assessment, also to no effect. The only thing worth mentioning that comes to mind is that our OSS Index source is still active. I tried deactivating it on our Nuget feed, but again: the package remains blocked.

I am not sure what you mean by "override the block as package level". Do you mean setting the package's status? When I do that (setting "Download allowed" to "Always allow downloads" instead of "Use licensing/vulnerabilities rules"), i can download the package. When I set it back to "Use licensing/vulnerabilities rules", the package is blocked again.

Hi @atripp

unassessed vulnerabilities are not blocked:

The vulnerability in question wasn't unassessed originally, btw. It was correctly auto-assessed to "High Caution", which correctly blocked the download of the package. But when I manually changed this to "Manually Unblocked", I should have been able to download the package. This always worked for vulnerabilities from OSS Index.

Here is a picture of our assessment types if that helps (the first four are automatically applied to vulnerabilities based on their CVSS if they have one):

We are testing the ProGet Vulnerability Central and we are currently running into a problem (ProGet version 2023.13): We have several assessment types that are automatically applied to vulnerabilities, blocking downloads of packages if the CVSS is above a certain threshold. In addition, we have an assessment type called "Manually Unblocked" that we can apply to issues manually if for some reason we want users to be able to download an otherwise blocked package. This works fine for vulnerabilities coming from OSS Index. However, this doesn't seem to work for issues coming from PGCV:

Is there any reason PGVC would behave differently here?

Also, the "Manage Vulnerability Sources" is kind of confusing. When we click on "Configure Download Blocking" and add Feeds to PGCV, it doesn't show up under "Vulnerability Sources". When we add it explicitly (via "add vulnerability source"), it then shows up twice (once as "PGCV" and once with the name we chose). I don't think this is part of the problem, just seems weird.

@stevedennis
Just wanted to let you know that I tested this with 2023.13 and both issues (PG-2426 and PG-2428) do indeed seem to be fixed with this version. However, it took some time for the package's page to show that the package has been deprecated after I downloaded it. I guess the package analyzer had to run to correctly show the package's state?

What's left is some kind of periodic check for updates on a packages' metadata after it has been downloaded. This would be really useful (doesn't have to be daily, once a week would suffice).

BTW: We are currently looking into the API approach that you suggested and one question came up: Is there a way to add custom scheduled jobs to ProGet (like the UpdateChecker or PackageAnalyzer tasks)? If not, could something like that be added via the Inedo.SDK in the future? I know we can just trigger it with a generic job scheduler, but it would be nice to have all ProGet-related maintenance jobs in one place.

Cheers,
Sebastian

Hi @stevedennis

Some additional info: I deleted the package from ProGet's cache again to test the SCA reporting. However, even though the package's info page now shows the deprecation info correctly, I don't see any warning in my SCA report. I then downloaded the package again and wanted to set the status manually to see if that makes any difference. However, I'm somehow too blind to find a "set status" option. I know that when a package has a vulnerability, I can set its status by clicking on a link within the vulnerability message, but I simply can't find such a link/button for a package that doesn't have any vulnerabilities.

One more thing: you mentioned writing our own "package updater" script using ProGet's Common Package API. Is there a way to list all packages that are cached by ProGet? Because those are the only ones I'd want to check for new metadata. Checking every single package on nuget.org and comparing its data to the data provided by ProGet (or vice versa) would be unfeasible.

Hi @stevedennis

Thanks for your reply. I tried to get the deprecation info into ProGet to see how things look like in VS and in the SCA reports, so I deleted the package from my example above from the cache using the "Delete Cached Package" button. Once the package was deleted, I indeed saw the deprecation info on the package's info page:

However, once I downloaded the package from ProGet, it seems the deprecation info was lost:

Same goes for the package from your example (which had not been previously downloaded and cached on our ProGet installation): Once I downloaded the package, the deprecation info is gone. Does that mean that ProGet does not copy NuGet's deprecation info when downloading a package, even when that status is already set at the time of the download? Is this a bug or intended?

Hi there!

It seems like ProGet currently doesn't handle NuGet's package deprecation feature at all. I saw a post from someone asking about deprecating one's own packages in ProGet, but I'm wondering about the handling of deprecated external packages. Would it be possible to have the follwing features in ProGet:

1. Display deprecation info in Proget
   At the very minimum, the package’s deprecated info should be shown at the package’s info page. This includes any additional info that the package’s maintainer provides, e.g. a custom message and a link to an alternate package, if provided. Compare the info shown for Microsoft.AspNetCore in ProGet and on nuget.org:
   
   
   Optionally, the info could also be shown in the search results (see nuget.org as an example):
   

2. The deprecation info should be visible in Visual Studio / dotnet.exe
   Visual Studio warns users if they use deprecated packages when connecting to api.nuget.org:
   
   However, when connecting to ProGet, no warning is shown:
   
   My guess is that this is another part of the nuget API, that is yet to be implemented by ProGet (like the vulnerability info, see PG-2359).

3. SCA Reporting should report deprecated packages
   Just like warnings about vulnerable packages or packages with unwanted licenses, SCA reports should show a warning when deprecated packages / package versions are used by a release.

4. Handle unlisted packages like deprecated packages
   ProGet allows for packages to be unlisted by user. In those cases, it would be nice if the features mentioned above could be applied to unlisted packages as well (display warning in Visual Studio, issues in SCA reports).

I'm aware that this is probably not a trivial request, because NuGet packages can become deprecated after they have been cached by ProGet, in which case ProGet probably won't update the package's metadata. However, there are already some maintenance tasks running regularly within ProGet (like PackageAnalyzer), so maybe it would be possible to regularly check if if the metadata of cached packages is still the same? Or maybe such an update-task actually already exists?

@stevedennis

I submitted a ticket [EDO-9428] for the "unknown license" issue.

I might open another thread for the "partial blocked licenses" issue later, but could you tell me what you mean by disabling the SCA feature in the Feed Features? I don't think I've seen this option in the Feed Features. Also: there are at least two mechanisms in ProGet to block/allow package downloads: license filters and package filters (in the feed's connector settings). What happens when you combine those filters? Is a package always blocked when it is blocked by one mechanism and allowed by the other? What happens if we'd set the default license filter rule to "Block downloads by default" and allow packages like Microsoft.* in the Nuget connector? Could Microsoft.* packages without a known license be downloaded or would they be blocked?

@stevedennis I just noticed that the fix seems to be offered only for "short" versions (i.e. 1.0 to 1.0.0) but not for "long" versions (i.e. 1.0.0.0 to 1.0.0). Is this intended? I think that in cases where the last version part is 0, long versions could be auto-fixed the same way as short version.

Two more thing we noticed in the current version of ProGet (2023.8):

1. Packages with packageid:// type licenses are still reported as "Unknown License". According to PG-2381 this should have been fixed in 2023.7, but it seems that the problem still persists. When I look at the package's page, the (manually applied) license is displayed correctly, but the SCA report still does not recognize it.

2. We have a certain license type which is allowed in some feeds and blocked in other feeds. We do this to make sure that packages with that license are downloaded from the "correct" feed. This has worked fine so far. However, starting with ProGet 2023, all packages with that specific license show up as issues in our SCA reports. How can we get rid of that? Manually resolving those issues is not an option, as we are talking about ~100 affected packages on a project with daily builds.

@v-makkenze_6348
We have seen similar issues in our projects. In most of our cases, the problem was that the "missing" packages had different versions numbers (not using the Semantic Version MAJOR.MINOR.PATCH pattern). E.g. Owin's version is actually 1.0 instead of 1.0.0 and Microsoft.Web.Infrastructure's version is 1.0.0.0 instead of 1.0.0. It seems that ProGet has problems matching those packages.

We resolved this by creating a legacy feed, manually editing the metadata of those packages and re-uploading them to that feed. The ProGet documentation seems to recommend something similar. It seems that there is a build-in function to do something like that in 2023.7, at least I think I saw something like that popping up when I opened the page of the Owin package in the latest ProGet version. I haven't seen any documentation on this feature yet, though. Maybe the folks from Inedo can shed some light on this.

Hi @apxltd,

Wow, that was fast... I noticed that this was apparently already implemented in 2023.5 (PG-2359). Just wanted to let you know that I tested this with 2023.6 and it works like a charm

@apxltd said in Questions about the new ProGet Vulnerability Central (PGVC):

As for Visual Studio, one of our engineers here just prototyped that, and I think we'll do it. That's much simpler and easy to sneak in a maintenance release :)

Sounds great, looking forward to it

Hi @apxltd,

I think having scores is crucial. Otherwise we would have to manually assess a lot of vulnerabilities by hand.

CVE-IDs aren't really that important. I guess we would only use them to find more information on the issue by Googling them. What would be nice: having links to sources, like a GitHub advisory entry, an NVD entry, ...

CWEs might become interesting at some point, if those would become available as a separate field. One could think of some kind of statistics on categories of vulnerabilities.

One more thing we noticed, but this is a general problem, not related to PGVC per se: I can't see information on vulnerabilities or deprecated packaged in Visual Studio. Nuget added support for vulnerabilities about 2 years ago. As a result, the dotnet client or Visual Studio can display on vulnerabilities of packages.

When I look at the same solution and list of packages using our Nuget proxy feed in ProGet, I don't seen any of that info:

I would assume that Nuget expanded their API to support this at some point and ProGet does not support that functionality yet. Are their any plans to support this?

@stevedennis said in Questions about the new ProGet Vulnerability Central (PGVC):

[2] 274/566 seems awfully high; several do not have scores, but since we have to compute the score ourselves with equations like these, it's very possible that the underlying data isn't formatted perfect or there's a bug somewhere -- can you share the examples you found so we can investigate?

Sure, what do you need? Here is a little snippet from the Vulnerabilities_Extended view, filtered on Score is null:

External_Id	Package_Name	Package_Versions	Title_Text

GHSA-23cv-jh4v-vffm	Microsoft.AspNetCore.App.Runtime.win-x64	>=3.1.0 <3.1.1	Denial of service in ASP.NET Core
GHSA-23cv-jh4v-vffm	Microsoft.AspNetCore.App.Runtime.win-x86	>=3.1.0 <3.1.1	Denial of service in ASP.NET Core
GHSA-23cv-jh4v-vffm	Microsoft.AspNetCore.Http.Connections	>=1.0.0 <1.0.15	Denial of service in ASP.NET Core
GHSA-2c7v-qcjp-4mg2	Microsoft.WindowsDesktop.App.Runtime.win-x64	>=7.0.0 <7.0.1	.NET Remote Code Execution Vulnerability
GHSA-2c7v-qcjp-4mg2	Microsoft.WindowsDesktop.App.Runtime.win-x86	>=7.0.0 <7.0.1	.NET Remote Code Execution Vulnerability
GHSA-2xjx-v99w-gqf3	Microsoft.NETCore.App	>=2.2.0 <2.2.1	Exposure of Sensitive Information in System.Net.Http
GHSA-35hc-x2cw-2j4v	System.Security.Cryptography.Xml	<4.4.2	Denial of service vulnerability exists when .NET and .NET Core improperly process XML documents
GHSA-365p-96qv-xr7g	Microsoft.AspNetCore.HttpOverrides	>=2.0.0 <2.0.2	ASP.NET Core allow an elevation of privilege
GHSA-365p-96qv-xr7g	Microsoft.AspNetCore.Server.Kestrel.Core	>=2.0.0 <2.0.2	ASP.NET Core allow an elevation of privilege
GHSA-3m2r-q8x3-xmf7	Microsoft.AspNetCore.Server.Kestrel.Core	>=2.0.0 <2.0.3	Moderate severity vulnerability that affects Microsoft.AspNetCore.All, Microsoft.AspNetCore.Server.Kestrel.Core, Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions, and Microsoft.AspNetCore.Se
GHSA-3m2r-q8x3-xmf7	Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions	>=2.0.0 <2.0.3	Moderate severity vulnerability that affects Microsoft.AspNetCore.All, Microsoft.AspNetCore.Server.Kestrel.Core, Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions, and Microsoft.AspNetCore.Se
GHSA-3rp6-rjw4-cq39	Microsoft.AspNetCore.Mvc.Core	>=1.1.0 <1.1.6	Cross-origin Resource Sharing bypass in ASP.NET Core
GHSA-3rp6-rjw4-cq39	Microsoft.AspNetCore.Mvc.Cors	>=1.1.0 <1.1.6	Cross-origin Resource Sharing bypass in ASP.NET Core
GHSA-3wcj-rg8q-9cqv	Microsoft.AspNetCore.Mvc.Core	>=2.0.0 <2.0.1	Open redirect in ASP.NET Core
GHSA-5633-f33j-c6f7	Microsoft.NETCore.App	>=2.1.0 <2.1.7	Tampering vulnerability in .NET Core
GHSA-5f2m-466j-3848	System.Private.Uri	>=4.3.0 <4.3.2	Denial of service in ASP.NET Core
GHSA-655q-9gvg-q4cm	Microsoft.AspNetCore.App.Runtime.win-x64	>=3.1.0 <3.1.1	Remote code execution in ASP.NET Core
GHSA-655q-9gvg-q4cm	Microsoft.AspNetCore.App.Runtime.win-x86	>=3.1.0 <3.1.1	Remote code execution in ASP.NET Core
GHSA-655q-9gvg-q4cm	Microsoft.AspNetCore.Http.Connections	>=1.0.0 <1.0.15	Remote code execution in ASP.NET Core
GHSA-6px8-22w5-w334	Microsoft.AspNetCore.Server.Kestrel.Core	>=2.1.0 <2.1.7	Denial of service in ASP.NET Core

Googling the External_Id of the first entry (GHSA-23cv-jh4v-vffm) leads me to this GitHub Advisories entry, which links to this NVD entry, which mentions a score of 7.5.
If you need more data, I can submit a support ticket and upload an export there.

Hi @stevedennis,

I have enabled PGVC, but the outcome was not exactly as expected:

1. I activated PGVC for our Nuget feed, but I did not delete the OSS Index source, because I wanted a side-by-side comparison of the vulnerabilities. Yet, all my OSS Index vulnerabilities are gone (even the ones for our npm feed).

2. Almost half (274 out of 566) of the vulnerabilities reported by PGVC do not have a CVSS score (OSS Index vulnerabilities almost always have a CVSS score). As a consequence, those vulnerabilities are not automatically assessed.

3. PGVC vulnerabilities do not display the CVE number or a CWE, and in many cases do not provide links to external sources like the NVD.

Is all of that intended and by design?

Hi @stevedennis,

thanks for the quick reply. I was just confused, because all of our vulnerabilities seem to have CVE IDs, so I thought that all of them should be suitable for matching between different sources. But given that there seem to be only 5 manually assessed vulnerabilities left, I guess there isn't really much to actually migrate. We'll try simply switching from OSS Index to PGVC and see what happens...

Hi @atripp,

I just tested the implementation of this with ProGet 2023.1 with the aforementioned atob npm package. The filtering works perfect. The package uses "MIT OR Apache-2.0", and as long as at least one of those two licenses is configured as allowed, the package can be downloaded. Only when both licenses are configured as "blocked", the package is also blocked. This works 100% as expected!

When I check the general page of the atob package, "License Information" on the "Overview" tab displays both licenses and their corresponding blocking configurations correctly.

However, when I go to a specific version, the version's "Overview" tab will always state This package has a MIT license, and may be used because of configured license filtering policies, even if MIT is actually blocked and only Apache-2.0 is allowed. This only changes when both licenses are blocked (In which case the page states Packages with the MIT license cannot be downloaded due to a global license rule).

Looks like this is just optics. As I said, the blocking itself seems to work exactly as expected.

Hi @stevedennis,

I'm not looking for a 100% perfect migration. Basically, I have a certain number of automatically and manually assessed vulnerabilities, and I would like to keep those assessments, wherever the same vulnerability exists in PGVC. In detail: I'm fine with "loosing" all OSS Index vulnerabilities. I'm also fine with seeing a larger number of new PGVC vulnerabilities after switching from OSS Index to PGVC, even if those aren't really "new", but already existed as an OSS Index vulnerability. What I would expect from a migration is this:

1. Auto assess all new PGVC vulnerabilities based on the "Auto assess" option configured for assessment types (I guess this should work anyway and have nothing to do with migrating from one source to another).
2. If a PGVC vulnerability can be matched to an OSS Index vulnerability (based on a CVE number), apply the assessment of the old vulnerability to the new one. If it can't be matched, rule 1 applies.

However, as I was writing this, I was having a look at our current list of vulnerabilities and it looks like we have lost a larger number of them. I currently only have 182 vulnerabilities, and only 5 of those are manually assessed. Is there any mechanism that deletes old vulnerabilities? I know for a fact that I have manually assessed way more vulnerabilities than that to unblock the corresponding packages. None of our assessment types have an expiration, but those should only remove the assessment, not the vulnerability itself, right?

@atripp We are currently testing new ProGet 2023 release. Are there any news about the migration from OSS Index to PGVC? Is there a tool, a script or some kind of documentation available?

@atripp said in SPDX license expressions:

Thanks @sebastian !! Your RegExFu is impressive

Thanks, but to be honest: it's mainly just trial and error

@atripp said in SPDX license expressions:

Hi @sebastian

Just an update; this was committed to the PG2023 code base, and seems to work on a few packages I tried (but I can't find too many).

Basically we just will enumerate the code matches in this Regex: ^\(?(( OR )?(?<code>[0-z-_\.]*))+\)?$

That will catch (a OR b) and a OR b, but if one were to be silly and add ((a) OR (b)) then it would revert back.

Doesn't seem worth getting any more complex than that :)

Thanks for the update on this! I don't think we will see a lot of complex combinations in the wild that are pure OR disjunctions, but just in case someone does something stupid, I took the liberty to slightly modify your Regex. How about this: ^(?>((\s+OR\s+)?(?<c>\()*(?<code>[0-z-_\.]+)(?<-c>\))*)+)(?(c)(?!))$

The \s+ before and after the OR will allow any amount of whitespaces, and the (?<c>\(), (?<-c>\)) and (?(c)(?!)) parts use balancing groups to allow any number of matching brackets (i.e. same amount of opening and closing brackets). Also, I replaced (?<code>[0-z-_\.]*) with (?<code>[0-z-_\.]+) to make sure there are no empty code matches.

I haven't been able to come up with a valid SPDX expression that could not be matched by that Regex, so I think this should pretty much cover it. Only thing that one could add would be to allow leading and trailing whitespaces.

Hi @atripp, thanks for the quick feedback and the insights!

As for the migration part: great to hear that there is something planned. It seems that it would be best for us to wait until some guidance or migration tool is available.

ProGet Vulnerability Central (PGVC) was announced for ProGet 2023 and is available as a preview feature since 2022.20. Would you mind sharing some insights on this new feature? I already have a few questions about it:

1. What is the advantage of using PGVC over OSS Index? Two things I could figure out so far are a) you don't need an API key from OSS (they could stop their free service any time) and b) it's updated with each version update of ProGet (which really only is of any significance if the ProGet server wasn't connected to the internet, in which case I would wonder what feeds there would be to scan...?). What would be other advantages? Does PGVC use more sources? Is it updated faster or more frequently than OSS? Is it more accurate, more reliable, ...?

2. The blog post states that PGVC data is available "instantly" while OSS Index needs to be updated over night. What does that mean? It's my understanding that both databases are updated daily. What is the actual difference here?

3. What about migrating from OSS Index to PGVC? We have a lot of assessed vulnerabilities from OSS. Will ProGet match those to the ones from PGVC? Or will we have to re-asses all of them?

4. What about using both services (OSS Index and PGVC) at the same time? Is that possible (it seems possible in the feeds' settings)? Would it make sense to do that, maybe because both services use different sources or maybe as a form of redundancy/backup?

Hi @apxltd

I didn't realizte ProGet actually already supports multiple licenses. In that case it might make sense to support just the OR operator for now (and see if there is an actual need to support other operators or more complex expressions).

In fact, one could argue that the AND operator actually creates a new license (the combination of the two or more licenses involved), and that it makes sense to treat the combination as a completely new license, while the OR operator offers you a chance to choose one of the licenses. Same goes for the WITH operator: I don't mind treating License Abc WITH exception Xyz as a completly new and different license. So it might make sense to treat OR different to AND or WITH.

The only operator that is similar to the OR operator would be the + operator. Wouldn't it be great if ProGet "knew" that LGPL-2.1 and LGPL-3.0 are newer versions of LGPL-2.0 and that LPGL-2+ means "LGPL-2.0 or later" (effectively LGPL-2.0 OR LGPL-2.1 OR LGPL-3.0)?

Hi @apxltd, thanks for the insights!

I half expected this to be way more complicated than I had hoped for, but one can dream...

@sebastian said in Package license definition:

7. It would require even less effort to just ask package authors to specify license codes, and then eventually the problem will go away on its own probably

Will try this, starting with the Google folks...

One more thought on the last point: What about packages that do not use a supported open source license? Think of Oracle.ManagedDataAccess. There simply is not SPDX tag that matches their proprietary license

That package is actually a good example for a scenario where hash-based license assignments would make a lot of sense. They update their license every now and then. Last update was from version 21.7.0 to 21.8.0. A hash-based license check would have caught that and labeled the new license as "unknown". As a result, version 21.8.0 would have been blocked until someone reviews the new license and manually approves it.

Hi there!

In our ongoing quest to identify the licenses of all packages used in our products (and, eventually, blocking all packages with unknown licenses), we came across license expressions that combine several licenses. The syntax for such combinations is documented here: https://spdx.github.io/spdx-spec/v2-draft/SPDX-license-expressions/

Take for example the npm package "atob" (https://www.npmjs.com/package/atob). It is licensed under both, the MIT and Apache 2 license. Consequently, the corresponding license expression is (MIT OR Apache-2.0). Obviously, this is not recognized by Proget out of the box.

Now, we could define new licenses for every combination of two licenses that we come across. However, I was wondering whether it would make sense to support at least a simple subset of the SPDX license expression syntax, specifically the AND and OR key words. License filtering could then be implemented as follows:

X AND Y: Allow downloading package if both X and Y are allowed.
X OR Y: Allow downloading if at least one of the licenses is allowed.

X and Y could be simple SPDX license tags or another disjunctive or conjunctive license expression.

Would such an approach make sense? It probably would not trivial to implement and I honestly don't know how many packages use such combining expressions (I haven't come across a lot of them yet), so I don't know if it would be worth the effort. Would be nice to hear how everyone else is dealing with such packages.

HI @apxltd,

1. It's even more confusing to use than packageid://, so we'd need to find a better UI solution

Would it be more confusing to have two or three hash values instead of dozens, maybe hundreds of packageid:// entries for a given license? People are getting used to using hash values (e.g. with GIT commits). One would have to be able to view the original license text, of course (see next point)...

2. We'd want to store the full license text as well, so it'd be easy to confirm the contents

Agreed. Otherwise, there is no way of confirming that the hash value was assigned to the correct license. But I don't think that would be infeasible. One could either store the content of the license file in a dedicated table in the database, or in file. And we only have to store it once per hash value. A single license file takes what, 1 maybe 2 KB? Let's say we will have a dozen, maybe a hundred different license files at the end (unlikely, probably more in the lower double digits area). That would take less than 1 MB in total.

3. This is all a nontrivial engineering effort

Agreed, but it's not too complex either. There is obviously already code in Proget which detects that there is an embedded license file and that can display the content of that file. I'd say you are probably almost halfway there :-)

4. We're not sure how many packages this would impact and how much value / time savings it would represent

Here is an example: Consider the Google.Apis.* packages (https://www.nuget.org/packages?q=google.apis). They all have the exact same Apache 2.0 license file embedded, so we would have to assign just a single hash value instead of dozens / hundreds of individual packages.
Another point is updates of packages. At the moment we would have to assign a license to every new version of a package. I think this feature could be a huge time saver.

5. None of this would even work for remote packages, which is by far what most users find confusing and have issues with

Yes, for this to work, Proget would have to download the given package and read to content of its license file. However, there are two major parts of Proget where license become relevant, and I believe the it's not an unrealistic scenario that Proget has downloaded the package in question in both scenarios:

1. Blocking packages. We want to prevent users from downloading packages with specific licenses. Let's assume a user wants to download X with version 1.2.3, and that package has an embedded license file. Now, to be able to serve the package to the user, Proget has to download it first, right? Either it has done so already and the package is cached, or Proget has to download it on demand. In both cases Proget has a chance to read the license file and compute a has value for its content, if it hasn't already done that before.
2. Reporting. Most packages that are analyzed by the SCA feature should have been downloaded in the past via Proget.

6. It would probably require less engineering effort to scan/query all packages on NuGet and make a "database" of package licenses using a little human intelligence

I think downloading all packages (including all versions of each package) and analyzing them would take a lot of effort and resources.

7. It would require even less effort to just ask package authors to specify license codes, and then eventually the problem will go away on its own probably

Will try this, starting with the Google folks...