Posts made by rhessinger

Hi @koksime-yap_5909,

The separate proxy server port is what is causing the import issue with this. After looking at this further, the main issue is that specified httpPort is overriding the port, even when an https:// URL is being used. I created a ticket, PG-3155, to fix that and add the ability to override the URL used for the Docker API. This fix will be released in ProGet 2025.15. If you are interested, I can get you a pre-release build with the fix in it either later today or tomorrow. Just let me know!

Thanks,
Rich

Hi @felfert,

Thanks for sending that. Since there are no errors right at the beginning, there was no errors in the upgrade process. Most likely restarting the container will resolve the schema issue. I have created a ticket, PG-3154, to add some more output logging in the schema update code to better understand the source of this issue going forward. Please let us know if restarting the container after updating to the 2025.14 does not resolve the schema version mismatch.

Thanks,
Rich

Hi @felfert,

The database schema is updated when the container starts. In the cases where you get a schema mismatch, typically just restarting the container will resolve the issue. This seems to happen every now and again, only in Docker, but we have been unable to reproduce it on our end to fix it. Next time you attempt to update to the new image and see this issue, could you provide us with the output from the start of your container?

Thanks,
Rich

Hi @koksime-yap_5909,

ProGet uses a combination of the Nexus REST API and the Docker API to pull images from Nexus. Just like packages, only local images will be pulled (as in only hosted Nexus Docker registries are supported). The basic process is:

1. Get a list of images using the Nexus components API.
2. Get the Docker API endpoint using the Nexus registries API (this is what you would use in the Docker client)
3. Pull the image (manifest, layers, etc...) using the Nexus Docker API

I'm guessing the error is occurring building the URL to Docker API endpoint. When you say that you are using an external proxy, did you configure the subdomain and port in Nexus to be the subdomain and port of your proxy? Would you also be able to send us the JSON that is returned for the following GET request in the Nexus API?

https://«NEXUS_HOST_AND_PORT»/service/rest/v1/repositories/docker/hosted/«NEXUS_DOCKER_REGISTRY_NAME»

If you can send me the value for the url property and the object for docker property, I can tell you what URL ProGet using to connect to the Docker API. Feel free to obfuscate the host name, subdomain (if configured), and registry name. The JSON will look something like this:

{
  "name": "internal",
  "format": "docker",
  "type": "hosted",
  "url": "http://localhost:8081/repository/docker-example",
  
...

  "docker": {
    "v1Enabled": false,
    "forceBasicAuth": true,
    "httpPort": 8082,
    "httpsPort": 8083,
    "subdomain": "docker-a",
    "pathEnabled": true
  }
}

Thanks,
Rich

Hi @lukas-herzog_4227,

Please try to restart your ProGet container. That will trigger another check for the database upgrade and should fix the issue. If restarting your container does not fix the issue, please let us know.

Thanks,
Rich

Hi @aristo_4359,

It looks like this should be possible with most of the services. I created a ticket, PG-3117, to investigate and add the feature. We will let you know if we find anything that will prevent us from implementing this.

Thanks,
Rich

Hi @aristo_4359,

Thank you for sending that over. I have recreated the issue and created PG-3116 to track the fix. We should have this resolved within the next two maintenance releases of ProGet.

Thanks,
Rich

Hi @aristo_4359,

Is this all rpm packages or just specific versions of a package? Can you share package names and version on the ones that will not delete?

@aristo_4359 said in RPM Bulk Edit Delete does not work:

Also a suggestion, when user delete package the page ideally stay on same page, instead redirecting to main feed on deleting single package and redirecting to first page when deleting using bulk edit

Thanks for the suggestion. The reason we redirect to the feed page after deleting a single package is because we don't know if the package will still exist (has other versions and/or is a remote package) in that feed. Although it is not trivial to check before we redirect, it could be added. I am going to add this to the list to discuss for ProGet 2026.

Thanks,
Rich

Hi @m-ruf_4197,

Sure thing! I have added ticket PG-3115 to track the feature. It should be released within the next couple of maintenance releases of ProGet.

Thanks,
Rich

Hi @caterina,

Good catch! We'll get that fix merged in.

Thanks,
Rich

Hi @windowsteam_8276,

Thanks for bringing this to our attention. We just pushed Otter 2025.1 that includes a fix, Ot-522, for that issue. Please upgrade to that version and let us know if that resolves the issue. Thanks!

Thanks,
Rich

Hi @inedo_1308,

I have just published a new CI build that should fix your issue. If you upgrade your Docker container to ProGet 25.0.8-ci.3, that should fix the problem with your feed usage instructions.

Thanks,
Rich

Hi @layfield_8963,

I'm having trouble recreating this error. I just stood up a clean install of ProGet 2025.7, created an asset directory, and uploaded a file to it. I then ran the command you sent and this is what I see:

pgutil.exe assets metadata set custom --path=test.txt --feed=test-import-data --key=test123 --value=12345
Setting test123 = 12345 on test.txt...
Metadata set.

