Hi @sebastian, thanks for the feedback!

These both could be pretty complex (specially the API) and would thus end up as strategic, roadmap-level items (as opposed to some minor enhancements); we'd already have ProGet v2022 mostly planned out, so it would be a bit before we can consider it.

How's your relational database / SQL skills? If you're comfortable exploring the data in there, it might give you some insight / ideas into what we can do as a low-risk, minor-enhancement that would add a lot of value. Once you're able to see what is possible with the existing data, then it might be a view we can do.

We don't have a "guide" on how to query the tables, but we can assist if you have questions. The database columns should be familiar, but tables of interest: Vulnerabilities, FeedVulnerabilitySources (links feeds + vulnerability sources), and PackageDependents (package consumers).

Thanks,
Steve

Hi @sebastian ,

Your current workflow sounds like it's the best approach for now, albeit cumbersome; there's also the possibility of directly querying the database, and generating a kind of report with your own tooling.

This is of course something we can consider improving, but it's hard to guess where without knowing more details and having real world datasets. So definitely an opportunity for a feature request / collaboration.

Let us know as you solidify your processes and learn what data you find valuable!

Thanks,
Steve

HI @sebastian,

There are three different package records:

• Downloads ("Record individual downloads for advanced statistics")
• Deployments ("Record where packages have been deployed")
• Usage ("Record where packages are being used") - i.e. package consumers

You can add these records for remote packages (or packages that don't even exist on the feed yet), and none of these records should be purged when you delete a package (manually or via retention). If you delete a package, and then add it back, those "old records" will reappear.

The "Download Count" is part of the "server-side package metadata", along with Listed/Unlisted Status, Tags, etc. This is one reason why "Download Count" and "Number of Downloads" can vary.

hope that helps,
Steve

@can-oezkan_5440 just an update, we plan to ship this in the next maintence release in ProGet as PG-2111

@kichikawa_2913 I'm wondering if this might be a regression with the preview feature, but I can't imagine how. I have one other idea, too...

I used the "test privileges" function and it shows that the group has View/Download permissions.

Can you clarify this? The "test privileges" should only work with a username, not a group name. Could share what happens when you:

1. Have a specific user navigate to a package in a NuGet feed, and then try to download it from UI? Is there a specific message body you see? (outside of 403)
2. Enter that same username in the "test privileges" with that particular feed? What are all the permissions you see?

After doing those, the last thing I would try is to revert to the 6.0 behavior, and see if the problem still occurs. AT least that will tell us where to look....

Hi @claes-hermansson_6271,

Great! Our recommend three-feed workflow (unapproved, approved, internal) is similar, and keeps the third-party packages in the first two feeds. This way, you can scan for vulnerabilities much more easily.

As I understand it though, to get full coverage the pgscan tool needs to be installed on every build server, and the pgscan publish... command needs to be implemented in every build?

This is correct. Dependency resolution is complex and often nondeterministic, so it can only really happen at build-time. Hopefully you can templatize pretty easily :)

Cheers,
Steve

Hi @kichikawa_2913 ,

The NuGet client's behavior is based on NuGet.org, where no authentication is ever required to view/download packages. As such, it doesn't pass the API key when doing those queries; instead, you can use a username of api and the password of your api key.

Based on the issue though, it sounds like ProGet is unable resolve the groups; I would use the "test privileges" function on the Tasks page to verify this. Thatw ill show you if the username can download packages or not.

The most common reason that groups aren't resolving is that the member is not directly in the group (i.e. they're in a group which is a member of the group), and you don't have recursive groups enabled; do note that this is really slow on some domains.

Cheers,
Steve

Hi @claes-hermansson_6271 ,

Good question; it sounds like you're creating a Package approval workflow, and are on the right track to thinking about "package governance".

Your observations about licenses and vulnerabilities are correct, and you could simply apply the same vulnerability source to each feed, if you want to use that feature. But i generally suggest putting it in the approved-packages feed (using our workflow above).

