Hi @rhessinger, I have now tested 26.0.9-ci.1 in a test instance and I can confirm it is working exactly as expected. Thanks for the quick response again! Joris

Hi @dean-houston, I think there might be a little bit of a misunderstanding. I'm not really evaluating the product. I'm selling the product. I've been using BuildMaster for over 10 years (I'm thinking 14 or 15) and most of which as a paying customer. I started a new job last year and I'm once again I've decided to try to sell your product to my employer. Previously I've just had to do a presentation on the product to get the company on board. Here, unfortunately, I need to do a little more show-n-tell rather than talk about the product. Not only that but this is the first place I've worked at that has a workflow quite like it does so it has brought up questions I didn't have to deal with, but I've never had any doubt I could/would accomplish what I needed. Since I know how hard of a sell this will be I'm trying to put extra effort in to coming up with the best demo possible and is leading to some of the questions. Thankfully I think I'm near the end of building what I need to build so hopefully will not be doing too many more posts on the forum. I really do appreciate all the time you and others have given to respond to my posts but I do feel a bit bad for how many and how complex my posts of been. Unfortunately I do not really know when I'll finally do the demo/presentation to my superiors, and I am kind of hoping I can wait until 2026 comes out before I do. I hate to sell a product and the version my pitch is based on is no longer the newest :-). Thank you, Brandon

Thanks @sigurd.hansen_7559 ! All right, I'm convinced.... this makes a lot more sense now to do now! I didn't quite realize that Microsoft does not allow non-VSCode clients to connect to their Marketplace, nor did I realize there were so many VSCode forks. The current plan is to create a new feed type called "Open VSIX" or something that will support connectors. It should also be able to handle the "multi-file packages" (i.e. how the same extension can have multiple .vsix files but different architectures). We should be able to just reverse engineer the VSIX API as well. That's clearly Open VSIX did; it's not all that complex I think. I've just now updated the other feed types; we don't have a date just yet, but it should e in the coming months. We'll keep this thread up to date.

Hi @jimbobmcgee , Long story short, "we're not entirely sure anymore." You've picked up on the original intent: these are intended to provide UI-based inputs around script parameters. And they do "mostly" show up in the use case you identify (i.e. when creating a Job Template for the first time)... but they are overall a glitchy feature. They were also intended to allow for Param()-like support to other scripting languages, so you'd simply need to add that header to the script and it would just "work" in OtterScript and job templates. From an engineering standpoint, we had planned to improve all of these after Otter 2022 (when they were first released), but our R&D priorities suddenly shifted. So we haven't had time to revisit them (or other Otter features we wanted to do), and they're basically in that same glitchy state Personally I thought they were a pretty neat idea, and it's just unfortunate we weren't able to take them further. But, so it goes with development priorities... -- Dean

Hi @amy.j , Looks like the code was actually merged in and shipped, but that status wasn't reflected on the YouTrack issue, so the note didn't get added to the release. Anyway I've modified the status and manually updated the release notes now. -- Dean

@brandon_owensby_2976 fantastic!! Thanks much; I'll let our technical writing team review/accept it, They should within a day or so -- Dean

Hello @atripp , I've now had a chance to try out the new version of PGUtil and the changes are working great. Thank you for your assistance :) Best Regards Nils Nilsson

I've had a chance to test the new version of pgutil now and it works perfectly, thank you. Best regards Nils Nilsson

Hi @dean-houston . Thank you for your response, it makes sense that you wouldn't prioritize this, as I assume my organization is quite an outlier where we need to have one policy for every application that utilizes ProGet. Best Regards Nils Nilsson

Hi @dean-houston Thank you for the detailed response. I'll dive into the properties set and retention create commands to see if the current implementations already cover our automation usecase. Fair point about the API, then I'll continue to default to using PGUtil so that you at least have one less user depending on the API in case you want to supercede/deprecate it in the future :) Best Regards Nils Nilsson

