Posts made by rhessinger

Hi @udi-moshe_0021,

Thanks for the information and I appreciate the background. Did you try the method of referencing the certificate by it's thumbprint while using the Windows Store? The only logs we have is if you run the IWS in a console instead of as a Windows service. This will allow you to see the console output from .NET when we register the certificate. You can do that with the following command:

"C:\Program Files\ProGet\Service\ProGet.Service.exe" run webonly

Based on the error you originally provided though, that error almost always means that the Service Account doesn't have access to the certificate and it's private keys. Can you tell me a little more about your setup?

1. Are you binding only the port (Urls="http://*:80;https://*:443" in the config file ) or did you configure it for port sharing?
2. Is there a proxy in front of your site?
3. What account are you running your IWS service as, Network Service, local domain account, etc....?

Thanks,
Rich

Hi @udi-moshe_0021,

Certificate configurations can be a bit tricky to resolve due to the many different types of certificates that can be generated. To start, are you using the integrated web server or IIS on your installation?

The first thing to check is that your certificate with either IWS or IIS is making sure that your certificate contains the private keys. That is required for any certificate problems. If you are on Windows, the easiest way to use the certificate is using the Windows Certificate Store. Once you have imported it into your certificate store, check that your have permissions to manage private keys.

If you are still haveing issues getting teh certificate to load, then you may want to switch to referencing your certificate using it's thumbprint.

If you are trying to link directly to the certificate instead of using the windows certificate store, you will still need to make sure the certificate has the private keys included, but you may need to convert your certificate to a ".pfx" or a ".pem" file. Although we have had success using a .crt and a .key file, we find it can be a bit finicky in comparison. Although I don't have the exact command to run, you should be able to easily find openssl commands to convert the certificate. Similar to this command:

openssl pkcs12 -export -out output.pfx -inkey private_key.key -in certificate.crt

It's hard to give an exact command since I don't know all the details on your certificate and key files. We also have some notes on how to convert PKI generated certificates to a ".pem" file in our in our HTTPS Binding to a Port (Advanced) docs. Just scroll down to the Update Configuration file and look at the commands we have there to convert the certificate.

This should be a pretty good starting point for this, but please let me know what works and what doesn't and then we can go from there.

Thanks,
Rich

Hi @Nils-Nilsson,

In order to use SAML with Active Directory, you will need to make sure your SAML claims are returning a Subject's NameID that matches the samAccountName in Active Directory excluding the domain suffix. Then if it finds that username in Active Directory, it will use it's permissions. If it does not find it, it will then create a user in the Built-In User Directory.

The Subject's NameID is a bit confusing because it looks like each service uses a different term for this. For example, EntraID's (Azure AD) SAML claims name it nameidentifier. Really it is whatever claim value is set in the SAML envelope under saml2p:Response/saml2:Assertion/saml2:Subject/saml2:NameID.

As for the callback URL; it is specified in the configuration wizard when setting up EntraID (Azure AD) and PingID, but not for other SAML providers. It also looks like this got removed from our documentation page, which I'll add back now. The callback URL should be https://«PROGET_HOST»/saml-acs-callback .

@dan-brown_0128,

The best way to handle this is to use the expiration feature on API keys or using a separate script (PowerShell, Shell, etc...) in a Scheduled Task or CRON Job to check your SAML or AD provider for access and then use our API to disable API keys. Although I have never set this up, I know many SAML providers offer Webhook subscriptions for when access is removed. That could be another option for disabling API keys in ProGet.

Thanks,
Rich

Hi @pooyan-zamanian_1706,

