Posts made by stevedennis

@steviecoaster the main headaches come when you try to use a kind of CDN (Front Door) or anything else that will cache/manipulate/munge requests; it's often slower anyways so there's no real benefit

I know a few customers were hit with some kind of bug in Gateway that caused problems in clients (Docker particularly) - it was a long standing, multi-year bug in Gateway, so who knows if it ever got fixed

Hi @yaakov-smith_7984 ,

I'm afraid I'm not really sure what's happening; it's clear that they're doing something "pretty weird" behind the scenes, and the integration is designed to use Active Directory, not this system.

You can see the queries that ProGet is making -- and if those queries don't return those "weird" groups like $JQA200-TQZJ4H3I77X8, then it's not going to work.

Hopefully the system will work with LDAP queries. If you use the OpenLDAP/Generic directory, you can customize the property names and queries to hopefully get it working: https://docs.inedo.com/docs/installation/security-ldap-active-directory/various-ldap-openldap

Let us know what you find out,

Thanks,
Steve

@james-woods_8996 good to know - I've just removed that from the docs since I think that was an instruction from earlier versions (before ProGet 2022 maybe)

Hi @james-woods_8996 ,

Setting the ASPNETCORE_URLS is the correct way to address this; that troubleshooting guide is outdated (though it probably still works to write out the config file like that).

As far as I understand, this behavior has not changed in ProGet 2025 and has been the default behavior since ProGet 2022. We had considered changing the Linux ports to be 8624/8625 to mirror Windows defaults, but decided to just update the documentation to clarify.

Thanks,
Steve

Hi @jw ,

You can ignore the message. There is no relation to a package; someone just happens to have that URL open in the browser, and the page is using AJAX to request updates to display the "alert bar" at the top. Eventually they'll close it and the error will go away.

Thanks,
Steve

Hi @jw,

That URL is for updating the notification bar -- typically you'll see this when someone has a browser Window open with the old version of ProGet that is attempting to load notifications from a URL that no longer exists.

Thanks,
Steve

Hi @koksime-yap_5909 ,

This is the "Feed Overview" page and the URL that you need:

Thanks,
Steve

@kc_2466 thanks for the suggestions, we'll also get this in a future maintenance release via PG-3067 ... should be trivial!

Hi @kc_2466 ,

Thanks! We'll add this via PG-3066 in an upcoming maintenance release, hopefully later this week if it's as trivial as it seems :)

Thanks,
Steve

Hi @parthu-reddy ,

There's nothing in ProGet that would cause a file name ending with a .spd fail. Just to double check that it's not related to the file name, I would rename it and see if it works.

The main thing that's jumping out to me is that there are large files (3.1GB). Those are uploaded using a chunked process, orchestrated by the browser. I would keep "playing" with this and see if you can identify any patterns.

The message from your firewall team is saying that they are seeing RST messages from the client and server. That's unusual, and means the connection is forcibly closed. ProGet does not operate at the network level and there is nothing that can cause ProGet to issue an RST command, which means it's most certainly network related.

I think you're on the right track with investigating at the network side -- but unfortunately you're going to have to find out what is issuing a RST. The firewall might not, but maybe there are other network devices that are?

Maybe something is "taking too long" and getting RST.

Thanks,
Steve

Hi @alex_6102 ,

Can you help us understand why one would want to use custom signing keys?

When a Debian repository (i.e. ProGet) is configured over HTTPS, signing the InRelease index is totally redundant and pointless. Moreover, from a security standpoint, these signing keys are cryptographically inferior to HTTPS.

The only reason to use signed indexes is so that apt doesn't issue a warning. They serve no other purpose in an HTTPS ecosystem.

On our end, it's a nontrivial effort so it seems like a waste of limited resources.

Thanks,
Steve

Hi @fabrizio-mancin_3822 ,

If you just download a new version of InedoHub from https://my.inedo.com/ this will work - for whatever reason, the self-updating function of Inedo Hub must not have worked for you.

Thanks,
Steve

Hi @koksime-yap_5909 ,

This is a known issue and will be fixed via PG-3063 in teh next maintenance release, shipping later today.

Thanks,
Steve

Hi @koksime-yap_5909 ,

That's just a "suggestion box" in the UI - you can just type in whatever you'd like. But in general you shouldn't upload files via the UI, but using maven.

Thanks,
Steve

Hi @koksime-yap_5909,

Please What is a "Connector" in ProGet? to learn more about how to accomplish this in ProGet.

Since Artifactory and Nexus are basically the same thing, here is some more context on comparing the "mental model" between those products and ProGet
https://blog.inedo.com/proget-migration/how-to-manage-repositories-in-proget-for-artifactory-users/

Thanks,
Steve

