Posts made by stevedennis

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

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

@mmaharjan_0067 we'll see how we can improve this while we work on PG-3034

@mmaharjan_0067 thanks for sharing that

I misunderstood the remove command -- I didn't realize that was deleting from the feed, and just assumed it was removing from the local project or something.

I don't see any code for DELETE in the feed, so we would have to add that. No idea how easy that is going to be, but we'll try doing it at same time with the UI improvements. You can track via PG-3035.

Thanks,
steve

Hi @mmaharjan_0067 ,

This is definitely some kind of UI regression; we did a lot of code-cleanup / refactoring on the front-end pages. We'll get this fixed via PG-3034 in an upcoming maintenance release (targeting next week's 2025.4).

Thanks,
Steve

@p-pelinski_1371 @pbe_9047 thanks for confirming that!

We will get this fixed via PG-3031 in the next maintenance release. You are also welcome to try the proget:25.0.3-ci.3 container image, which is building now.

Hi @mmaharjan_0067,

I think we can call this a "known limitation" now that you've discovered it ;)

It's a bit tricky to set up a conan debug/testing environment, so to advance this further instead of putting off another few days.... do you mind trying to run the command with --verbose and share the output? How about without the -p command?

I'm just trying to see what URLs the conan client is trying to call, and make a guess for how we can address it.

Thanks,
Steve

Hi @stefan-hakansson_8938 ,

SSL/HTTPS is all handled at the operating-system level.

When there are SSL/HTTPS issues then you will see some kind of OS-level error in ProGet. You can see what these are like by connecting to one of the "bad" options at https://badssl.com/ - the connection will be refused.

Thanks,
Steve

Hi @pbe_9047 ,

Can you share what you see on Admin > Database Overview page?

Also Admin > System Inforamtion?

Thanks,
STeve

Hi @stefan-hakansson_8938,

ProGet relies on SSL/HTTPS, so instead of connecting to http://archive.ubuntu.com/ubuntu/ you should use https://archive.ubuntu.com/ubuntu/

I just updated the docs you found to use https instead of http - thanks for pointing that out.

Thanks,
Steve

That's the intended/expected behavior of repackage. The use case is CI/CD workflows, so you would do something like:

1. Create w.x.y-ci.z
2. Repackage to w.x.y-rc.z
3. Repackage to w.x.y

Retention policies would then clear out old -ci and -rc packages.

I believe that display bug has been fixed in ProGet 2025; I remember seeing it listed as a bug discovered during testing. But in any case, it's in the package history as you can see.

Hi @mmaharjan_0067,

I can't easily create and populate a Conan feed.... but if I remember correctly, I think that everything is stored as blob files? Like hashes for names, with nothing useful?

Do you see anything under the package store (i.e. on disk) that might be useful to display?

Thanks,
Steve

Hi @kc_2466,

Prerelease segments are sorted numerically, so 1.0.0-ci.10 > 1.0.0-ci.2 as you would expect.

If most builds are never released to production (a common CI/CD scenario), this is a great approach.

Thanks,
Steve

Hi @mmaharjan_0067,

Can you clarify this one a bit? I'm not picturing what you're requesting and I'm also not sure if there's much we can show.

I do know that Conon feeds are a bit limited due to the limitations of the Conan Server API / protocol. If you see other feed types / products handle this differently, let us know.

Thanks,
Steve

Hi @mmaharjan_0067,

This is not a trivial request and would require database changes, new API endpoints, and of course pgutil changes. We will put it on our ProGet 2026 roadmap for future consideration -- hopefully some other users will chime in!

Thanks,
Steve

Hi @kc_2466,

SemVer build numbers are really weird -- they are not intended to make a version unique. In other words, 3.4.1+1 and 3.4.1+2 are considered equal, and thus overwrite them.

As for 4-part numbers, that is most definitely a validation bug - Universal Packages use SemVer, and 4-part versions are invalid. Now that we know about it, we will likely fix it - so don't use it.

I'm not totally sure what you're trying to accomplish, but the best CI/CD workflow for builds and releases is to use prerelease/repackaging:
https://docs.inedo.com/docs/proget/packages/repackaging

If, for whatever reason, your package needs a version number that SemVer does not support, you can do something like yz = y*100000 + z*100. For example, 4.2.1.5 becomes 4.2.100500

Thanks,
Steve

Hi @misael-esperanzate_5668 ,

I'm afraid we simply can't reproduce this. Here is what we do:

1. New Maven feed w/ Maven Central Connection
2. Download Index
3. Navigate to /feeds/marvin/org.hamcrest/hamcrest-core/1.3

All files will show up in the list because the index file is downloaded; if the index file was not downloaded, only the pom file will show. But the behavior is the same either way.

The artifacts download with no issue, as expected:

curl http://localhost:8624/maven2/marvin/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar

curl http://localhost:8624/maven2/marvin/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.pom

They download in any order just fine, and I can delete them from the ProGet UI. There is no case that we can have a "file vanish" as is happening to you.

