Posts made by jw

@stevedennis

Thanks for the updated version - it works smoothly now.

Unfortunately this difficult to debug on its own, and it will be impossible to debug w/o the database itself, but if you're comfortable with SQL feel free to modify or tweak. It's not an easy script :(

Yea, the size and also the fact that it deletes things puts that out of my comfort zone. ;)

We haven't yet run this against all customer databases yet, but it's our list this week. If you haven't sent us your database already, please do :)

You can find our database in EDO-10311, I have also extended the expiration date in case you need to redownload.

Executing a revised version manually is perfectly fine for me, if you decide not putting it into the 2024.2 release. I'd appreciate clear communication what should or should not be done with the next update to get this fixed.

Thanks for the effort.

Thanks for the script, it does indeed find a few things.

I have an error all the way at the end of the script. Is this because I ran it on a 2023.32 database and it is only supposed to be run on a 2024.x database? (Only used DryMode so far)

Deleting Duplicate Ids...
Error: The DELETE statement conflicted with the REFERENCE constraint "FK__FeedPackageVersions__PackageVersionIds". The conflict occurred in database "ProGet", table "dbo.FeedPackageVersions", column 'PackageVersion_Id'.
[2024-04-29 17:57:00] 206 rows affected in 356 ms

The reason I'm asking is that I'm not quite sure how to proceed with our instance.

I want to avoid running into the same exceptions that were mentioned above. From the changelog it was not quite clear to me if these issues have been addressed in code or we really need to run a cleanup script before upgrading.

From what I've been told, our database has duplicates that only differ by casing of the package names. So, if there is any script to identify or clean these duplicates I'd be happy to give it a shot.

Is this issue addressed in the 2024.1 release?

A clean-up script, that is supposed to remove the duplicate entries, was mentioned to be included in a post 2024.0 release, but I could not find anything in the changelog.

@atripp said in NuGet no longer works after upgrading to 2024:

Offhand, I believe it's a result of "bad data" (duplicate packages) that are in your database, and it's the same issue behind here: https://forums.inedo.com/post/15730

Hi Alana,

before we run into the same thing, is this by any chance the same "bad data" you mentioned in EDO-10311?

We're in the final stretches of ProGet 2024 now (looks like we're on ci-27 as of this morning); you're welcome to try it, we've been using it for a bit ourselves. It seems to mostly work.

I've been looking into ci-30 a bit, since I had some issues with the SCA API, but it seems they still persist in this version.

• https://docs.inedo.com/docs/proget-sca-releases-get

  • I cannot get the /api/sca/releases?project= to work, I always get some Persisted object is not a ProjectReleaseConfiguration. HTTP 500 error.

  • According to docs ReleaseInfo does not contain the id, it would be good to have that there. From what I understand the id is needed for the /api/json/Projects_GetBuildInfo?ProjectBuild_Id= API

  • Few docs issues

    • releases endpoint should probably be builds now
    • /api/sca/releases?name= is mentioned a few times but the parameter should probably be project

• Export SBOM for both formats is still broken for me in this version.

• Version number is cut off in the UI
  

• The SCA Events seem quite granular
  
  Do these really fire for every single "noncompliant package", "vulnerability detected" or "issue opened"?
  I was hope something along the lines of "Build Added" that fires after a new SBOM was imported, containing the build id, project name and build version

Thanks for squeezing these all into the upcoming release.

On semi-related notes:

Does it make sense to give feedback about SCA 2024 issues for the 24.0.0-ci.5 version, or will there be a RC before the release?

I'm afraid this is a bit too granular for us now, but it's something we can consider re-evaluating down the line, especially as we will likely want to add specialize permissions for projects, policies, etc. We expect that will happen later in the year, after ProGet 2024's new features get more adoption. We'll see if anyone else requests package-level permissions, etc.

Thanks for the feedback, let's see if there is more demand.

As for the Advanced, I put a note in ProGet 2024's final touches to address that. Honestly I thought those were only on Debug builds only, but clearly not... thanks for reporting!

Glad to hear it is just an UI issue, I was worried users could mess with metadata.

Cheers

As of 2023.32 the right to mark a package as deprecated is tied to the Unlist Package permission.

This permission also allows modifying download rules and unlisting, which is not something we want developers to be able to do.

