Posts made by davidroberts63

Thank you, that did the trick.

Proget 2024.12

Can someone point me to documentation on what permission is needed for a user to gain access to the 'Projects & Builds' section of the 'Reporting & SCA' tab? Currently I have some that can see the 'Licenses' part but get a 403 when visiting the 'Projects & Builds' part.

Ahh, that was it. I explicitly enabled the license detection on that feed, reanalyzed it and noticed it found a license. That package and others are being reanalyzed and falling off that list. Thank you for that.

I believe this occurred due to some confusion in the UI. When I originally looked at the feed settings I saw this:

Which indicated to me the license detection was enabled. However when clicking 'change' that option was not ticked. Ticking that checkbox now shows the green checkmark with the same text and the rest of the license checking seems to be working as expected.

That initial text (screenshot from above) is very confusing. Because it literally says license detection enabled. Rather than 'License detection disabled', like the vulnerability detection says when it is disabled on some of our feeds. If it is possible to change that text to reflect the actual status I think that could be helpful to others.

Thank you Alana for your help it is greatly appreciated.

Thank you Alana,

That was very helpful. I appreciate it. I did query that PackageLicense23_Extended view for the 'Microsoft.Identity.Client'. It did show a lot of that package's versions having the MIT license associated with it. However it is in fact missing a record for the 4.66.0 version. Actually it is missing license records for anything after 4.63.0. I did click on 'Reanalyze Package' for the 4.66.0 version, but no change was seen in the UI or the database. I've pasted the results of the reanalysis if it may be of any help.

