@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:
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.
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
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
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
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:
w.x.y-ci.zw.x.y-rc.zw.x.yRetention 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
I'm afraid we simply can't reproduce this. Here is what we do:
/feeds/marvin/org.hamcrest/hamcrest-core/1.3All 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 @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
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
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