We would like to have a dedicated Deprecate Package permission that just allows that and nothing else.

Thank you for considering.

Also a question:

The text boxes Advanced tab on the Set Package Status popup seem to suggest that publish/download metadata could be changed here, but changing anything has no effect.

What is the intention here? These text boxes should probably not be there?

I think it makes sense to put the SCA 2024 Preview UI feedback in a different post, or this one will get too long.

Here a some of the issues my colleagues reported to me.

Version: 2023.32.
For a user with the following permission set:

1. Top menu bar - Replication /

Link leads to 403 page and exception is recorded in admin log.

=> The replication link should be hidden if the feature is not licensed or at least be moved into the admin panel. A user without permissions should never be able to see that link, since they usually have no business configuring it.

2. Packages and Container page /packages and/containers

The bulk edit menu is always visible, clicking on it shows a menu with delete or promote option. Selecting Delete selected results in no action at all, which is misleading.

=> The "bulk edit" link should be hidden for users that do not have delete or promote permissions in any feed.

What might be a bit more tricky to handle is the case when users have local feed permissions. Some feedback to the user about what did or did not happen would probably be a good start.

3. Package page /feeds/nuget-feed/package-name/1.0.0

The Repackage Package and Reanalyze Packge link both lead to 403 pages and exceptions are recorded in the admin log.

=> Both menu items should be hidden

4. Package metadata page /feeds/nuget-feed/package-name/1.0.0/metadata

details link causes 403 and exception is recorded in admin log.

=> There should probably be two links "view" and "edit"
View should be available for everyone regardless of permission, since they can just navigate to the file tab and find the embedded license file directly. Edit should only be visible with appropriate permissions.

My colleagues have reported a few issues with the ProGet UI to me. Usually it revolves around them seeing a link or a button but when they click that element, either nothing happens or they receive a 403 error, either in-page or as popup.

From permission point of view this makes totally sense, as they are trying to access resources which they are not authorized for.

I tend to agree with them that from a UI/UX perspective this is a bit annoying.

From what I could gather from the ProGet UI is that the general design philosophy seems to be to hide elements (links, buttons, pages, panels, etc.) when a user does not have the appropriate permissions.

Is my assumption here correct and does it make sense for me to report those issues that my colleagues and I have found?

Looks like success!

Thanks for addressing this so quickly.

Updated my test instance from SQL Server 2016 - 13.0.4001 to 13.0.6435.1, which should be the latest if one ignore Azure features - still no luck.

This is what the activity monitor looks like during job execution. The average seems to be around 900-1000 batch requests/sec. No idea if that is normal or resonable.

Is it always failing with the follow?

Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host..

Yes, the error is exactly this one every time.

Looking over your Prod dates... did you happen to upgrade after 2024.03.14? Or maybe that's when you enabled the preview feature?

The production instance was coming from 2023.29, the .30 was skipped and the .31 applied only on 22.03.

My test instance is a bit tricky, since I did not track when I was updating something or enabling preview features. Inedo Hub says my last installation was on 17.03.2024, so that must have been the upgrade to .31, I was slightly off in my screenshot.

Inedo Hub log does not seem to reveal which version was installed in the logs. Can I find that somewhere else?

Could you try running sp_updatestats and cleaning fragmentation on those tables usig SQL Management Studio? Clearly there's something we're missing here...

Just ran the command on my test instance. According to the output nothing was updated. Ran another VulnerabilityDownloader job to double check, but it failed again.

I will now try to patch my test instance (SQL Server 2016) to the latest version and see if that helps in any way.

I have found that my test instance also suffers from the same problem.

Both instances and their SQL-Servers are running on Windows and were installed with Inedo Hub. The only modification that was done to SQL Server is making the instance remotely accessible via TCP.

Hardware should not be an issue, both VMs have 4 (or 8) cores, 8GB RAM and SSD disk space assigned to them.

What is interesting that the error is not actually time related. On my local test instance, that has a more powerful CPU, the same error occurs, but already after 6-7 minutes.

From the execution logs it seems like it is unrelated to a particular version or upgrades and rather some issue that appears over time.

The screenshots below show all available execution logs for the VulnerabilityDownloader. I marked the date when ProGet was updated to to a particular version left in the tables.
Production instance:

