Best posts made by sebastian...

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

@kichikawa_2913 Not sure if this is related to your problem, but we had some strange problems after upgrading to ProGet 6.0.8 / 6.0.9 as well, so maybe sharing the following info might help you:

We first encountered problems after upgrading to ProGet 6.0.8: Users could access feeds, but could not download any packages. After upgrading to version 6.0.9 this was resolved.

We then had a problem where access became very slow until users could not access any ressources on our ProGet server anymore (even those with "Anonymous" access rights!). We deactivated the "6.1 Preview Features" and restarted everything (including the IIS). This resolved the issue. We also updated the InedoCore extension, but I don' t think this was related to the problem.

I think the 6.1 features are still kind of buggy. We try to avoid activating them for now.

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 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

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 ).

@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.