The 404 error you keep getting is expected if there is a cached entry without a file. There is really no other way we can imagine to get that error. It's very common on Windows for files to "suddenly vanish" when you have anti-virus tools running --- a .jar files suddenly being written to disk will often trigger a quarantine action.

ProGet obviously cannot detect nor prevent this interference. You may be able to use a tool called ProcMon to monitor for interference: https://learn.microsoft.com/en-us/sysinternals/downloads/procmon

Otherwise, you may wish to just set up a AWS Lightsail sandbox, which can be done for pennies: https://docs.inedo.com/docs/proget/installation/proget-how-to-install-on-aws-lightsail

That will allow you to compare/contrast behavior.

Thanks,
Steve

Hi @michal-roszak_0767 ,

You can just click "edit" on an API Key in the UI to change the date or secret value.

However, if you have "Cryptographic hashing" enabled, then you will need to delete the key and recreate it to change the value.

Thanks,
Steve

Hi @phopkins_6694 ,

The "missing tags" is a regression from ProGet 2024.28 (PG-2911); it is a UI display issue and it's already been fixed in ProGet 2025.

Not sure about download counts, but there were some display changes in ProGet 2022 as well -- I think what you're seeing is the difference between "total downloads for all versions of the package" versus "downloads for this version".

Thanks,
Steve

Hi @mhelp_5176 ,

When upgrading ProGet 2024 and earlier via the Inedo Hub, the user performing the upgrade must have db_owner permission. So, this behavior is expected if <Domain>\MyLoggedInUser doesn't have access.

I'm not sure if you can log in to Windows using a gMSA or not. But, the easiest move is just to give <Domain>\MyLoggedInUser the appropriate access, or just switch to username/password authentication.

In ProGet 2025 and later, the ProGet application itself performs the upgrade, so that user account would need db_owner permission.

Thanks,
Steve

Hi @parthu-reddy ,

These indicate that your network stack is being overloaded. npm can do this, as it's sending thousands of simultaneous requests to your server. Each of these requests require multiple database connections (network) and requests to remote registries (network).

If you're using load balancing, you'll want to tweak the configuration to do rate limiting. For example, in npm it's this: https://blog.nginx.org/blog/rate-limiting-nginx

Hope that helps,
Steve

Hi @m-karing_2439,

It looks like this is a network-related issue: "Cannot determine the frame size or a corrupted frame was received."

There are no changes in ProGet 2025 that would cause something like this, but it's possible that a firewall or something else is interfering with the communication. The executable name changed from ProGet.Service.exe to proget.exe, and we've seen some "anti-virus" tools require a new execption be made.

No idea why it would work for PyPi, however. Hope that at least points in the right direction.

Thanks,
Steve

Hi @kc_2466 ,

The message "Feed-scoped Privileges are not available in ProGet Free Edition. You can still add them, but they will apply to all feeds." should be displayed when you add a privilege, but it's probably easy to miss. I'm not sure if we show it after that.

As for Personal API Keys, you can create them as an admin, but non-admin users can't create their own. It's a different page.

Cheers,
Steve

Hi @kc_2466,

I see - so they are "self-connectors", and ProGet is effectively connecting to itself. In that case, then the ProGet server is not "trusting" your in-house certificates.

You'll need tot add a self-signed CA to Docker configuration. See the self-signed-ca option:
https://docs.inedo.com/docs/installation/linux/docker-guide

Cheers,
Steve

Hi @kc_2466 ,

This error means that the ProoGet server itself cannot make a secure / SSL connection to the URLs you've configured.

We know that npmjs.org has a valid certificate, so this means that "something" on the server or in your network is interfering with outbound traffic. This is typically a content filter, proxy, or something to that effect.

You would get the same results of if you were to curl those URLs while logged in to the ProGet server, running under the same user that ProGet is running as.

Thanks,
Steve

Hi @kc_2466,

Feed-level security is not available in ProGet Free edition:
https://docs.inedo.com/docs/proget/administration/license#security-restrictions

You can configure it, but as the UI should warn, it is not enforced.

You can request a free trial license for a paid version of ProGet from https://my.inedo.com/

Thanks,
Steve

Hi @parthu-reddy ,

First, please note that IIS is no longer recommended for ProGet 2024 and it is not supported in ProGet 2025: https://docs.inedo.com/docs/installation/windows/web#iis

As for request limits, there are none. And it's not really a question that we can answer - a request can be anything from serving a cached image to doing a query with "chained connectors" that has to do a lot of network activity. It really depends on the types of feeds, configuration, etc.

But a good "rule of thumb" is that 50-100 simultaneous connections will start to strain a server, and 10x that very likely be difficult to use.

Hope that helps,
Steve

Hi @michal-roszak_0767 ,

I'm afraid Feed Groups are not currently supported in the Feed Management API or pgutil feeds commands. We are considering rewriting/refactoring the API later this year, so I've added this to the notes to consider for that.

Thanks,
Steve

Hi @steviecoaster ,