A couple important things to note.

All packages have a license (even "no license" is a license), and a package with an unacceptable license (i.e. one you explicitly block) is always unacceptable. There are really no exceptions to this (maybe the CEO or legal officer someone could override this rule?), and if someone accidently uses an unacceptable license, it presents an immediate legal risk that you should remediate.

Very few packages have vulnerabilities, and those that do are usually acceptable to use. Most vulnerabilities won't impact your application, and those that do are usually easy to work-around aren't severe enough to warrant action. Severe vulnerabilities (i.e. where remediation is needed, like log4shell) will likely come up once or twice a year for you... if that.

When a severe vulnerability is discovered (i.e. one that you wish to block), tracking across feeds isn't really that big of a problem, compared to discovering which applications consumed that package. What I would recommend is investing in configuring package consumers (see section #2 of the article).

Cheers,
Steve

Thanks for the update, @janne-aho_4082

1153 packages yields about 2000 quests to ProGet, and I'm guessing you have a connector to npmjs.org, that will probably yield another 1000-2000 requests outbound (e.g. "what is latest version of del for example). It's possible that some of those proxied requests are timing out, and that's why you're seeing 404s. Hard to say.

Can you try using 6.0.9.rc.3 +1.13.1-rc.10? This will have both the LDAP User caching (it wasn't fully implemented in 6.0.8) plus the "memberOf" property caching.

The next step, if you enabled CEIP, we can track down your sessions and find what's taking so long.

Hi @paul_6112 ,

The general philosophy that BuildMaster was designed around is this:

• A "Release" is an intended set of changes to production
• A "Build" is an attempt at implementing those changes
• When a "Build" makes it to production (i.e. the final stage in the pipeline), then the changes were applied to production, thus the "Release" has occurred
• If you want to change production again, then you create a new "Release"

This means that, after build of 1.1 is successfully deployed to production (and no rollbacks are needed, etc.), it cannot be released again. You'd need to do 1.2, or so on.

However, in practice users want to deploy 1.1 build 1234 to production, and then 1.1 build 5678 to production.

So with this, we have a few options:

1. Create the releases 1.1.1234 and 1.1.5678, and then have build 1 (sounds like you're doing this)
2. Create Release 1.1.0 Build 1234, Release 1.1.1 Build 5678, and use a Release Name of 1.1 (this overrides the display in nearly all places)
3. Edit the pipeline, and uncheck "Mark the release and build as deployed once it reaches the final stage."; this will give you more control over changing release status
4. Don't use releases at all (set Release Usage to None on advanced settings), and have the build number be 1.1.1234, 1.1.5678

Definitely open to some other ideas as well. A few users have had to "workaround" this design philsophy, and we'd rather just support it!

Hi @janne-aho_4082 ,

That version will work on 6.0.8 as well! Please let us know, we're eager to get this improved.

Since there's a lot going on, I want to share a summary...

In some maintenance release of v5, we updated Active Directory libraries. Apparently a side effect for your domain was that querying the "memberOf" property of a LDAP user object is really slow. Who knows why.... it makes no sense. But that's LDAP. Anyways, I guess it must not have been noticed from the front-end? Hard to say.

In v6, we redid API authentication. However, we didn't use the LDAP User Cache. We fixed this mostly in 6.0.8, and hopefully fully in 6.0.9-rc.3. That seems like it helped some, but it must be still slow querying the "memberOf" property.

We figured out a way to cache the "memberOf" property, and then applied that to InedoCore-1.13.1-rc.10. So hopefully with the user object cached and memberOf property cached, this should be much faster.

Cheers,
Steve

Hi @janne-aho_4082 ,

No problem, and great you can try this so quickly; PG-2096 is available in 6.0.9-rc.3, and you can install this via the Inedo Hub; https://docs.inedo.com/docs/desktophub-overview#prerelease-product-versions

Cheers,
Steve

Hi @nmorissette_3673,

Unless you blurred out /feeds in your screenshot, the URLS are different:

• Server: /feeds/nuget/Puma.Security.Rules/versions
• Workstation: /nuget/Puma.Security.Rules/versions

Otherwise, I can't help but wonder if there's some rewrite rule, proxy server, or something that's interfering between your workstation and the server

Cheers,
Steve

Hi @martin-noack_4528 ,

This isn't currently supported, in part because it wouldn't be possible to do with cloud storage providers. It also doesn't seem to happen that often, so we didn't implement it.

Is this an operation you'd do often? We can consider adding it, though it wouldn't work for cloud storage because, for whatever reason, the only way to "rename" a folder is by moving each item individually (which can take a long time).

Cheers,
Steve

Hi @claudio_9251 ,

This is most certainly another bug/quirk with Telerik's proprietary feed, and them not following the clear NuGet API specifications

If it's easy we'll consider trying to work-around, but otherwise they really need to be following the API specifications. Or they should migrate away from their own server, like how Infragistics did ;)

Anyway, if you can share the specific HTTP request that is return an unexpected result (it's probably some GET query that returns 404?), then we can try that against the same credentials you sent earlier, and attach a debugger to see what's going on, and if it's an easy fix.

You can find this request by attaching Fiddler, then doing a side-by-side comparison in Visual Studio.

Cheers,
Steve

Hi @benjamin-soddy_9591,

No problem "resurrecting" topics! We definitely want to hear from users about feedback/feature requests.

We still haven't had anyone else ask for deprecation since this request, but I wonder if there's a better solution to solving your challenges than this feature. It sounds like you want to increase governance of your NuGet Packages, potentially with some sort of compliance in mind.

The dotnet list package --vulnerable is probably not what you want for your organization; NuGet's Built-in Vulnerability Scanning is really limited, in part because it only reports on a fraction of known package vulnerabilities (164 as of today). It also won't block packages that you deem problematic, unlike ProGet's feature.

The same is true with dotnet list package --outdated -- it's probably not what you want, because it relies on developers to have to know (1) to run the command, and (2) know what to do if there's an outdated dependency.

There are better ways to manage third-party packages (see How to Create a Package Approval Workflow for NuGet), and you'd better served knowing who's consuming outdated packages (see Use Package Consumers to Track Dependencies

Just some thoughts; like I said, we haven't had any demand for this feature, but these are proven solutions for improving governance of packages as organizations grow/expand their NuGet usage like you are.

Cheers,
Steve

Hi @claudio_9251

I believe that Telerik has a buggy/quirky API implementation, and sends invalid/broken metadata. It happens to work in Visual Studio, and I guess an older ProGet.

Anyways, if you can send us some credentials / instructions to connect to your Telerik feed, we will connect and attach a debugger, and trace the bad metadata.

You can email those to support at inedo dot com -- just reference [QA-743] in the subject. And please let us know when you send them email, because we don't monitor that address.

Cheers,
Steve

Hi @mcascone !

Interesting idea . just brainstorming here :)

Can you share the workflow you're thinking? Like... why do you want to know that a package was repackaged/promoted?

For example...

• I already know that a -rc.xyz version has been repackaged, because we only creat -ci.xyz versions.
• I already know that a package has been promoted, because that's the only way these packages are in a feed

... so this information isn't so helpful to me. Unless a mistake was made, only promoted packages are only in certain feeds, and all packages go through same workflow (repackaging).

Thoughts off the top of my head...

• Promotion records exist in the database, so perhaps easier to show
• Repackaging records are inside the package (I think), so maybe harder to show

Cheers,
Steve

@Michael-s_5143 have you installed using the Inedo Hub?

You can change this in the configuration tab. Otherwise, this is in the Installation Configuration Files.

@mcascone thanks so much for confirming that! This may be fixed in v6 already, but I created the issue PG-2072 just in case it's not.

We should get it shipped in the next or folllowing maintenance release.