Hi @koksime-yap_5909,

No; when you use LDAP, then you need to manage the LDAP users' groups in your directory. Here is a recent discussion on the topic:
https://forums.inedo.com/topic/5471/feature-suggestion-allow-ad-users-to-be-added-to-built-in-groups

Thanks,
Steve

Hi @patrick-tessier_4584 FYI,

dotnet nuget and nuget.exe are effectively the same thing - they both invoke the NuGet CL.. The nuget.exe is a standalone version of the CLI and dotnet nuget is part of the .NET SDK.

The issue is that your copy of nuget.exe was ancient and didn't work.

Cheers,
Steve

@patrick-tessier_4584 thanks for letting us know!

NuGet 2.8.3 was released October 17, 2014, which I believe predates ProGet. It probably uploads things in quirky way that we haven't tested in very many years.

In any case, it sounds like it's working now and the issue was the ancient version of nuget.exe

@jfullmer_7346 this is a bit tricky behind the scenes but hopefully will be resolved with PG-3047 -- which we hope to get in the next or following maintenance release

Hi @patrick-tessier_4584,

The underlying error is network-related; perhaps the traffic is being interfered with, the client is prematurely disconnecting, etc. There are no settings in ProGet nor issues with your ProGet configuration.

Unfortunately that's a bit challenging to troubleshoot, but I suggest you start with a tool like Fiddler Classic or ProxyMan, and see what reuqests are being sent to ProGet.

Then try to reproduce using only curl (not the client tool). Then bypass network equipment / proxies / etc., running the request entirely on the PRoGet server/container if you have to.

Hope that points in the right direction; please share what you find.

Thanks,
STeve

Hi @kc_2466 ,

Thanks for the report; we'll get this fixed in the next maintenance release (this week) via PG-3064

Thanks,
Steve

Hi @misael-esperanzate_5668 ,

That makes perfect sense; when package caching is enabled, the package files are added to the feed and stored on disk. When it's not enabled, they are simply streamed from the server.

Something is interfering with your disk storage that is deleting (quarantining) files on disk. You will need to follow the troubleshooting I identified above - it's probably a security tool.

Suggest using AWS Lightsail to get a test box in an environment you can control.

Thanks,
Steve

Hi Marc,

I'm not sure what you mean by 2024.8-r1 but the -ci.x and -rc.x images are prerelease versions. Sometimes they are the same as the release versions, sometimes they aren't.

I wouldn't use prerelease versions unless we suggest them to you for a specific issue you're facing.

-- Dean

Hi @v-makkenze_6348 ,

You can use a ProGet Trial Key or if this is just a quick temporary instance, just use your existing license key to try it out.

Thanks,
Steve

Thanks @imm0rtalsupp0rt, this is exactly what I was looking for -- I'd like to be clear what's wrong though.

You're saying the $.data[].versions[] array only contains the latest version, and not all the versions?

Hi @carsten_1879 , just to give another update.

The issue appears to be localized to your ADO Server, perhaps it's the version or locale. The authentication header doesn't seem to make any difference.

Whatever the case is, the library we use, libgit2, simply cannot clone from it -- for whatever reason your ADOS is returning a 400 with some German error message when doing what should be a totally fine request. We did not test with git.exe.

Our new, proprietary library also does not work, but for a different reason - it looks like ADOS is using an ancient format (like from 2010??) for one of the reposes, so we don't support that yet. At least we think.

We'll need too spend a bit more time researching this, so it'll get pushed into the following weeks.

Thanks,
Steve

@steviecoaster @imm0rtalsupp0rt in the screenshot above it's not clear what API is being used, what queries are being made, and what's expected -- if you could provide us with that, we could troubleshoot this very quickly

@stefan-hakansson_8938 as you noticed, ProGet's Debian connectors are not currently designed to handle the gigantic, operating-system mirrors very well. This is because they are always refreshed "on demand" - which is what you want for CI/CD workflows.

It's not great for public repository mirroring, however. In Q4 or later, we will explore adding an option to do periodic updates.

@v-makkenze_6348 thanks, unfortunately I wasn't able to reproduce it

Can you try a manual import by going to Reporting & SCA > Projects & Builds > Import SBOM > paste in your SBOM?

If that gives an error, can you also try to edit application name/version in the XML before pasting? Fox example, change it to:

    <component type="application">
      <name>MyTestProject</name>
      <version>25.3.85.1</version>
    </component>

That will create it as a new project/build.

Just trying to figure where the issue might be.

Thanks,
Steve

@carsten_1879 thanks for the update

We were able to reproduce this using your credentials, and It's definitely an "error reporting an error" on Linux. On Windows it's clearer ("too many redirects or authentication replays").