Can you please navigate to Administration -> Software Info and copy and paste the contents of that here? If you feel more comfortable, you can email it to support@inedo.com with the subject [QA-2790] Database Information. If you email it, please let us know when you do so we can look for it in that mailbox. The only thing I can think of is that your database schema did not update properly on upgrade.

Thanks,
Rich

Hi @inedo_1308,

@inedo_1308 said in ProGet bug - Duplicate custom Feed Usage Instructions for Debian feeds:

Actually this feature (signed-by) is quite old. It just was badly documented for a long time (See this question) and therefore nobody used it.

Thanks for the additional details!

@inedo_1308 said in ProGet bug - Duplicate custom Feed Usage Instructions for Debian feeds:

I would appreciate that very much :-)

No problem, I'll reply back as soon I as I have a build ready.

Thanks,
Rich

Hi @layfield_8963,

Just to verify, is your instance using SQL Server or PostgreSQL? Also, can you please provide me the command you are using to recreate that issue? That will allow us to more quickly identify the issue.

Thanks,
Rich

Hi @inedo_1308,

I updated the name on that ticket. It will also cause other issues with other feed types as well. It is an issue with how it creates usage instructions that have the same name as other usage instructions (both built-in and custom). As part of that ticket, we will handle fixing the editing and deleting of instructions that were created incorrectly. The display issue will most likely need to be fixed by manually deleting the duplicates and recreating them (post fix).

I will also fix the Debian usage instructions as well. Since I'll be touching the code where the built-in instruction is stored, I was planning to just include them in that ticket, but I can create a new ticket for that as well. When we wrote our documentation for Debian, signed-by was not a feature yet. In the latest updates for the updated Debian feed, most customers were still using the legacy way for adding ProGet as a source. It has really only been in this latest major of apt that signed-by has worked consistently for us.

I plan to work on these early this week. If you want, I can provide you with a CI release as soon as these are ready if you want to test them early.

Thanks,
Rich

Hi @inedo_1308,

Thanks for sending this over to us. I created a ticket, PG-3069, to fix the exception with editing. I'll also get the feed usage instruction and our documentation updated with the signed by parameter.

Thanks,
Rich

Hi @jfullmer_7346,

Thanks for sending this over to us. This looks to be related to an issue with a stored procedure only used by this specific Asset metadata API. I have fixed this as part of PG-3062 and it will release this Friday in ProGet 2025.6.

Thanks,
Rich

Hi @caterina,

That looks to be an issue with the UI. Your feed policy will only ovewrite the specific license you marked as compliant and the remaining non-compliant licenses will still mark packages with those licenses as non-compliant. For example, any package AGPL-1.0 will still be non-compliant. On the second feed, it should be using the Global policy for that package. Can you share which feed features are enabled under the Feed Properties tab (Manage Feed in ProGet 2024) on the feed you promoted the package to?

Thanks,
Rich

Hi @kc_2466,

I just wanted to clarify Dan's comment a bit. The tz environment variable sets the timezone used in the container and time zone in the user config will only set the time zone to use in the UI, not the format of the date. Setting LC_TIME will change the locale within the Docker container and format it at the OS level, it doesn't look like that will be picked up in the .NET side of things. This is something I will need to discuss with the team internally. We have a team meeting on Monday (EST) of next week and I should have an update for you on the following Tuesday.

Thanks,
Rich

Hi @mhelp_5176,

When hosting via the Integrated Web Server, you will need to update the account the service is running as. As long as the GMSA is a db_owner on your database, then "Integrated Security=true;" in your connection string will use that account. As for installs through the InedoHub with "Integrated Security=true;" , it will use the account of the person running InedoHub when connecting to SQL Server during the install, so that account will need DBO on the ProGet database as well.

Thanks,
Rich

Hi @mwatt_5816,

Thanks for all of the detail. I have fixed the code, BM-3982, for this template and it will be released in the next maintenance of BuildMaster 2024.0.7 on Friday.

Thanks,
Rich

Hi @jfullmer_7346,

Thanks for the detailed recreation steps on this! I was able to recreate the issue and created a ticket, PG-3018, to track the fix. This is expected to be fixed in ProGet 2025.2 on Friday of this week.

Thanks,
Rich

Hi @petter-jacobsen_7171,

Just an update. It looks like I have found some issues with our policies. I have created tickets PG-3015 and PG-3016 to track the fix. These are expected to be released in ProGet 2025.2 at the end of the week.

Thanks,
Rich

Hi @stefan-hakansson_8938,

In ProGet 2024, we added support to enable enhanced database mode, which requires database owner, as an opt-in feature to prepare for ProGet 2025. Beginning in ProGet 2025, ProGet requires database owner on the ProGet database in SQL Server. Once you add DBO to your SQL user, this will unblock the upgrade to ProGet 2025. You can see more information in you [SQL Server & Inedo Products](In ProGet 2024, we added support to enable enhanced database mode
) documentation.

