Posts made by rhessinger

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

Hi @jw,

Yes we believe this is the same data issue. Our initial thoughts were that this only affected analysis, but it seems to be affecting the NuGet feed itself as well.

Thanks,
Rich

Hi @proget-markus-koban_7308,

I have a feeling that there was a problem connecting to the third-party Maven index. Which third-party Maven index where you trying to connect to? Also, can you try creating a blank Maven feed and then add the connector to it and see if you can pull artifacts from it? This would help to point us in a direction of where the issue may exist.

Thanks,
Rich

Hi @proget-markus-koban_7308,

This is not expected behavior. Can you please tell me which version of ProGet you are using?

Thanks,
Rich

Hi @daniel-scati ,

Thanks for catching that! I have updated the documentation.

Thanks,
Rich

Hi @sebastian,

That option can be ignored. We have decided to remove that option from the feature because it was only something that changed a UI color and had no real affect on the operation. It looks like we missed it in that UI. We will remove that in an upcoming release of ProGet.

Thanks,
Rich

Hi @sebastian,

Thanks for asking this. We will definitely explain this better in our docs prior to the launch of ProGet 2024. Basically, the concept of build stages was a way to track your project through it's build lifecycle. Since the scan needs to be performed against the source code, a build is typically added at you CI server's build stage. Then the version will be promoted between stages until it is released. During this process, there are typically multiple CI builds that are created and then rejected before going to release. ProGet's build stages give you the ability to automatically handle archiving old versions and determine at what stage an automated build analysis should create issues.

With all that said, you can customize these build stages by navigating to Reporting & SCA -> Projects and then hover over the multi-button in the upper right corner and select "Build Stages". From there, you can modify the settings for how builds are handled in each stage (scan for issues, number of active builds to keep, etc...) and create new build stages to match your CI/CD process.

ProGet includes 4 stages out of the box and they are configured to do the following by default:

• Build: Archive other builds except the latest 10.
• Integration: Archive other builds except the latest 3.
• Test: Archive other builds except the latest 3 and create issues for noncompliant packages.
• Production: Archive other builds except the latest 1 and create issues for noncompliant packages.

I hope this helps! Please let us know if you have any other questions.

Thanks,
Rich

Hi @jw,

Thanks for letting us know about these. To answer your questions:

1. This is an issue with the order of how we delete the projects and their child items. If you delete all the builds first, then the project can be deleted without issue. We will fix this as part of PG-2596 that will be released tomorrow in ProGet 2023.31.
2. This is an oversight on our part. We will get delete buttons added to the Edit Project Settings and Edit Build Settings page also as part of PG-2596.

Thanks,
Rich

Hello @jw,

We are currently in the process of testing the change to include the updated CycloneDX Specs. It is expected to be released in ProGet 2023.31.

Thanks,
Rich

Hi @andy222,

To expand on this further. If you are looking for it to just skip the stage based on that variable and proceed to the next stage, then I would also suggests @philippe-camelio_3885 method of checking in OtterScript using the $PipelinStageName. If you are looking to block going further in the pipeline and stopping at a specific step, I would suggest using the Pipeline Stage Requirements and setting a Require Variable automated check. That can block deployment to a stage unless a variable is set to a specific value.

Thanks,
Rich

Hello @daniel-scati,

Sorry for the delay in our response. We have recreated the issue and have a fix, PG-2582, ready and will be released in ProGet 2023.30.

Thanks,
Rich

Hi @forbzie22_0253,

There is no way to split out each feed to have different app pools. The only way to accomplish that is to have multiple instances of ProGet where each instance has a different feed. That would require a separate license for each instance.

Thanks,
Rich

Hi @forbzie22_0253,

Since these will be free editions of ProGet, each instance will need to have its own database. The only way to share a database would be to purchase an Enterprise edition license and configure ProGet to use High Availability.

Thanks,
Rich

Hi @PhilipWhite,