Sure thing! ProGet 2024.33 is scheduled to release on April 18th. If you need something earlier, we can create a pre-release build as soon as the fix is ready (it's currently going through testing at the moment).

Thanks,
Rich

Hi @pooyan-zamanian_1706,

I was able to recreate this issue and have created a new ticket, PG-2946, to track the fix. This should be released in the next maintenance release of ProGet 2024.33. If any thing changes, I will let you know.

Thanks,
Rich

Hi @pooyan-zamanian_1706,

Thanks for the additional information. This will take me a bit of time to work through. I should have an update for you tomorrow.

Thanks,
Rich

Hi @pooyan-zamanian_1706,

Thanks for sending this over to us. Just wanted to check, does the PGV-2129406 vulnerability have only a single assessment or is there an overridden assessment for that feed on that vulnerability? Also, are both of these packages in the same feed?

The log gives us a good starting point to attempt to recreate it, but I just wanted to make sure I have the base conditions set to recreate it.

Thanks,
Rich

Hi @udi-moshe_0021,

I tested using the following docker command: docker pull test-server-1:8624/qa-2652/geoserver:2.27.x

I have the connector configured with the following settings:

• Connector URL: https://docker.osgeo.org
• Authentication: anonymous
• Timeout: 10
• Attempt to search the container registry: checked
• Do not use library/ prefix for repositories without namespaces: checked

I was able to pull using the docker command above and I also was able to us "Pull Tag" in the interface. One thing I would try is to delete the cached image ProGet using the ProGet UI and then try to pull it again.

Also, could you provide your docker output? Sometimes we see more information in that output if nothing is showing in the diagnostics center.

Thanks,
Rich

Hi @udi-moshe_0021,

Do you see any errors logged in the diagnostics center in ProGet? I did a test of pulling the image using Docker and the Pull Tag button in ProGet and they both worked in my case. I'm thinking you might be rate limited by docker.osgeo.org in your ProGet instance.

Thanks,
Rich

Hi @v-makkenze_6348,

Glad to hear it!

Thanks,
Rich

Hi @v-makkenze_6348,

So this package is a wierd one for sure. NuGet has actually removed it entirely from NuGet.org because it violated their terms of use. I would highly recommend switching to a supported package for that. That being said, there is a great answer in this stack overflow article on it https://stackoverflow.com/questions/1186270/referencing-system-management-automation-dll-in-visual-studio and you can see the removal from NuGet.org here: https://www.nuget.org/packages/System.Management.Automation.dll/

Basically to view this in ProGet, you will have to navigate manually to it in your feed because it is no longer returned in NuGet.org's search queries. You can use the following URL as a template (just swap out host and feed): https://«PROGET_HOST»/feeds/«PROGET_FEED»/System.Management.Automation.dll/versions

Thanks,
Rich

Hi @arose_5538,

We just released ProGet 24.0.31 that has the fix included for this so you do not need to specify those extra environment variables.

Thanks,
Rich

Hi @arose_5538,

There looks to be a bug in our Docker image for 24.0.30. To work around this, if you add the environment variables PROGET_USE_HTTPS_REDIRECTION:false and PROGET_INTEGRATED_AUTHENTICATION:false to your Docker run command or Docker Compose file, that will get you passed the error for now. I have created a ticket, PG-2932, to track the fix going forward.

Thanks,
Rich

Hi @rel_0477,

Thanks for sending over the recreation steps! I was able to recreate the issue and have created a ticket, PG-2922, to track the fix. This should be released in the next maintenance version of ProGet, 2024.30.

Thanks,
Rich

Hi @rel_0477,

Would you be able to send us an example crate and the exact publish command you are using so we can test this issue with? Also, what version of cargo are you using? In my test cases, I'm able to run cargo publish and view them in ProGet.

Thanks,
Rich

Hi @pmsensi,

Thanks for bringing this to our attention. I believe I see what the issue is, but I would like to confirm the issue. Would you be able to run the following query to get me a list of created by names so I can test it locally?

SELECT DISTINCT [CreatedBy_User_Name]
  FROM [AssetItems]

If you do not feel comfortable posting it to the forums, you can email the output to support@inedo.com with the subject of [QA-2618] and just let me know when it was sent. This way I can confirm what is needed for the fix.

Thanks,
Rich

Hi @enrico-proget_8830,

So we have fixed multiple issues with npm, specifically the npm connectors in the versions since you installed. I think upgrading to ProGet 2025.26 should resolve your issue with the ECONNRESET issue. Could you update to 2025.26 and rerun your test and let us know if you are still seeing the issue?

Here is a link to the change list since your version of ProGet: https://my.inedo.com/downloads/upgrade?product=ProGet&fromVersion=2024.22

Thanks,
Rich

Hi @enrico-proget_8830,

Can you please tell me which version of ProGet you are running?

Thanks,
Rich

Hi @steviecoaster,

Thanks! We will take a look as soon as we can!

Thanks,
Rich

Hi @kc_2466,

Thanks for submitting this to us. It looks like there is an issue with packages with 3 or less characters that may fail to download. I created ticket, PG-2886, which will release this Friday (February 3rd, 2025), that will contain the fix for this.

I also want to note that version 2.8.0 of syn does not exist on crates.io, so I verified using syn 2.0.8.

Thanks,
Rich

Hi @jeff-peirson_4344,

I have been able to recreate the issue and created a ticket, PG-2870, to track the fix. We expect this to release in ProGet 2024.25 on January 24, 2025. This looks to be related to the package name existing on npmjs.org with all versions being unlisted. If you need a fix sooner, we can provide a pre-release version of ProGet 2024.25 that includes the fix.

Thanks,
Rich

Hi @jeff-peirson_4344,

Thanks for sending these over. Let me do some investigation on these and I'll get back to you soon.

As for the latest version of the image, we are now on 2024.24. We ran into a replication issue with universal packages in 2024.23 and had to release 2024.24 on Monday.

Thanks,
Rich

Hi @jeff-peirson_4344 ,

For the issue with upack, can you please submit a new forums post for that? So far this post has been about npm and I don't want this issue to get lost.

Thanks,
Rich

Hi @jeff-peirson_4344,

Can you please share the npm package you are having issues with?

Thanks,
Rich

Hi @jeff-peirson_4344,

This is a known issue that we will have fixed in tomorrow's release of ProGet, 2024.23. We are tracking the fix in ticket PG-2860.

Thanks,
Rich

Hi @serveradmin_0226,

Does this error happen after ProGet has been running for a bit or is this the error you get as soon as you start ProGet preventing it from running at all? Can you please confirm which version of ProGet you are running and your SQL Server version? Also, is SQL Server running as part of your Docker Compose setup as well?

Thanks,
Rich

Hi @caterina,

No problem, thanks for getting back to us. We have an upcoming release of pgutil that will include this flag. We also have improved this command a bit by allowing you to use the working directory which will search for the right files instead of --input having to specify the path to the file (although you still can). It will now also automatically audit the scan directly after, you can use --noaudit to skip the audit. We should have those updates pushed this week.

Thanks,
Rich

Hi @caterina,

We are working to add this back, but the hold up has been trying to properly document this. Here is our thoughts, but wanted to get your feedback.

We are looking to change the parameter name to --do-not-scan-node_modules with a command line description of:

Do not scan the node_modules directory when scanning for package-lock.json files

What are your thoughts on this?

Thanks,
Rich

Hi @jw,

I just pushed the latest version of Inedo.ProGet to NuGet.org. Please let us know if you have any issues using it.

Thanks,
Rich

Hi @caterina,

The fix in pgutil corrected the API to enure the proper parameter was passed to the SCA API. There looks to also be a regression on the ProGet side in the SCA API. I have created a ticket, PG-2805, which will be released next week on Friday Oct 4th that contains the fix. If you need the fix sooner, please let us know and we can get a pre-release build out for you.

Thanks,
Rich

Hi @jw,

I have added this to our ProGet 2025 roadmap. If there is a more immediate need for this, please let us know and I can discuss this with the products team.

Thanks,
Rich

Hi @v-makkenze_6348,

I was able to identify the issue, PG-2778, and will have this fixed in the next maintenance release of ProGet.

Thanks,
Rich

Hi @v-makkenze_6348,

Thanks for bringing this to our attention. I need to dig a bit deeper into this, I should have an update for you by tomorrow.

Thanks,
Rich

Hi @j-d-koning_0111,

Just wanted to check in if PG-2738 fixed your issue. We have also been working with another customer that has had similar issues. We determined this was related to setting to Map groups to SAML groups setting. If you have this enabled and do not have any groups claims sent, it was causing the error you saw above. This last issue, PG-2745, will be released in the next maintenance release. As a work around, make sure you have your SAML provider configured to send groups claims.

Thanks,
Rich

Hi @j-d-koning_0111,

I did some more testing and found another scenario where this could error, it's less common, but I'm guessing that is what is happening to you. In certain situations, an authentication cookie may be created for a new SAML user before the user was added to the system. This also would cause subsequent attempts to fail because the cookie was preventing the updated SAML logic from running. This issue has been fixed in PG-2738, which will be released on Friday.

Also, is your ProGet instance running in Docker or Windows?

Thanks,
Rich

Hi @jw,

Thanks for sending this over. I created PG-2731 to track the fix. It should be out within the next two maintenance releases of ProGet.

Thanks,
Rich

Hi @j-d-koning_0111,

I just wanted to let you know that this fix released this past Friday.

Thanks,
Rich

Hi @j-d-koning_0111,

We had another ticket that came in with a similar issue. It looks like that error will happen when the SAML response does not include an email or a display name. We have a fix, PG-2727, that will be released on Friday in ProGet 2024.9.

Thanks,
Rich

Hi @j-d-koning_0111,

Thanks for that information. Which user directories do you currently have enabled in your instance? I'm wondering if the user is being found in another user directory and that might be cauising this issue. Unfortunately, I'm unable to recreate this error in testing.

In addition to the other user directories you have enabled, are you able to provide me the steps you took to setup your SAML integration?

Thanks,
Rich

Hi @j-d-koning_0111,

I received your email and took a look. It looks like everything is working on the SAML translation side. It was able to properly parse the SAML response. So that leads me to believe that it is happening while attempting to login. Do you see the SAML user show up in your Built-In users?

Also, when trying to log in, do you see that error in the diagnostics center in ProGet? I'm wondering if we can see a stack trace for that error to help narrow down what is causing the issue.

Thanks,
Rich

Hi @j-d-koning_0111,

This is most likely an issue with a claim configuration in Entra ID. The best way to start debugging this is use ProGet's SAML debug callback page (requires ProGet 2024.6 or later). That will allow us to see the SAML response that was sent back and the results of our parsing. To view this, you will need to update your SAML callback to be http://<YOUR URL>/saml-acs-callback-debug. Once you set that and you attempt to login using SAML in ProGet, it will redirect you to the SAML Debug page that will show you all this information. Please note that with the debug callback enabled, you will not be able to log into ProGet with it, it will only show you the SAML information.

Once you configure the debug page and navigate to it, can you send me the contents of that page? That will allow us to determine what exactly is causing the issue. For security reasons, you can send it to support@inedo.com with an email subject of [QA-1597]. Just let us know once you have sent it and we will keep a look out.

Thanks,
Rich

Hi @Darren-Gipson_6156,

No problem! Glad it is working. ProGet 2024.6 will include a fix for this issue, PG-2695. So hopefully this won't happen again!

Thanks,
Rich

Hi @Darren-Gipson_6156 ,

I think I have finally recreated the issue. Can you please try something for me? Please configure integrated authentication following these steps:

1. On the ProGet site in IIS, enable Anonymous authentication
2. In ProGet, login as an administrator and navigate to Administration -> Manage Security and enable windows integrated authentication (do not worry about the warning about not seeing a login user).
3. On the ProGet site in IIS, disable Anonymous Authentication and enable Windows Authentication

Once you do that, does windows authentication work?

It looks like there was a change in .NET 8.0 that automatically sets the User Principal on the HTTP Context to windows authentication name. By following the steps above, I was able to configure Windows Authentication in IIS to work around this issue.

Thanks,
Rich

Hi @Darren-Gipson_6156,

Thank you for getting back to me. I got your email and this is all very helpful! I think I see where the issue is occurring. As you noted, it looks to have to do with how we are converting the integrated authentication user to a user principal in the HTTP context. I'm going to need to dig into this a little bit, but I should have an update by mid-day tomorrow (I'm in the EST timezone). I'll let you know what I find.