Microsoft SQL Server 2022 (RTM-GDR) (KB5032968) - 16.0.1110.1 (X64) 
	Nov  9 2023 22:31:58 
	Copyright (C) 2022 Microsoft Corporation
	Express Edition (64-bit) on Windows Server 2022 Standard 10.0 <X64> (Build 20348: ) (Hypervisor)

Test instance:

Microsoft SQL Server 2016 (SP1) (KB3182545) - 13.0.4001.0 (X64) 
	Oct 28 2016 18:17:30 
	Copyright (c) Microsoft Corporation
	Express Edition (64-bit) on Windows 10 Pro 6.3 <X64> (Build 19045: ) (Hypervisor)

ProGet 2023.31 (Build 5)

Executing the VulnerabilityDownloader job always leads to the error below:

Updating local PGVD index...
Downloading latest vulnerability definitions from Inedo Security Labs...
Download complete. Unpacking database...
Processed 1000 entries.
Processed 2000 entries.
Processed 3000 entries.
[...]
Processed 37000 entries.
Processed 38000 entries.
Processed 39000 entries.
Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host..
Update complete.

Few observations:

• The whole import runs around 12mins before it dies
• One thread of the SQL Server is sitting at 100% CPU during import
• The import progress slows down significantly after the 25000 entries mark

Initially we thought our anti virus is slowing down things too much, but even after excluding everything ProGet-related this error still appears.

Another somewhat related question:

When a SBOM scan is uploaded, no issues are created initially even though the UI suggests that analysis was done already. One has to run analysis a second time with the issue checkbox set for issues to be populated.

Is this intentional or what is the idea behind that?

I was expecting to get a full analysis after uploading either via API or UI.

I can understand that this is a lot of effort and really appreciate that this request is not discarded right away.

The workaround you proposed is something that I have already looked into myself.

To make this work smoothly, a webhook for SCA events would really be immensely helpful. Is something like that already on the 2024 SCA roadmap?

However, the package metadata should already be in ProGet by the time you upload the sbom. When doing package restores from ProGet, the packages will be cached automatically. If that's not happening for you, make sure to clear your nuget package caches.

Not all packages will always be acquired via the remote restore mechanism, as I eluded to here.
They still should be analyzed by SCA and not show up on SCA as "inconclusive".

For example, I just cannot get the System.Security.Cryptography.Primitives populated in the ProGet cache, via regular dotnet restore. The package is always taken from the local dotnet SDK installation folder.

There are also other cases like these framework packages. We have a number of people working via VPN and for performance reasons they are access nuget.org directly, via Microsoft's CDN, which gives them much better performance. Their restore operations will not trigger cache population in ProGet.

Bottom line, there are plenty of scenarios why a package might not be readily available in the ProGet package cache.

Ultimately we designed the SCA feature is designed to be used in conjunction with ProGet as a proxy to the public repositories. It's not a "stand-alone" tool, so it won't work well if packages aren't in ProGet.

The reason is, if the package metadata isn't in ProGet, it has to be searched for on a remote server. In your sample (one build, two packages), you're right.. it's just a few seconds to search that data on nuget.org. But in production, users have 1000's of active builds each with 1000's of packages... and that *currently * takes about an hour to run an analysis.

That is how every other SCA systems works, that does not have a built-in package server.

Right now we are using DepTrack behind ProGet as a caching proxy. If DepTrack wants to analyze any package it will just pull the information from ProGet, if that package is already cached, great. If that package is not cached ProGet will download it and it will be cached from here on out, zero manual intervention required.

This very same scenario will not work in ProGet without manual intervention by either adding packages on some exclusion list or downloading them manually to populate the cache.

This limitation will always put ProGet SCA in a disadvantage when being compared to other systems.

Adding 100k's of network requests to connectors to constantly query nuget.org/npmjs.org for server metadata would add hours to that time, triggers api rate limits, and causes lots of performance headaches. Plus, this "leaks" a lot of data about package usage, which is an added security concern. This is a major issue with tools like DependencyTrack - they're basically impossible to scale like ProGet.

I agree, this is not how things should be set up. If someone decides to run a setup like this, they are not doing a good job.

ProGet should always be in the middle as a caching proxy and the cache download should only be there to fill the gaps for packages that for whatever reason are not available yet.

