Hi @fabrice-mejean , It's no longer possible to query this information from the database. As you've noticed, ProGet now uses a version range (i.e. AffectedVersions_Text ) to determine whether a package is vulnerable or not. So instead of 4.2.3 it's now 4.2.3-4.2.8 or [4.2.*) or something like that. Unfortunately it's not practical/feasible to parse this information unless you were to rewrite a substantial amount of ecosystem-specific parsing logic - this would be basically impossible to do in a SQL query. Instead, you'll need to use the upcoming pgutil packages meatdata command to see what vulnerabilities a particular packages has. You can also use Notifiers to address newly-discovered vulnerabilities. Thanks, Alana

Hi @koksime-yap_5909 , Not necessarily - it really depends on the API query. If the query is like "give me a list of all versions of MyPackage", then ProGet will need to aggregate local packages and connector packages to produce that list. If the query is "give me the metadata for MyPackage-1.3.1", then the first source that returns a result is used. In practice, NuGet asks for "all versions" a lot. So you'll get a lot of queries. Thanks, Alana

@james-woods_8996 we haven't released the extension yet, so it won't be in any builds of the product. We are waiting on someone to test/verify that it works

Hi @philippe-camelio_3885, Can you clarify what you've tried to date, and the issues you've faced? You can silently install the Inedo Agent, or even use a Manual Installation process if you'd prefer. Ultimately it's a standard Windows service, and you can change the account from LOCAL SYSTEM (which we recommend, by the way) to another account using sc.exe or other tools. Thanks, Alana

Hi @koksime-yap_5909 , Docker registry import from Sona, JFrog, and other ProGEt instances is coming soon via PG-3128 - we anticipate that in the next maintenance release. As for Assets, I'm afraid we don't have any support for that planned in the near future - it's relatively easy to write a script that "extracts" them - if you could extract it to a ProGet drop path, then they'll be imported that way. https://docs.inedo.com/docs/proget/feeds/feed-overview/proget-bulk-import-with-droppath -- Dean

Hi @tobe-burce_3659 , We do not support deleting or modifying any of the contents under the program directory; they will simply return when you upgrade and it may cause other problems. Instead, please create an exception; we are aware of the vulnerabilities in libraries that Postgresql uses and can assure you that they are false positives and will have no impact on ProGet... even if you were to be using PostgreSQL. Using virus/malware tools to scan/monitor ProGet's operation causes lots of problems, as these tools interfere with file operations and cause big headaches. Thanks, Alana

I had the same issue but it didn't update on startup so I ran this: cd /usr/local/proget/service/ ./proget upgradedb

Hi @fabrice-mejean , I definitely understand where you're coming from.... both commands basically work off the assets file, which is generated at build time. But your workflow is not common... the standard for SBOM generation is post-build. Doing it pre-build checking requires that packages.lock.json is used, which not many use... it's hard for us to advocate this workflow when most users don't care about saving time in this stage. I know we could add a "switch" or something to pgutil, but we learned "the hard way" that adding lots of complex alternative/branching paths to pgscan made for very difficult to maintain/understand code, so we want to keep the utility as simple as possible. Thanks, Alana

Hi @layfield_8963 , Thanks that makes sense -- since you've already got a personal repo going, I think it makes sense to stick with that for now. If other users are interested, we can explore it. We publish pgutil pretty regularly, so we'd need to automate updating that repository and that's just one more script t write and one more thing to break later :) Thanks, Alana

Thank you

Hi @it_9582 , This is a known issue / UI quirk with Conan packages, and hopefully should only impact that one page in the UI. To be honest I don't quite get the issue, but it has something to do with the fact that a Conan package is actually "set of packages that share a name and version". Each package in the set can define its own license file. The particular page was never really designed for "package sets" so the display is a little weird. It's a nontrivial effort to fix and would obviously impact all other package types, so it's not a priority at the moment. We would love to redo the UI at some point, s I think it'd mkae sense to do then. Thanks, Alana

Yeah, will do. I'll give it another try. Thanks Mickey

@udi-moshe_0021 sounds like it was a temporary outage on npmjs.org or perhaps even your proxy server. I wouldn't worry about it if it's working now since it's not something you could really control anyway

Hi @parthu-reddy, Thanks for discovering/confirming that; unfortunately we're not able to reproduce this issue, as the multi-part / chunked uploads already take into account multiple servers. Chunked upload sessions are persisted in the shared database (ChunkedUploads table) Bytes are appended to a file stored in shared store Would you be able to dig into the request patterns a little more? I suspect there's "something" configured on the load-balancer that's "doing something weird" with these ranged requests. The Multipart Upload API explains what's happening behind the scenes, and you may find that using pgutil assets upload is easier to troubleshoot. Thanks, Steve

Hi @it_9582, First and foremost, we don't recommend the "package promotion" feature as a means to indicate which "stage" (i.e. tested quality) a package is in relative to a CI/CD pipeline. Instead, repackaging should be used: https://docs.inedo.com/docs/proget/packages/repackaging Having multiple feeds is fine; we do that for Products and PreReleaseProducts on proget.inedo.com, but that's to make it "harder" for someone to accidently use a prerelease version. Otherwise, you can just use one feed and have retention policies cleanup the "-ci" builds. As for having the "build promotion" feature in ProGet be used as a workflow engine (i.e. to trigger actions upon promotion), I don't think we would consider that. At the most, we would do a webhook of sorts... though it doesn't make a ton of sense to be honest. The reason is that ProGet isn't intended as the "source of truth" for build status - the idea is that you would have something like a pipeline in BuildMaster) update the statuses in ProGet. The main benefit to having this status in ProGet is retention of builds/SBOMs. Hope that helps, Steve

Hi @stevedennis, thanks for your reply, it would be really nice if this feature could be implemented. We would chat about this with our point of contact. Thanks, Florian

Hi @alexvanini_5999 , I would try using the Inedo Agent instead; if you are getting this error, it most certainly means that there is some kind of security/hardening/account setting that is blocking WinRM. This is the underlying technology that PS Remoting and the PowerShell-based agent use. In this state, it's a real pain to get working - and the Inedo Agent is much more stable, anyway. It will not be "randomly blocked" by a new GPO or Patch Tuesday bug as we've seen a lot with WMI. Otherwise, you'll need to scour the web for obscure settings that may have been applied to the server. You may see information logged on the target machine under Windows Event Log under Windows Logs → Application or System related to WinRM. It's possible that the domain account lacks needed rights, even though it's a local admin. Sometimes subtle rights (like SeRemoteInteractiveLogonRight, etc.) can block initialization. Good luck, let us know what you find! Thanks, Steve

Oh ok, I was thinking that we could create a private metadata provider if we want deprecate our own packages without doing it on each feeds. So it will not help me. Thanks