Hi @cyril , Thanks for checking; that would be fine. Note you'll have to enter a license key in your scripts (free is fine), as ProGet will not automatically create a license key. Aside from various features missing from Free edition, one restriction is that ProGet Free can't connect to other instances of ProGet. The software will generally enforce this as well. -- Dean

Hi @daniel.pardo_5658, This behavior is somewhat expected. I'm not really a Debian expert or anything... but when it comes to a Debian repository index, all is actually the name of a component. When we look the index files, we can see: ubuntu-jammy has all components ubuntu-jammy-updates has no all components ubuntu-jammy-security has no all components ubuntu-noble has all components ubuntu-noble-security has all components ubuntu-noble-updates has all components I would have thought that any means "any component", but apparently it doesn't. So I guess you have to specify that list if you want it to work. -- Dean

Hi @brad.zinser , This is somewhat expected, although the error could be improved. You're sending a Content-Type: application/json or similar header, which will attempt to read the content body -- but since it's a GET request, there's no body. And at some point, that error occurs. -- Dean

Hi @brad.zinser , I'm having a bit of a hard time reproducing this or figuring out how this might be possible. What kind of CI do you have set-up? Did you configure anything via the API? If so, would you be able to share the XML used for the underlying Secure Resource (it's in the SecureResources table if you're poking around in the Database)? You can also go to Admin > Secure Resources to get a more "raw" view of this. As an FYI, here's the code where it's failing: [image: 1786126801171-38a275e7-8e5f-4062-992c-61405d435dee-image.jpeg] However, that property (project.LastSync) is set in exactly one place (project.LastSync = DateTime.UtcNow;), so it doesn't make a lot of sense to me. Let us know what you find! -- Dean

Hi @brad.zinser , This is expected behavior across our products... both the Diagnostic Center and Native API require system/admin-level access, so it's not exposing any information administrators can't already easily see. Note that, you can also see the API key exposed in standard HTTP access logs as well if you pass via the query string, so the X-ApiKey header may be better anyway. Thanks, Alana

Hi @caterina , Glad this is working now! I have no idea what it could have been.... maybe there was some kind of platform/library regression. We didn't make any WIA/AD/LDAP changes -- just went from .NET8 to .NET10. This stuff is a bit fragile, as you're noticing Anyway, all good for now! THanks for letting us know -- Dean

Hi @Ashley, It wouldn't make sense to try removing "vulnerable packages" from storage -- in fact, even download blocking doesn't make sense in most cases, as it tends to lower the organization's security posture and leads to other problems. Even the package with the "world's most severe vulnerability" (i.e. the infamous log4shell) is harmless unless it's incorporated in an application in a certain way and the application is exposed in a certain manner that would allow a malicious actor to exploit it. Trying to block access or remove these harmless library files from the network will substantially lower the organization's security posture, for a number of reasons. I'd encourage you to check out our best practices guide: Vulnerability Management Done Right with ProGet. In particular: Preparing for a Category 5 Vulnerability to learn how to handle the "next" severe vulnerability Blocking & Containing Vulnerable Packages for general best practices in addressing them in pipelines I think the Preparing for a Category 5 article will help you create that template process for what to do when that high vulnerability package is is identified. Hope that helps -- Dean

Hi @a.sieger , I would push back on that "hard requirement" because it doesn't make any technical or business sense, and will only lead to support headaches just like this. There is something wrong with your PostgreSQL server configuration, perhaps permission related, that's causing the database to not be created. The error cannot be logged in the database because it doesn't exist. I would delete the database and start again, but verify you've created the database exactly as specified using the exact version supported: https://docs.inedo.com/docs/installation/postgresql#external-postgres Things like improper locales will cause errors. Then, don't run ProGet detached (i.e. ommit -d) so you can get the console logs. That's where you will see database errors. You can also run the upgradedb command instead: https://docs.inedo.com/docs/installation/linux/installation-upgrading-docker-containers#upgrading-the-database-only-optional Please let us know what you find! Hope that helps, Alana

@atripp thanks