We do not test on ADO Server, but we quite a few customers users with it - who knows why it works for them but not you. Anyway, please bear with us as we figure it out.

Hi @imm0rtalsupp0rt ,

We don't know choco search is doing behind the scenes with regards to API calls, but I think it's using the V2 ODATA API. That gets pretty complex and we don't have enough information to work on yet - and trying to set up a reproduction case is quite the endeavor.

Could you provide a very basic reproduction, perhaps with a dummy package or two, using only the API calls? If you use something like Fiddler you can see the underlying API calls

Thanks,
Steve

@erich_1530 in the ProGet software, you will see a "License REquired" error message. if you click on the "Request License Key" you can get a Free or Trial key from within ProGet. Or you can go to my.inedo.com and request a key from there if your server does not have internet access

@carsten_1879 excellent, thanks! Please give us a little time to review this.

We will also test it with the new Git library, which is available in buildmaster:24.0.8-ci.9 container image -- you have to go to Admin > Advanced Settings and enable it.

If you get a chance to try it yourself, please let us know. We are currently testing it ourselves on our main server.

Hi @james-woods_8996 ,

No problem using ProGet 2025 Docker Image with SQL Server - it works exactly as it did in ProGet 2024.

We will continue to support SQL Server in the through at least ProGet 2026.

Thanks,
Steve

@phopkins_6694 perfect, just what I was looking for

I was able to reproduce this - searches via the NuGet API (which connectors use) will consider tags, while local searches seem to only be looking at names.

I'm not sure how long this has been the case, but we'll try to get it fixed soon. Unfortunately it's not a trivial fix, hopefully we'll do it via PG-3046, likely in the July 18 maintenance release.

Thanks,
Steve

Hi @erich_1530,

Nice idea for the docs, I just updated.

It looks like the software was successfully installed.

What does the "Services" tab show? There will be a "Logs" tab that should provide you with the logs.

I would try to uninstall and then reinstall using the Inedo Hub. Also reboot just to see if that works.

Thanks,
Steve

Hi @caterina ,

Multiple policies will "stack" and are evaluated in order from Global > Shared > Feed. It can get pretty tricky, so I would use the "Re-analyze" feature on a package - this will print out some detailed analysis logs that show you exactly what rules are being followed.

The "Policies and Blocking" view under the Manage Feed pages will try to combine these a single view, but you may find that using Admin > Policies is helpful... it only shows one policy at a time, and does not combine them.

To add to the complexity, compliance results are cached on the "list packages view" -- so that's why it's important to do that renalyze function to make sure you're looking at the right results.

The caching doesn't last long (few minutes), but it makes debugging a challenge/

Thanks,
Steve

Hi @carsten_1879 ,

Huh weird... so GitHub works, but your ADO Server doesn't. I bet it's related to some kind of TLS or something?? We may be able to see it with Wireshark or something.

Anyway if you can give provide us with credentials that would be great. We can then test on our new GitLibrary and see if it works.... maybe the solution is just to get you that instead.

Just email the info to support at inedo dot com, and include [QA-2678] in the subject line. But let us know when you send it, because we don't monitor that box.

Thanks,
Steve

Hi @erich_1530 ,

I'm not really familiar with how installation issues are reported with Chocolatey, but if you don't see a INEDOPROGETSVC service, then I think there was some kind of installation issue.

I would start by using the Inedo Hub instead of silent/automated installation. Once successfully installed, there will be a "Launch" button - it just loads https://localhost:8624, which is the default port for ProGet. Once you do that, the software will walk you through configuring HTTPS, which you can do later.

You may or may not be able to access the software by going to http://your-server-name:8624 due to firewall or network restrictions. But that's handled outside of ProGet.

Best,
Steve

@v-makkenze_6348 can you email it to support at inedo dot com with [QA-2775] in the subject, and let us know when you sent it? We can find it then

Thanks

Hi @carsten_1879,

The mystery continues.

The strange thing here is when adding a new connection to azure devops and entering the instance url, username and personal access token, i am able to browse the projects and repositories in the buildmaster setup dialog.

Behind the scenes, the project/repository browsing are handled using the ADO API, which is called from .NET code, which eventually uses the openssl library installed on the operating system. Clearly, this is working... and I think your credentials, etc. are fine.

HOWEVER, the cloning is handled using a totally different library called libgit2. It uses libssl behind the scenes, and clearly this is not working.

Unfortunately, libgit2/libssl are a lot less forgiving with SSL issues than .NET and a lot more cryptic. So it's possible that the "could not open libssl" isn't even the actual error message.

The real mystery here is why is this not working for you but it works fine for us? Especially since we're both using the same container image?

