Thanks for adding it to the roadmap. From what I can see so far, there haven't been that many changes in the spec. For us mainly the author field changed. Right now there is no immediate need. It might arise in the future if improvements or fixes are only being made available in the CycloneDX 4.x tooling.

@apxltd At the moment we only have five I think. The adoption rate of it has been slow due to the SCA feature being very interesting but lacking the presentation of some valuable information, such as what this thread addresses. Once the adoption grows with increased information connectivity (builds with the associated packages for instance and this license component) we would likely have more than 300 or 400 build projects.

HI @parthu-reddy , Thanks for the feedback; I update the docs to mention that the feeds/permissiosn would also need to be updated as well. We hope to handle an in-place migration in a future version, but didn't want to delay shipping the feed. Please let us know if you have any issues/feedback. Note we are adding several improvements to the Maven (New) feeds in ProGet 2024.15: PG-2798 Add Direct Download (Artifact Import) Support for Maven (New) Feeds PG-2797 Add OSS Metadata Caching Support to Maven (New) Feeds PG-2796 Improve MavenIndex Download Visibility for New Feed Connectors PG-2792 Feed Management API Returns Empty Type on Maven2 and new feeds PG-2794 Add Simulated Directory Browsing to Maven (New) Feeds -- Dean

Hi @parthu-reddy , I'm afraid we don't have enough information to help with this; it appears to be an error the tool you're using (packet), and there's not enough information in the screenshot to see what error packet is encountering. It just says "Packaged failed with could not download..." We aren't familiar enough with packet to know how to follow their Stack Trace. If you can't find a clear error message, I would use an HTTP Proxy tool like Fiddler Classic to inspect the traffic that packet is making, and see if you can spot an issue there. I would also try downgrading packet , as it's very possible there's a regression in the tool. -- Dean

@dean-houston Thank you for the insight! Definitely did not think of that as an issue.

Hi @arunkrishnasaamy-balasundaram_4161 , Thanks for clarifying! [1] The MavenIndex file is not at all required to download artifacts from a remote Maven Repository nor to see the latest version of artifacts. In ProGet, all this allows you to do is browse remote artifact files in the ProGet UI which typically isn't very helpful. [2] It's not possible to change this [3] ProGet does not have "group repositories", but uses feeds with connectors. The model is different, and feeds with connectors will often cache packages in a lot of organizations. [4] It's likely you will be unsuccessful in your ProGet configuration with a setup like this or at least give your users a big headache and lots of pain/confusion. This is considered an "old mindset" the for configuring artifact repositories that were based on "files and folders on a share drive" not packages. This "closed approach" will greatly slows down development, causes duplicate code, and lots of other problems. Modern development approaches do not use this level of highly-granular permission. Instead, they take a innersource model. You do not need to make everything available to everyone. However, less than 1% of your 2k projects will contain sensitive IP or data that other teams can't access - those projects should be segregated into sensitive feeds. The logic is, "if everything is sensitive, then nothing is sensitive" [5] ProGet does not generate a "support zip file"; if we require additional information when supporting users we ask for the specific information

Hi @uvonceumern_6611 , Thanks for providing all of the additional information; based on what you shared, it looks like the file is actually being uploaded incorrectly... using a "multi-party / form upload encoding" instead of a basic PUT of POST of the body contents. Please see the Upload Asset File documentation for more information. Thanks, Steve

Hi @caterina , Thanks for checking; I was able to reproduce this; it seems to be a regression.... we'll get it fixed via PG-2795 in next week's maintenance release. Thanks for letting us know. Thanks, Alana

The reason for blocking application packages like this, that have vulnerable dependencies, comes down to security governance. While yes, it can be inconvenient if a package that has worked before is now blocked, that does prevent us from introducing known vulnerabilities into our environment. In the event of an emergency deployment (ex prod rollback, etc), we could apply a temporary exemption to allow the package to still deploy -- after doing a risk assessment. To use the log4j example again -- if we have an application that was built with a vulnerable version of log4j, nobody would want that package to get deployed again (while also remediating it anywhere that it was already deployed). From what I can tell the most effective way would be to block the download from ProGet - if we can leverage it's automatic blocking functions. Adding the audit into the deployment process is definitely one way to partly add this security layer but it'd require active implementation for all of our deployments, and opens more opportunity for teams to skip or work around it. Basically its better than nothing yes, but it's not the most effective security enforcement measure.

Hi @jw , This doesn't seem like a a trivial change, due to the way those pages work, so I'll add it to the "wishlist" - we've got a lot of other ProGet 2025 roadmap stuff prioritized ahead for the time being :) Cheers, Alana

Hi @dan-brown_0128 , It doesn't look like there's been much interest in this so far (we haven't heard any othe rrequests for it), but I wanted to mention that Terraform repositories are planned and something we hope to accomplish in the coming months. Cheers, Alana

@sebastian said in Problem with PGV-22381O7 (tree-kill1.2.2 incorrectly flagged vulnerable): There should be a special treatment for withdrawn vulnerabilities within ProGet. Maybe not deleting them (because I'm pretty sure there will be cases where I will be looking at a package and think "I swear this one had a vulnerability, but now I can't find it?" ), but maybe auto-assess a special status to it. That's what we were worried about as well, having them dissapear. Perhaps we just delete ones without assessments, and if you set a withdrawn vulnerability unassessed, it gets deleted

@carl-westman_8110 very happy to hear it, thanks for the kind words :)

Hi @husterk_2844 , I'm afraid we're at a loss here; no one else has reported any kind of errors like this, and I can't imagine what would even cause such a problem. I suspect there is something off about your Docker Compose file? That seems to be the only thing different than the basic setup. I would just try to re-follow the basic instructions we posted: https://docs.inedo.com/docs/installation/linux/docker-guide That's what we use to test, and lots of users install and upgrade without a problem. Thanks, Steve

Hi @forbzie22_0253, The easiest solution is to change both the "ProGet Service" (INEDOPROGETSVC) service and the "World Wide Web Publishing Service" (W3svc) to Automatic (Delayed Start). This typically allows SQL Server to start before IIS and the ProGet Service start. Thanks, Dan

Hi @atripp thank you very much, downloading the latest version solved my issue. Best, Caterina

Hi @forbzie22_0253, There's no Windows event logged, but once the /heath page is reachable, then the application is ready. If you're using SQL Server and IIS on the same box, then both of those must first load before ProGet can start. Thanks, Steve

Great thanks for confirming Dean

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 @steviecoaster , The Native API can be a little finicky, especially since you can invoke with JSON, forum-encoded values, querystring, and I think even XML. But it sounds like you're on the right track. Let me share the C# code that ProGet uses to set the password: using (var rfc2898 = new Rfc2898DeriveBytes(password ?? string.Empty, 10, 10000, HashAlgorithmName.SHA1)) { var bytes = rfc2898.GetBytes(20); DB.Users_SetPassword(userName, bytes, rfc2898.Salt); } ... it looks a little different than the code you're using, so hopefully that will help! -- Dean