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 , 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

Hi @daniel.mccoy_4395 , Actually, developer experience is a big reason we don't recommend using Download Blocking. A 400 error provides no real context. Developers can see something is wrong, but not how serious it is or what to do next. First and foremost, an unlisted package should not be noncompliant. An author may decide to unlist their package for any number of reasons, including simply not wanting too many versions to show up in a list. This would mean that, all of a sudden, a build deployed to production can suddenly be considered as noncompliant just because an open source author arbitrarily flipped a switch on NuGet.org. That's not to say you should ignore the unlisted flag, but you should definitely not put it at the same categorization as a GPL3 license or severe vulnerability. "Compliant with Warning" could be a more appropriate status here, but keep in mind that developers swill naturally upgrade dependencies as they do platform updates, so it may not even be worth worrying about. Especially if it leads to constant warnings -- in that case, warnings become meaningless. Noncompliant packages should be rare for the same reason. If noncompliant can be determined by an OSS author's whims, then it really caries no meaning and no one (especially your developers) will understand/appreciate what it means. As for the workflow to use, we recommend running pgutil builds scan when that pull request is run. That will not only put the build in ProGet, but it will produce a text report with warnings or noncompliant packages. A ProGet login is not required. If there are Noncomplaint packages or warnings, the developer can then comment on the PR why it's nothing to worry about. If it's always the same package/issue ("we cannot upgrade from this 5-year old library and replacing it would be a substantial effort"), then you can formalize that as an exemption. The advantage to this workflow is that, if a deployed build later becomes noncomplaint (typically due to a vulnerability), then you can decide how and when to address it. The wrong time to address noncomplaint packages is "the next time a developer happens to open this project". Overall, what you want to avoid is having developers load a project for what should be a trivial change and then have to upgrade dependencies because it produces pointless warnings/errors. That will just create a "constant upgrade" mentality. That leads to constant regressions and constant headaches for testers or end-users, who have to deal with strange and unexpected errors from library upgrades. Hope that helps, Alana

Hi @rcpa0, It's hard to say, but maybe it has something to do with how the package file / archive was created. Can you share the file or a reproduction case? Thanks, Alana

Hi @brandon_owensby_2976 , Thanks for clarifying; it got a little distracting with the desire to have PR cleanups and specialized variables! We also see a lot of anti-patterns in Git repositories, such as using PRs for workflows, because that's how open source projects tend to work. Anyway, it sounds like you figured it the first part, which is to set the monitor to just create a build with a specific pipeline (e.g. "Feature Branch" pipeline). The next step, just use a retention policy that targets builds that have completed the pipeline. For example: https://docs.inedo.com/docs/buildmaster/builds-continuous-integration/buildmaster-ci-git-workflows/buildmaster-git-feature-branches#cleaning-up-feature-branch-builds-with-retention-rules

Hi @pmsensi , Oh sorry I didn't realize or notice it when reviewing the reply. We decided not to include it after all, mostly because we couldn't realistically model/generalize the data across ecosystems when it comes to things like how NPM handles dev-level dependencies, how PyPI handles environment dependencies, etc. The UI display garners a decent number of "complaints" because it doesn't represent it the same way as say, npmjs.org for example. That said, the manifest file (i.e. .nuspec) is cached in the database, but there's no "ProGet" API to retrieve that. You'd have to use the NuGet-specific API for that, or just download the package file and then extract the .nuspec file. Thanks, Alana

@atripp said: ust as an FYI, I submitted two pull requests for this: Thank you very much, Alana!

Hi @paul.moors_5682 , Without more details it's hard to say; this may be normal/expected depending on the feed type. The numbers displayed in the UI show what information is in the database, not what's on disk. So it's possible to have files on disk that aren't in the database, and vice versa. The Feed Integrity scan (part of ProGet 2025+) will help identify database entries without files. Then, you can run a "feed reindex" you can chose to delete database entries for missing files. Hope that helps, Alana

@manuel.riezebosch_8638 the purl argument was never actually read, so you could have really put anything in there :) It was just one of those docs error; many other api endpoints will use a purl argument And you're right... all the other package types have metadata inside the package, so that's what's read. Some require a file name, but Debian is an outlier in that it requires a distribution argument as well.

Hi @stevedennis, Thank you very much for your answer. From what I've read elsewhere, that's exactly what I thought. By the way, and besides that, ProGet is a really great tool. Good job ! Regards, Olivier

Thanks for the tips. That Docker constraint is particularly good to know, I hadn't realized! We do have a rather large amount of feeds to manage, including a (growing) set of feeds we use as local mirrors. I'll see if we can find an alternative solution that works for us...

Hi @jeremy-oaks_9309 , Just wanted to respond to this real quick: I have ~80k packages (~600GB) -- so we're opting for the stand-alone database for performance purposes Based on this information we still recommend using the embedded database; it's almost always going to be more performant as well as simpler to maintain. 80k is not that many packages by any stretch. While @pg_user_8607 is correct in that it's a bit easier to monitor database performance, investigate issues like bad queries, and do DBA maintenance tasks - that's all technically "our job". From a user perspective, the only required "database maintenance" should be backing up the files. We certainly don't mind the help (and users like @pg_user_8607 have helped us out a lot!!), and it may be quicker if you "know what you're doing" to get to a root issue, since we're not all exactly experts at all these layers. But I just wanted to make sure you were aware of the pros-and-cons. Thanks, Steve

Hi @brandon_owensby_2976, I wasn't able to reproduce this issue, but looking over the code, I can see a few scenarios in which "not configured to allow access to encrypted values" will trigger, even if that's not accurate. It's not trivial to rewrite that to provide a more accurate error message or credential resolution, so we'll add this to our BuildMAter 2027t roadmap and review it more closely then. In the meantime, I would just use a variable and duplicate the information. Thanks, Steve