Ahh, took me a while to get it, but this is the dialog I was looking for. It wasn't quite clear that the orange "Package Status is Deprecated" is actually a policy violation dialog, which is overriding this one here. Thanks again.

Hi @rhessinger Works like a charm, thanks. Have a nice weekend.

Ok thanks for the explanation.

Hi @andy222 I'm afraid we don't have that capability in OtterScript, and it would require a new variable function to do that. You might be able to add that in an extension, or we could add it as well.. but we have a few things we want to finish first on our BuildMaster 2024 roadmap. Since you're creating build variables using the API, I wonder if you could just create a variable called @BuildVariables that is just a list of the variables you're creating. Then you can use $BuildVariable(name) to get the value. Hope that helps, Alana

Hi @rhessinger, thank you very much! We will just wait for the next release and I will come back to you if we encounter further problems. Thanks, Caterina

@pariv_0352 oh interesting - for some reason I thought NuGet was used for C++ packages... I just did a quick look, and it doesn't look like vcpkg supports private registries; it only looks for package files on disk (share drive?) or in a Git repository: https://learn.microsoft.com/en-us/vcpkg/maintainers/registries So I guess the first step would be to ask the vcpkg team to create a package registry :)

Hi @atripp Thanks for the update! Looking forward to the potential addition and the release in late October. Best, mars

Hi @arkady-karasin_6391 , A 403 error means Not Authorized; since those are publicly-available repositories, my guess is that you have a Proxy or Content Filter that's blocking that URL, and the ProGet Server is getting a 403 response from that intermediate server. -- Dean

@joel-shuman_8427 thanks for the heads up! I just updated it https://github.com/Inedo/inedo-docs/blob/master/CONTRIBUTING.md

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