While I'm diving into this. Can you try restarting IIS after you enable integrated authentication and try again? I just want to rule out security caching.

Thanks,
Rich

Hi @Darren-Gipson_6156,

Thanks for all that information. I'm sorry this is taking so long to figure out, but LDAP/AD and Integrated Windows Authentication are always difficult to track down.

Just a few notes on the query process.

• The NETBIOS mappings in the UI just help to speed up the LDAP query process because it removes the need to query for the NETBIOS mapping from the domain controller. If you leave that blank, it will search for the netbios mapping in the domain directly Line 418. With that said, it will then cache that result so it doesn't have to query each time.
• The \5c you are seeing is the LDAP library we use (System.DirectoryServices on Windows and Novell.Directory.Ldap.NETSTandard on Linux) encoding the username in the LDAP query. It shouldn't be searching for domain\user in that query, so most likely there is a bug in part of that process.

Can you tell me what ProGet installation you are using (InedoHub or Docker) and which web server you are using (IIS or Integrated)?

One last thing, can you test a few things for me? This will help my pinpoint the issue further.

1. With Integrated Windows Authentication disabled, can you verify you can login with the following usernames using the Login Page:
   1. Use username@domain.com
   2. Use DOMAIN\username
2. With Integrated Windows Authentication enabled, can you navigate to http://yourprogetserver/debug/integrated-auth and send the results? If you need to distort the usernames, can you please leave format visible?

If you do not feel comfortable posting the results of the debug page, you can email them to support@inedo.com with the subject [QA-1565] Results.

Thanks,
Rich

Hi @scott-wright_8356,

Thanks for the additional information. We were able to recreate it and have a fix pending, PG-2639, that will be released this Friday in ProGet 2024.2.

Hi @proget-markus-koban_7308,

Thank you for all the extra detail. I was able to recreate this issue and fix it as part of, PG-2628. This fixed will be released this Friday in ProGet 2023.34 and 2024.1.

Thanks,
Rich

Hi @v-makkenze_6348,

As @atripp stated in your other post, this is due to bad data. For that package exact;y, it was added with a NuGet quirks version that is 4 parts (most likely specified), 17.2.65.0, which is getting handled correctly to a 3 part version due to NuGet's API specs. We are still working out how best to handle these cases.

Thanks,
Rich

Hi @arlymac_7956,

What version of ProGet did you have installed prior to upgrading to ProGet 2024 before you downgraded? I don't see any differences in the table schemas between ProGet 2023 and 2024, but I want to make sure I'm comparing to the correct schema.

Thanks,
Rich