You can use pgutil for this:
pgutil settings set --name=Licensing.Key --value=XXXXXX

This is in the Configuration table FYI, which is what pgutil settings does

Thanks,
Steve

Hi @ds_6782 ,

If you haven't already ,I would make sure to check out the docs here:
https://docs.inedo.com/docs/proget/feeds/nuget/symbol-and-source-server

The NuGet client will automatically push both packages when you issue the dotnet nuget push command. You do not need to push then separately.

It looks like, for whatever reason ,your NuGet client isn't doing that? We don't see this problem very often - it "just works" - and I'm not really an expert at troubleshooting NuGet client configuration.

But that's where I would start. It looks like the issue is on the client end, and somehow your clientis misconfigured to not push the source packages.

Thanks,
Steve

Hi @ds_6782 ,

nuget search uses the v2 API, so this behavior is to be expected.

Thanks,
Steve

Hi @parthu-reddy ,

The default Timeout is 10 seconds, but you can configure it on each connector.

There is no "connection pool" for NuGet -- these are just normal HTTP connections like your browser or any other web api.

Thanks,
Steve

Hi @stefan-hakansson_8938 ,

Thanks for the additional information; so if I'm reading it correctly, it's basically a different format/style of index files?

So far as I can tell, it's been around for quite a while (2016?), but doesn't seem to be widely used or mandatory? I didn't look too deeply.

In any case, supporting one style of Debian index files is already a challenge, since we are reimplementing everything from scratch (and not using their tools). As with many package formats, the "real specs" differ a bit from the docs and can only be discovered by studying the source code and/or behavior of clients. Supporting a second format is a big investment, and doesn't make sense unless there's a compelling need (like clients deprecating old format, etc).

If you're looking to query/manipulate packages, I would suggest checking out pgutil instead:
https://github.com/Inedo/pgutil

Thanks,
Steve

Hi @stefan-hakansson_8938,

I'm not familiar with deb882 / ubuntu.sources... is that a new kind of format? Is this causing some kind of problem or issue with clients?

Thanks,
Steve

Hi @jw ,

Thanks for the detailed report; this is definitely a bug, and we'll have it fixed in the next maintenance release via PG-2975 -- planning to ship next Friday.

Thanks,
Steve

Hi @parthu-reddy,

If you (the NuGet client) requests the NewtonSoft.Json-13.0.0 package, and ProGet already has that package cached , then ProGet will return the package without ever contacting NuGet.org.

However, the NuGet client will also request a list "all versions of NewtonSoft.Json when doing a package restore. I don't know why, that's just what it does.

In this case, ProGet will contact the connector (NuGet.org) and aggregate the remote/local results. If the connector is unreachable (as in the case above), ProGet will log a warning and instead return a list of "all (cached) versions of NewtonSoft.Json`... which will be probably all that's needed.

This is likely why no one has complained/noticed and jobs aren't failing.

Thanks,
Steve

Hi @caterina ,

In ProGet 2024+, the Project Analyzer will give some kind of warning/error and builds 1001+ will be in an "inconclusive" state instead of "Compliant", "Warn", or "Noncompliant"

That said, ProGet 2024+ does include capabilities to auto-archive builds through use of status/pipelines, so that might be worth investigating.

Thanks,
Steve

hey @steviecoaster ,

Great idea! This will be the default starting in the next maintenance release via PG-2965

Thanks,
Steve

Hi @parthu-reddy,

This basically means that ProGet was unable to communicate with nuget.org for one reason or another. More specifically... ProGet didn't receive a timely response.

Usually it's a temporary outage or network issue, and will hopefully go away and not cause any issues.

Thanks,
Steve

Hi @misael-esperanzate_5668,

Currently, ProGet uses the nexus-maven-repository-index.gz file to see what artifacts are in a Maven repository, and then downloads the files based on that. So you'll need to enable that index file by doing this, I think:
https://jfrog.com/help/r/jfrog-artifactory-documentation/maven-indexer

This only applies to Maven indexes, and that file is only used for importing/downloading a feed into ProGet. For other feed types, a different API is used.

Good news --- in an upcoming maintenance release of ProGet, we will be shifting to use the Artifactory API directly to import artifacts from a repository.

Thanks,
Steve

Hi Paddy,

Connector Filters allow/block packages by name (not version filters). The package name is FluentAssertions not FluentAssertions:>=8.0.0. So that's why it's not behaving as you expect.

Please see Dealing with Fluent Assertions License Changes in ProGet to learn more how to address this particular issue.

Thanks,
Steve

Hi @itadmin_9894 ,

Can you give us a few more details of what you're trying to do? A connector filter is intended to allow or block a package by name; it does not filter out versions.

Thanks,
Steve

Hi @mmaharjan_0067 ,

I'm afraid we're at a loss here; as you noticed, it works fine on the command line - but there's just something "off" about your runner.

The only thing we can figure is some kind of network block or interference. We don't really have a way to test/debug this any further.

Thanks,
Steve