I was pleased to see that the license files for OSS licenses are now part of the ProGet database and can be accesses via API, so thank you for that.

There might be a small problem with ill-formed files. I have only verified this for the Apache-2.0 license, but others seem to be affected as well.

Viewing the files from the ProGet UI, there seem to be line breaks missing:

A comparison between what can be downloaded from the ProGet /api/json/Licenses_GetAllLicenseData API vs. what is stored in the SPDX GitHub repository:

https://raw.githubusercontent.com/spdx/license-list-data/main/text/Apache-2.0.txt

Hi @apxltd

Thanks for the response. I will try to not reiterate the cache issue too much, as I have raised it here before
https://forums.inedo.com/topic/3953/proget-sca-missing-package-because-of-nuget-proxy-cache-miss/6?_=1710244266850 and also in my mail about ProGet SCA Feedback to you.

We were really hoping this would be improved as part of the SCA 2024 changes. Both current solutions, either manually downloading missing packages or maintaining exclusion lists seems like a workaround to something that could be fully automated.

I expect this to be one of the first questions my colleagues will ask me, once I introduce them to the SCA features. ProGet should try to do its absolute best to create the most complete analysis possible, even if that means it takes a few extra seconds. All the manual effort that should go into it, should be focused on solving the actual issues, like assessing and fixing vulnerabilities.

Package detection is still a lot hit or miss like in the previous version.

Here are two packages pulled in via nuget.org ProGet proxy, one is detected perfectly fine the other one raised an issue as "Package not in feed". When navigating to both of them they are found and reported with green label (no vulnerabilities or license violations).

What is also a bit confusing is the "inconclusive" label. To me this would mean the state of the package could not be determined, but on the issues package it gives a proper "Package not in feed" explanation. I would expect to see this state here too.

Three closely related issues:

1. When trying to bulk delete a project from /projects, I get a popup with the following error:

(500) Server Error
The DELETE statement conflicted with the REFERENCE constraint "FK__ProjectIssues__Projects". The conflict occurred in database "ProGet", table "dbo.ProjectIssues", column 'Project_Id'. The statement has been terminated.

2. The button Disable ProGet 2024 Projects (Delete All Builds) does not work
   When clicking the button the page reloads, but nothing changes. This might be related to the error above.
   **Edit
   Just found out it actually works, the builds are removed only the projects stay there, as the button text actually suggests.

3. I did not find any other menu option to delete a project or a build anywhere in the UI
   The only thing I found is the project bulk delete option which suffers from the issue above.
   Am I missing something?

@rhessinger

Thanks for the update, looking forward to the next release.

When trying to upload a SBOM JSON file create with recent tooling to ProGet 2023.30 (Build 16) the following error is returned:

(500) Server Error
Unsupported specification version: 1.5

Are there any plans to support this spec version?

@stevedennis

Famous last developer words: "Changing this one flag can't possibly break anything"

Thank you for considering

Cheers

We are also interested in README rendering.

I've been looking to find where the project URL is displayed, but were unable to find it. Maybe this could be added aswell?
https://learn.microsoft.com/en-us/nuget/reference/nuspec#projecturl

Also related is the releaseNotes field, that would be similar to README rendering
https://www.nuget.org/packages/Microsoft.Extensions.Configuration/9.0.0-preview.1.24080.9#releasenotes-body-tab
https://learn.microsoft.com/en-us/nuget/reference/nuspec#releasenotes

Essentially we are looking for a way to make changelog information of a given package easily accessible to developers.

I'm looking to enable HTTP to HTTPS redirection in ProGet.

Is this something that could be added?

https://learn.microsoft.com/en-us/aspnet/core/security/enforcing-ssl?view=aspnetcore-6.0&tabs=visual-studio%2Clinux-ubuntu#usehttpsredirection

An option to opt-into this behavior would be very much preferred to having to install another webserver/proxy just to handle this redirection.

Hey @atripp,

Thank you for that snippet, very insightful.

Oddly enough that issue is still on the .NET 8 Planning milestone, even though .NET 8 was already released this November. Ah.. one shall not question Microsoft's planning... ;)