One guess I have at this time is a proxy server is "reencoding" the SSL stream using an algorithm libssl doesn't understand? And then, this error is thrown? Or, perhaps it's a locale thing? Just some wild guesses.

Could you try this with like, GitHub perhaps? Or maybe you could try this on a public server that we could access, like a Amazon LightSail server?

FYI - on our end, we have written our own Git library from scratch using .NET that will not have these problems. It's almost ready.

Thanks,
Steve

Hi @phopkins_6694 ,

Probably not - the search in Chocolatey and ProGet UI will be different, and that's not something reasonably addressable. So let's start the issues you're having with ProGet UI search.

Thanks,
Steve

Hi @phopkins_6694,

I'm afraid not; the Chocolatey client and ProGet UI perform different search functions so there's not much we do with that information.

If you can provide a very specific reproduction case, we can investigate:

1. Create a new Feed
2. Upload a package
3. Search the package in the ProGet UI

If you share the nuspec of the package you uploaded and your search terms, we can try to reproduce the case and see if we can reproduce. Then we can explain or fix the behavior.

Thanks,
Steve

Hi @v-makkenze_6348 ,

The SCA Import "Nullable object must have a value" is likely coming from data in your SBOM XML. It's likely unrelated to Postgres, and more related to the library upgrades. Can you share with us the SBOM document you are uploading?

The Connect errors are unrelated to your switch. Based on the stack trace, it looks like you have a no-longer-supported setting called auding proxying enabled, and npmjs.org is timing out while making that request. You should disable that by navigating to the npm feed's "Manage Feed" page and configuring npm audit setting to Enabled or Disabled.

Thanks,
Steve

Hi @phopkins_6694,

If you've upgraded, then the tags should now be displayed on the Metadata tab of the package.

When doing a search in the ProGet UI for NuGet (and Choco/PowerShell) packages, the Name, Description, and Tags are considered. However, the ordering may not be what you expect, especially if your tags are common words common in many names/descriptions.

Thanks,
Steve

Hi @carsten_1879,

The underlying error message ("could not open libssl") is related to your specific environment; it's an error occurring at the operating-system level where it's failing to load a dependency that is already installed (in Docker/Linux version).

We made a change in BuildMaster 2024.06 that may have had an impact, but since you tried 2024.05 we can rule that change out.

So at this point, we need to try to figure out why it isn't working for other users (including us during testing).

Can you tell us a bit about your environment? Like the host? K8 vs Docker? Do you have any special security software running?

Thanks,
Steve

@stefan-hakansson_8938 thanks for confirming, I see what's happening

Debian feeds do not use metadata caching (they have a local index file instead), so it's not settable and is always displayed as "disabled" in the ProGet UI. If you were to go to the connector page, you won't be able to set it. HOWEVER, it's settable using the API.

Hi @stefan-hakansson_8938 ,

I cannot reproduce this in ProGet 2025 - the value is set and displayed correctly, as expected.

Both the UI and API use the same code to retreive/load information from the database, and there is no data caching here, so I'm thinking there might be some other issue (looking at wrong instance, looking at wrong connector, etc).

Thanks,
Steve

Hi @stefan-hakansson_8938,

There's no point in verifying a fingerprint (i.e. hash) for content from a trusted HTTPS source. In the olden days (before "SSL Everywhere" with unreliable downloads and questionable mirrors), it was an important way to validate integrity... but there's no sense to it today.

If one were to "compromise" a trusted HTTPS source and tamper with content (signing keys, packages, etc), then they could just as easily tamper with hashes provided by the source. So you can simply just accept whatever key ProGet provides you -- no need to "think twice" about it.

Hashes can help with troubleshooting corrupted files... but with network speeds so fast, you can just redownload it when file sizes don't match.

Hope that helps,
Steve

@michal-roszak_0767 I think this is a similar question to your post in another thread, so I'll just quote my response from there:

@stevedennis said in services.gradle.org proxy:

Hi @michal-roszak_0767 ,

That looks like it's just a "web page" with a bunch of links to files?

ProGet does not support connecting to "web pages" and we have no plans to add that feature. There's simply no API to use, which users could never be able to "see" the files in ProGet until after they've been downloaded -- and the lack of metadata also creates all sorts of other complexities.

However, you can create an asset directory to store "generic" files. It's basically a web-based file system: https://docs.inedo.com/docs/proget/asset-directories-file-storage/what-is-an-asset-directory

Thanks,
Steve

I think that @dan-brown_0128 is on the right track - if you can parse the "web page" and know what links reference files you want, then you could then follow those links, download the files, and upload those files to an asset directory

Not sure if you're able to share the script @dan-brown_0128 but if not, it'd probably be "relatively easy" to get ChatGPT to hep with or something