Package "pkg:nuget/Microsoft.Identity.Client@4.66.0" will analyzed with local data
Package originates from package gallery (https://api.nuget.org/v3/index.json); remote metadata will be used to determine latest patch version instead of local feed.
Attempting to update local package with remote metadata...
No Remote Metadata Provider was found for "https://api.nuget.org/v3/index.json"
Detecting vulnerabilities for "Microsoft.Identity.Client" version "4.66.0"...
Found 0 vulnerabilities.
Searching policies associated with feed "approved-nugets"...
Found 1 policy to use for analysis.
No policies define a latest patch, so latest patch will not be checked.

Here's the query I ran:

SELECT Package_Name,PackageType_Name,Package_Version,Title_Text,External_Id,License_Id FROM PackageLicenses_Extended WHERE Package_Name LIKE 'Microsoft.Identity.Client%' ORDER BY Package_Name,Package_Version

And here is part of the query results:

Microsoft.Identity.Client nuget 4.61.1 MIT License MIT 186
Microsoft.Identity.Client nuget 4.61.2 MIT License MIT 186
Microsoft.Identity.Client nuget 4.61.3 MIT License MIT 186
Microsoft.Identity.Client nuget 4.62.0 MIT License MIT 186
Microsoft.Identity.Client nuget 4.63.0 MIT License MIT 186
Microsoft.Identity.Client nuget 4.7.1 MIT License MIT 186

It almost looks as if ProGet is falling back to the last available license for the package. At the moment, the UI does appear to be consistent with the database data in part.

Would you have any recommendations on how to get the package license information properly updated in the database so the UI removes it from the unlicensed listing?

In Proget, we have a lot of packages that show up on the 'Unlicensed Local Packages' listing, but when we view most of them, the package states it has a known license. Is there some setting that is making this occur? For example:

Microsoft.Identity.Client 4.66.0

Is a nuget that is MIT licensed as noted on nuget.org. When I view the list of Unlicensed Local Packages, that package also shows up there. Clicking on that package and going to the metadata tab it shows 'SPDX Expression (MIT) Known type (MIT)' for license. We do not understand why this licensed package is showing up on the unlicensed listing. Why is this happening? And is there something we can do to correct it?

ProGet
Version 2024.12 (Build 10)

@apxltd At the moment we only have five I think. The adoption rate of it has been slow due to the SCA feature being very interesting but lacking the presentation of some valuable information, such as what this thread addresses. Once the adoption grows with increased information connectivity (builds with the associated packages for instance and this license component) we would likely have more than 300 or 400 build projects.

I would like to add my support for that UI for viewing the Active Builds Using "[license]" and Packages Using "[license]". The recommendation of allowing to sort by the package or the project name would be very helpful. I was looking for this exact view in Proget (2024.12) for the past few days as we have a similar situation.

Also, on the builds page, I'd recommend having a sort and/or filter ability for the Stage. We may want to review production stages as a priority and then the rest as a secondary effort. Filtering or at least sorting would greatly assist in focusing our efforts.

Does there happen to be a PG tracking number that we could follow to be aware when it gets released?

@stevedennis This is perfect. I greatly appreciate this, Steve.

Is there an api call that would return the current version of ProGet I'm running? And is there an api call against indeo.com that would return the available versions and their release date?

I'm looking to build a self-updating dashboard of our pipeline tools. To help us stay on track with what version is in live use and staging, versus the lastest available and how old each are.

Haha, I missed it by one minor verison. :-D

Sounds good. Thanks for the quick response. Means I get to test my scripted upgrade process. :-D

Have a good one.

We have an assets folder with an LDAP group assigned 'NuGet Uploaders' permissions. The users can create directories but get the following exception message immediately when clicking 'Add Assets':

Inedo.ProGet.WebApplication.SecuredTaskDeniedException: [USERNAME-HERE] is not permitted to perform the Feeds_AddPackage task for the current scope.

I've also tried granting the users all permissions except administrator as well as assigning the individual them-self as opposed to a group. But neither approach seem to allow the user to upload a file. I, as the proget administrator, can successfully upload a file to the asset directory. I've checked the tasks given the various permissions I've tried. 'Add Packages' is part of the permissions involved.

Are there any recomendations on how to get the user the ability to upload a file to the asset directory?

Product: ProGet
Version: 4.8.2

Somewhat similar to the post you've read already, but I've provided an answer to this kind of problem before:

https://inedo.com/support/questions/7990

Basically it's setting up two IIS sites, one with Windows auth the other with Basic Auth (or anonymous if you want). One instance of ProGet, but two ways to get to it.

We've been successfully using ProGet with both Windows Auth (for .NET nugets) and Basic Auth (for npm and docker) for about a year now, with the configuration described in the post I referenced.

David

Jon I've run into the same issue before dealing with the npm feeds. I ended up hosting the proget site twice in IIS under different hostnames.

In IIS we have two websites:

proget.mycompany.com

• Windows Auth enabled
• Forms Auth disabled
• Anonymous Auth disabled

formsauth-proget.mycompany.com

• Anonymous Auth enabled

Both sites use the same physical path of your proget installation. The host name in the binding must be different though. That is so IIS knows which way to go, the website with Windows auth or the site with the anonymous auth.

We've been using this for several months with no problems. I hope it helps in your situation.

Please note, I do not work for ProGet, I'm a fellow customer offering assistance.

Gordon,

Have you made any changes to the web.config in the Proget website? Also, can you go through some of the IIS settings as well? Version of IIS, authentication modes that are enabled. Also, take a look at the providers for 'Windows Authentication' and what does that list look like?

I did a little digging and found a somewhat similar situation on a completely different product (SiteFinity). In that forum discussion there is talk about changes in the web.config causing the issue. Thus why I'm asking about what your proget installation web.config looks like.

https://www.sitefinity.com/developer-network/forums/bugs-issues-/error-throw-then-pool-web-app-restart

Please note, I do not work for ProGet, I'm a fellow customer offering assistance.

I'm not sure if you can use the V3 url in a ProGet connector. I believe I've tried and it wouldn't' work. I defer to ProGet employee's to confirm that.

However, that won't affect your developers using VS 2017. They can connect to ProGet with the url that you provided earlier and they will see the same results. I have about 80 developers across VS 2013, VS 2015 and VS 2017 all using the same ProGet url, and all are working fine with the nuget.org connector in ProGet.

Please note, I do not work for ProGet. I'm a fellow customer offering assistance.

As an alternative choice you can use Powershell for this. Add a 'Windows Powershell' step (be sure to install that Jenkins plugin first):

DIR -Recurse -File -Filter "*.nupkg" | @{
& nuget.exe push $_.FullName -Source https://urltoyourproget/nuget/feedname
}

You will also need to ensure you have the nuget.exe command line executable available to the Jenkins node running.

Please note, I do not work for ProGet, I'm a fellow customer offering assistance.

You are correct, the 'NuGet Uploaders' task is a custom one I made, it's been a while since I did that and did not immediately recall it as such.

That said, our use case is that the one administrating ProGet (myself and a few others) define what licenses are allowed in a separate feed. We have a set of developer architects that are responsible for reviewing which packages get put into the feed. Some of the packages they appropriately want to upload to the feed have an 'unknown' license. The dev arch then looks into the package and sees the url pointing to what reads as a particular license (likely a file in the project github repo). They would assign it correctly.

We would watch the new url license assignments and verify (trust but verify) ourselves outside of that process to allow them to move forward. Below is a workflow of what we have setup:

Arch upload -> import-nuget-feed -> assign license -> arch promote -> approved-nuget-feed

• Arch has upload access to the import-nuget-feed
• Arch only has promote access to approved-nuget-feed
• approved-nuget-feed has license restrictions on it
• Arch would assign license of the package while in the import-nuget-feed
• Devs use approved-nuget-feed for development

The archs would not need proget administrative rights, because they are not administrating the running and operations of Proget, just the content within it.

I hope that makes sense. I appreciate your time in this.

What permissions are required for a group/user to be able to 'Assign License' to a package that has an 'Unknown' license in the nuget/node package in a specific feed?

I am logged in as an Administrator and see the 'Assign License'. However when I give someone the 'NuGet Uploaders' task they don't see the 'Assign License' button. I also added the 'Manage Feed' permission to the 'NuGet Uploaders' task to see if that would work but it did not provide that button to the user.

Product: ProGet
Version: 4.8.2

Wonderful!

Worked just as you said it would. Thank you very much Alana.

I can understand what you are saying regarding 'system level' tasks. However, I'm not trying to scope a system level task.

In my original question you may note I'm trying to scope 'Download & View'. Which upon looking into the 'Cusomize Tasks' as you mention (thank you for pointing that out to me, very handy), the 'Download & View' has 'Download Feed' and 'View Feed' only. And both of those have the 'F' marker denoting that it can be scoped to a feed. Yet, my display shows 'n/a' still.

Am I doing something else wrong?

I will definitely look into the extension documentation. Thank you for mentioning it.

But, you're saying this won't work?

https://www.nuget.org/api/v2/Packages()?$filter=IsPrerelease%20eq%20true&$top=10

I imagine I'm misunderstanding something you said, or there maybe something else I'm not aware of when querying nuget.org.

Upgraded from 3.8.1 to 4.8.2.

Now in 'Tasks' I see 'Scope' set to 'n/a' on most of our assignments. We have the same groups granted permissions to multiple (but not all) feeds. How can I now see the details of these permissions?

Example of how it looks:

Task :: Scope :: Users & Groups
Download & View ::  n/a ::  AllDevelopers, AllDevelopers, Vendors, LicenseRequired, LicenseRequired

Example of how I'm expecting it to look:

Task :: Scope :: Users & Groups
Download & View ::  ApprovedNugets ::  AllDevelopers, Vendors, LicenseRequired
Download & View ::  LicensedNugets ::  LicenseRequired

This is so that I can confirm that the settings are correct. The way the UI is now, I have no way to know if the settings are correct and which ones to remove if need be. Note, the security is correctly applied (those that should have access do, those that should not have access are correctly denied), it's that I cannot see the settings as I did before.

Product: ProGet
Version: 4.8.2

Recently went from 3.8.1 to 4.8.2 and now have better connector functionality, thank you. However, we are seeing the pre-release packages show up in feeds with a nuget v2 connector. How can we filter those out? Specifically when we view a package with dependencies if the dependency has a prerelease package, that's the one we end up seeing and linking to in the web UI.

An example:
Serilog.Sinks.File v3.2.0 requires Serilog (>= 2.3.0)
Serilog's latest published version is 2.5.1-dev-00890 (which we don't want to see in ProGet).
Serilog's latest non pre-release/stable version is 2.5.0 (which IS the one we want to see in ProGet).

An alternative behavior would be that the pre-release ones show up but everything would default to using stable/non-pre-release packages unless specifically called out to include them by the user. Same as on nuget.org.

Product: ProGet
Version: 4.8.2

I'm still seeing that caching problem that you mentioned.
v3.8.1(build10) IIS hosted

1. Edit feed that has no connector
2. Add connector "http://localhost" (for testing, others can do the same as long as it errors on first try)
3. View the feed, see the delayed 'loading' and then the 'error with a connector' at top
4. Edit feed again. Remove that connector (just the red x)
5. View the feed, see the delayed 'loading' and then the 'error with a connector' at top
6. Edit feed again, change description (or something to trigger a save).
7. View the feed, see the delayed 'loading' and then the 'error with a connector' at top
8. Recycle app pool
9. View the feed. Problem gone.

I repeated the above process three times to make sure. I also waited about five minutes between step 4 and step 5 to see if that would do anything.