The Repository Name field is actually the name of a Docker Repository Connection, not the Repository itself. To add a Docker Repository Connection:

1. Navigate to your application -> Settings -> All Settings
2. Click "add" to the right of the Connections heading
3. Select Docker Repository
4. Select the repository type and fill in the fields (note: if this is not a ProGet Docker Registry, use Generic Docker Repository and then your registry and name will go in the Repository Name field here)

Then take that resource name and add use that in the "Repository name" field in the Docker::Buid-Image operation. Also if you only have one Docker Repository Connection, you can leave it blank and it will use the variable $DockerRepository by default, which is automatically set to your Docker Repository Connection.

Hope this helps!

Thanks,
Rich

Hi @Justinvolved,

The easiest way to setup a test environment for this would be to setup an instance of Otter (free edition is fine). Then once you have checked out https://github.com/Inedo/inedox-windows and made your changes, you can package the extension using the Inedo Extension Packager. This is available as a .NET tool. You can then navigate to the extensions page and upload the extension file to Otter. You may need to modify the AssemblyVersion in AssemblyInfo.cs to a version newer than the installed version to get it to pick it up as the lastest. Alternatively, you can copy that extension file to the Extensions.ExtensionsPath and restart Otter to have it pick up as well.

The command I typically run to package the extension is:

inedoxpack pack InedoExtension Windows.upack -o --build=Debug

I run that command from the the solution file's directory.

Hope this helps! If you have any questions, please let me know.

Thanks,
Rich

Hi @Justinvolved,

Would you be able to send us the output of Get-Module -ListAvailable on PowerShell 5.1? I would like to take a look and see if there is anything causing a parsing error in Otter. If it is not safe to post here, you can email it to support@inedo.com and prefix the subject with [QA-1405] and then comment back here when you have sent it.

Thanks,
Rich

Hi @sebastian & @caterina,

I'm sorry, I realized that after I sent the last response. I have already fixed it as part of ticket PG-2563 in ProGet 2023.28. That version is due out this Friday, but I can provide you with a pre-release version early if you want to fix this issue immediately.

Thanks,
Rich

Hi @caterina,

I think I see what the issue is here. When it comes to the package purl for npm packages, the scope needs to be URI encoded. When it goes to parse the purl for scoped packages, it reads the @ in the scope as the character indicating a version and starts then fails to parse it as an invalid URI. I'll get a fix in pgscan to handle this shortly and reply back when I have an updated version.

Thanks,
Rich

Hi @MY_9476,

We just released 2023.3 on 12/1/2023. Can you please update to 2023.3 and verify that it fixed your issue?

Thanks,
Rich

Hi @philippe-camelio_3885,

Thanks for finding this and providing a work around. I have added a ticket, BM-3915, to fix this issue. It should be released within the next couple of versions of BuildMaster.

Thanks,
Rich

Hi @paul_6112 ,

Thanks for letting us know that this is still an issue. I created a ticket, BM-3914, to track this fix.

Thanks,
Rich

Hi @paul_6112 ,

Thanks for letting us know that this is still an issue. I created a ticket, BM-3913, to track this fix.

Thanks,
Rich

Hi @v-makkenze_6348,

This fix has been released in pgscan 1.5.7. Please let us know if you have any questions!

Thanks,
Rich

Hi @philippe-camelio_3885,

Based on that script, as long as your Dockerfile is at the root of the $WorkingDirectory (From defaults to $WorkingDirectory) and the myapp.env is specified within the Dockerfile, that script should work. Can you please tell me what you are seeing while running Build-Image?

Thanks,
Rich

Hi @paul_6112,

What version of the Scripting extension do you have installed? This bug should be fixed in v2.4.0 of the Scripting extension. If it is not currently version 2.4.0, can you try updating that extension and see if that fixes the issue?

Thanks,
Rich

Hi @paul_6112,

Thanks for sending this over to us. I have resolved the issue in OT-505 and it will be released this Friday in Otter 2023.2.

Thanks,
Rich