On a server with multiple IPs, I tried to bind ProGet only to one of those IPs with Port 80 and 443 while using the integrated webserver and bind another webserver to the same ports of a 2nd IP.

<WebServer Enabled="true" Urls="https://192.168.0.1:443;http://192.168.0.1:80" Subject="mycert" Store="My" Location="LocalMachine" AllowInvalid="True" />

I observed that for some reason ProGet is using the Kestrel server when the binding a port on all IPs (https://*:443 ) but switches to HTTP.sys when binding a specific IP like I tried with the config above. This can be observed with tools like netstat or TcpView. With Kestrel the ports are held by the application exe itself, while with HTTP.sys hosting the ports are occupied by the System process.

The problem with HTTP.sys-based hosting seems to be, that even though the ports are only bound on one IP, they are also blocked from being used by another process on another IP. Once the ProGet service starts, both ports show up in the port exclusion list netsh int ipv4 show excludedportrange protocol=tcp.

As far as I know there usually is no reason to use HTTP.sys unless specific features are required (see here). Kestrel should also be capable of binding to concrete IP:Port combinations.
Also with Kestrel all these netsh http add urlacl settings don't seem to be required anymore. I made a small test app and I could bind my process to a port below 1024 without urlacls just fine when using Kestrel and running the process as Network Service.

I'd be interested to learn why ProGet is switching between Kestrel and HTTP.sys for these two IP binding scenarios. Also any pointers how to reuse the ports on another IP would be very welcome.

Thank you for the pointers.

I think I finally got it working, though I must admit I'm still not a 100% sure what combination in what order actually led to success.

I'm already in contact with @apxltd about your planned SCA changes. I will try to write up what tripped me as part of that feedback.

Hi @stevedennis

I have this feed feature enabled:

Or are you referring to the SCA setting "Vulnerability Download Blocking Configuration"?

Hi @atripp

I tried what you suggested. Here is the output from the PackageAnalyzer job:

DEBUG: 2023-10-17 11:53:19Z - Fetching list of licenses...
DEBUG: 2023-10-17 11:53:19Z - Found 327 licenses.
DEBUG: 2023-10-17 11:53:19Z - Analyzing 1 feeds...
INFO : 2023-10-17 11:53:19Z - Beginning analysis of nuget-proxy feed...
DEBUG: 2023-10-17 11:53:19Z - Fetching list of known NuGet vulnerabilities...
DEBUG: 2023-10-17 11:53:19Z - Found 0 vulnerabilities.
INFO : 2023-10-17 11:53:19Z - Recorded data for 1 packages in nuget-proxy feed.
DEBUG: 2023-10-17 11:53:19Z - Analyzing 1 active releases...
DEBUG: 2023-10-17 11:53:19Z - Analyzing TestProject 1.0.0...

Sadly, no matter what I do (delete and reupload, overwrite, clicking on "analyze" on the Release), the vulnerability is never shown.

Is there anything else I could try?

Ran into some potential bugs when evaluating SCA vulnerability scanning.

Tested on Version 2023.20 (Build 14)

1. The two marked settings behaving strangely. Either I cannot save them and they revert to the unconfigured state, or they are actually configured and I cannot remove them no matter how often I configure and save them. Not exactly sure how to create either state, also happens to me on a clean trial installation.

2. There seems to be some localization issue on the "Auto assess (VCSS)" option. I'm using an en-US OS but with German regional settings for numbers and dates.

Saving and reopening this shows:

I've been trying to get vulnerability detection with SBOM scans to work for nuget.org packages, but so far no luck.

Here is an example SBOM that should pop up on any scan:
https://privatebin.net/?ca7ad862057815c8#7WzmrR54i6opxoD37dxaE1X7GS67GfcJ79zEps2BTtaS

Clicking on the package shows that the vulnerability is recognized:

The package is also in the package cache, I've manually downloaded it to avoid this issue.

Yet there is not a single mention of this vulnerability anywhere on the SCA release pages:

• I have configured the vulnerability sources (both OSS Index and PGVC)
• I have enabled the vulnerability feature on the feed
• I have added auto assessment, though I'm not really sure if that is even needed. I am not looking to make download blocking work at the moment.

Is there something I have missed?

This paradigm "SCA in ProGet only works correctly when a package was previously put in the cache" should be revisited.

There already seems to be functionality in ProGet that can determine which feed provides a package, otherwise this link here /packages/from-purl?pUrl=pkg%3Anuget%2FMicrosoft.AspNetCore.Mvc%402.2.0 would not work. So the feed identification where to get the information from does not seem to be the issue.

Then on the subject of cache. Caches should be something that are fully transparent. If a package is not in the cache or caching is not available, then the required information should just be pulled from the source.

I do not see a difference between someone restoring a package from a feed and an SBOM requiring a package for running a complete SBOM analysis.

It would be really nice if this could be considered as an improvement to the NuGet SCA experience in ProGet. All the parts already seem to be there, they just need some wiring. Doing this externally with scripts or other hackery seems counterproductive to a well-rounded product.

Hello @atripp,

this is a tricky subject indeed.

As for this particular case, we've seen this too - and just found that downloading the package caused the issue to go away, and that was simple enough since there weren't too many packages (just lots of annoying clicking).

While it can easily be resolved by downloading the packages manually, this is just not sustainable in the long run. Packages change, frameworks change and with every change there is the risk of yet another package missing in the cache and someone having to click again.

I don't think we want to have ProGet automatically download/populate the feed with packages, but perhaps a better way to handle this is some kind of rule or ignore setting for missing packages??

And it'd be nice if ProGet automatically shipped with a list of these too. I really can't think of any reason why anyone would ever want a notice of "Microsoft.Extensions.Localization" being missing. Can you?

Ignoring these packages does not seem like a good solution. Just because they are shipped with the .NET Runtime/SDK does not mean they are not susceptible for vulnerabilities, so I would rather have them being treated as regular packages with full vulnerability scanning etc.

This is probaly something unqiue to NuGet as opposed to other package managers.

Without knowing enough about the ProGet internals, this seems more like a proxy/caching issue for me. The question I would ask first is why ProGet does need the full package in its cache for the SCA tracking to work correctly.
Maybe some degree of metadata would be enough for that?

Maybe a parameter to SBOM uploading/analyzing could be introduced that enables downloading the required metadata or packages (depending on what is really needed) before analysis is started.

I configured a NuGet caching proxy for nuget.org.

When uploading a sbom.json I noticed that a number of open source NuGet packages are reported as "Missing Package". One such example is Microsoft.Extensions.Localization.

These packages do exists on nuget.org and ProGet is also showing them correctly. The issue is that these packages are never actually downloaded during the dotnet/nuget restore process (in fact, they are never part of the build machine's local NuGet package cache) because the dlls of these packages are shipped together with the DotNet SDK.

ProGet SCA is reporting these packages are missing, because since they were never restored, they are not part of ProGet's proxy package cache.

It is possible to click on each missing package, get redirected on the package page and then hit the download button to populate the proxy cache and this also resolves the missing package issue, but this is very inconvenient.

I think there should be a way to automatically populate the proxy caches when uploading SBOMs.

Am I missing something here?

Version 2023.18 (Build 15)

It also leads to an error in the Logs:

The release itself seems to be deleted though, guess just a proper redirection after deletion is missing.

In 2023.10 the field is populated and the history page shows it correctly.

The $UserName variable for web hooks (tested with Teams integration) still shows Anonymous for the same package though.

I pushed the package via nuget.exe with API key.

Assuming I'm actually looking at the correct column (ProGet.dbo.FeedPackageVersions.PublishedBy_User_Name), in does indeed say "Anonymous".

I've just installed 2023.9 but the upload user is still shown as Anonymous on the history page.

Was this issue addressed yet?

Just installed 2023.2 and .snupkg pushing works again for me, so the original issue is solved.

As for the lost packages:

Tried reimporting all the packages and triggering re-indexing once again. This time it completed cleanly.

Looking in the InedoHub Logs, the last version of ProGet I installed was on 05.03.2023, so whichever version was current at this date is the one I updated from to 2023.1.

I cannot find any ProGet version number in the InedoHub installation logs, which is a bit weird...?

@gdivis

Good to hear.

As for the re-indexing, yes I had the option checked and I also recall that the log was full of warnings that hashes of the packages wouldn't match. After the process was finished the feed was completely void of any package.

Unfortunately I did not save the logs, which in retrospect was no so smart..

@rhessinger

Just tested this with another package I had already pushed before - Same exception.

Also, yes, the feed is still configured correctly.

**Edit

• Rebooted the machine
• Tried re-indexing the feed. This deleted all the packages, very unsettling....
• Recreated the feed completely

Still no luck.

The NuGet package is created on disk, so this shouldn't be a permission problem. The matching .snupkg produces errors and is subsequently missing on disk and also not indexed.
API key is configured for both the package as well as the symbol source URLs.
.snupkg support is enabled on feed.

nuget.exe output:

D:\test>nuget push -Source https://192.168.x.x/nuget/nuget-hosted/v3/index.json SourceLinkTestLib.2.0.6.nupkg
Pushing SourceLinkTestLib.2.0.6.nupkg to 'https://192.168.x.x/nuget/nuget-hosted/package'...
  PUT https://192.168.x.x/nuget/nuget-hosted/package/
  Created https://192.168.x.x/nuget/nuget-hosted/package/ 231ms
Your package was pushed.
Pushing SourceLinkTestLib.2.0.6.snupkg to 'https://192.168.x.x/nuget/nuget-hosted/symbolpackage'...
  PUT https://192.168.x.x/nuget/nuget-hosted/symbolpackage/
  InternalServerError https://192.168.x.x/nuget/nuget-hosted/symbolpackage/ 67ms
  PUT https://192.168.x.x/nuget/nuget-hosted/symbolpackage/
  InternalServerError https://192.168.x.x/nuget/nuget-hosted/symbolpackage/ 7ms
  PUT https://192.168.x.x/nuget/nuget-hosted/symbolpackage/
  InternalServerError https://192.168.x.x/nuget/nuget-hosted/symbolpackage/ 56ms
Response status code does not indicate success: 500 (Internal Server Error).

Server log:

System.IO.FileNotFoundException: Could not find file 'C:\ProgramData\ProGet\Packages\.nugetv2\F1\SourceLinkTestLib\SourceLinkTestLib.2.0.6.snupkg'.
File name: 'C:\ProgramData\ProGet\Packages\.nugetv2\F1\SourceLinkTestLib\SourceLinkTestLib.2.0.6.snupkg'
at Microsoft.Win32.SafeHandles.SafeFileHandle.CreateFile(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options)
at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize)
at System.IO.Strategies.OSFileStreamStrategy..ctor(String path, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize)
at System.IO.Strategies.FileStreamHelpers.ChooseStrategyCore(String path, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize)
at System.IO.Strategies.FileStreamHelpers.ChooseStrategy(FileStream fileStream, String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, Int64 preallocationSize)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options)
at Inedo.IO.FileEx.Open(String fileName, FileMode fileMode, FileAccess fileAccess, FileShare fileShare, FileOptions fileOptions)
at Inedo.ProGet.Extensions.FileSystems.DirectoryFileSystem.OpenReadAsync(String fileName, FileAccessHints hints, CancellationToken cancellationToken)
at Inedo.ProGet.Feeds.NuGet.NuGetFeed.InstallOrUpdateSnupkgAsync(Stream stream, Nullable`1 publishDate)
at Inedo.ProGet.WebApplication.FeedEndpoints.NuGet.NuGetApi.PutHandler.ProcessPutRequestAsync(AhHttpContext context, WebApiContext apiContext, RequestData urlData, NuGetFeed feed)
at Inedo.ProGet.WebApplication.FeedEndpoints.NuGet.NuGetApi.ProcessRequestAsync(AhHttpContext context, WebApiContext apiContext, NuGetFeed feed, String relativeUrl)
at Inedo.ProGet.WebApplication.FeedEndpoints.NuGet.NuGetFeedHandler.ProcessRequestAsync(AhHttpContext context, WebApiContext apiContext, NuGetFeed feed, String relativeUrl)
at Inedo.ProGet.WebApplication.FeedEndpoints.FeedEndpointHandler.FeedRequestHandler.ProcessRequestAsync(AhHttpContext context)

@atripp

Thanks for the update, looking forward to the release.

@stevedennis

Is there any news on this subject by any chance?

There is updated documentation with step-by-step instructions here:

https://docs.inedo.com/docs/installation-windows-https-support#configuring-https-on-the-integrated-web-server