Thanks,
Rich

Hi @lukas-christel_6718,

Sorry for the delay on this. We just pushed an updated pgutil that will now skip over any invalid versions.

Thanks,
Rich

Hi @petter-jacobsen_7171,

I took a look through these and I have some more answers for you:

1. Looks like you added the package string to the license. You will need to navigate to Reporting & SCA -> Licenses -> manager license types & rules, then find that license, edit it, and remove the package string under the PUrls tab.

2. This looks to have been fixed in ProGet 2025.1 that released last night.

3. You can block a specific package on the Set Package Status page.

4. There does look to be an issue in policies, but I will need to dig into this further to determine exactly what the issue is. I will be looking into this more tomorrow.

5. I was unable to recreate this issue. It may have been fixed in 2025.1 or it may have been related to something else. Please note that if the package is in a connector, then the package will show in your feed once you delete it as a remote package.

6. This may be related to the issue in 4, I will update on this once i have dug in further.

7. Again, this looks to be related to an issue in policies.

8. I addressed this in my previous comment, but just wanted to call it out for completeness sake.

I should have an update tomorrow for you with more specifics around the blocking issues. Please let me know if you have any questions regarding my responses!

Thanks,
Rich

Hi @rel_0477,

I just happen to check right when this came in. Glad to hear it is working again! Was it the local cache? Cargo has a pretty aggressive cache for both good and bad packages.

Thanks,
Rich

Hi @rel_0477,

I apologize for not responding sooner. Can you please navigate to Manage Feed -> Storage & Retention and run the re-index operation? That should fix any packages that were pushed with the invalid JSON header.

Thanks,
Rich

Hi @darren-sloper_5044,

Great! Glad to hear you are up and running again!

Thanks,
Rich

Hi @petter-jacobsen_7171,

Thanks for submitting all this detail. I just wanted to let you know we are currently reviewing these items and will have an update later today.

I did want to make not that rollback is only supported when you upgrade from 2024 to 2025, then you will be able to downgrade back to 2024. With that said, that connector error may go away by simply restarting the ProGet services. If not, you can also try to uninstall 2024 and then reinstall it again and point to the existing database. That will force the schema update to rerun and should add back that missing stored proceedure.

Hi @kc_2466,

I'm having trouble recreating this issue. Are you using the built-in/unmodified publish packages task or did you create a custom one? If you created a custom one, please make sure all that all your options can be scoped to a feed (denoted by the "F").

Thanks,
Rich

Hi Darren,

We pushed a new installer last night and you should be able to use that to upgrade now.

Thanks,
Rich

Hi @darren-sloper_5044,

Thanks for all of the information! Installer issues take a bit to debug through, but we are looking into this now. Please hang tight and should have an update later today or early tomorrow morning on this.

Thanks,
Rich

Hi @matthias-reitinger_3646,

Good catch and thanks for sending over an example! I took a quick look and you are correct that bin was not included in the metadata for that package. I have created a ticket, PG-3000, to track the fix for this. Unfortunately it is too late to get this fixed in today's ProGet release, but it should be fixed in the next maintenance release of ProGet, 2024.39, which is expected in two weeks.

Thanks,
Rich

Hi @rel_0477,

Thanks for sending over the reproduction case. I was able to identify the issue, PG-2993, and have it ready to go in the next maintenance release of ProGet.

Thanks,
Rich

Hi @caterina,

Thanks for bringing this to our attention. I have created a ticket, PG-2990, to track the fix and it should be released in the next maintenance release on June 13th.

Thanks,
Rich

Hi @steviecoaster,

Thanks for the find. We'll get this fixed in the next maintenance release.

Thanks,
Rich

Hi @michal-roszak_0767,

Can you please post what the fix was?

Thanks,
Rich

Hi @michal-roszak_0767,

I took a look at the code and the only line that could throw that error during the configuration is when it goes to download the federation metadata. Typically that error message indicates the ProGet server was shutting down will it was attempting to create a new HttpClient. I would try to reboot your ProGet server and see if it happens again.

Thanks,
Rich

Hi @Nils-Nilsson,

Glad to hear it's working for you! Also, thanks for the feedback on adding that to our docs, I'll work on getting that added soon.

Thanks,
Rich

Hi @udi-moshe_0021,

If you could please share all of the output, that would be helpful.

Thanks,
Rich

Hi @Nils-Nilsson,

At this point, I would suggest using our debug endpoint to see what the SAML response sent to us is and how we interpret it. You can do that by change the callback URL in your SAML provider to https://«PROGET_HOST»/saml-acs-callback-debug then attempt to login to ProGet using your SAML provider. You will then be redirected to a debug page that shows you the SAML details. That should be able to help you identify what is missing. If you need help, you can email us the contents of that page to support@inedo.com with a subject of [QA-2681] SAML and then reply to this letting us know you sent it.

Thanks,
Rich

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