Hi @jw , thanks for pointing this out! I added a note to review/investigate this in our run-up to finalizing ProGet 2024.

Hi @sebastian, Thanks for sharing your thoughts on this! Few things to point out... [1] The "Missing Package Problem" is not as bad in ProGet 2024, mostly because it will only apply when there's a license rule. In ProGet 2023, a "missing package" would happen even for vulnerabilities. [2] We're working on a new feature/module (tentatively called "Remote Metadata") that is intended to routinely cache/update meatdata from public repos like nuget.org, npmjs.org, etc. This feature enables two usecases: Routinely update "server-side metadata" like Deprecated, Unlisted on cached packages Fetch metadata for packages not in ProGet during build analysis It works somewhat independently, and basically it'll just show up on the Admin tabs as like "Remote Metadata" and you can configure providers, urls, etc. I hope to have a prototype in a couple weeks and will post some details on a new forum posts. As an FYI this is something we will limit in the Free/Basic editions and have full-featured in the ProGet Enterprise product. [3] "Package In ProGet" could be a policy rule to add after RMetadata feature, though it's probably not a big deal if ProGet can detect licenses thanks to RMetadata Best, Alex

Hi @jw, Thanks for letting us know about these. To answer your questions: This is an issue with the order of how we delete the projects and their child items. If you delete all the builds first, then the project can be deleted without issue. We will fix this as part of PG-2596 that will be released tomorrow in ProGet 2023.31. This is an oversight on our part. We will get delete buttons added to the Edit Project Settings and Edit Build Settings page also as part of PG-2596. Thanks, Rich

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.

@stevedennis Famous last developer words: "Changing this one flag can't possibly break anything" Thank you for considering Cheers

Hey @atripp, Thank you for that snippet, very insightful. Oddly enough that issue is still on the .NET 8 Planning milestone, even though .NET 8 was already released this November. Ah.. one shall not question Microsoft's planning... ;)

Hi @jw , Thanks for reporting these! We'll get the fixed in hopefully the next upcoming maintenance release via PG-2520 and PG-2521 Cheers, Alana

Thank you for the pointers. I think I finally got it working, though I must admit I'm still not a 100% sure what combination in what order actually led to success. I'm already in contact with @apxltd about your planned SCA changes. I will try to write up what tripped me as part of that feedback.

Thanks for the additional feedback; this is definitely something we're revisiting for ProGet 2024. As you described, a lot of the pieces are there - they just aren't wired together very well in some cases. We're working on redesigning this to be more cohesive. A lot of the existing behavior has to do with performance. For example, /packages/from-purl?pUrl=... is a bit of a "hack" that we used. It's the navigation URL, then then redirects you to the proper URL. This is because finding the URL of a package can be expensive, especially when there are 1000's of packages in a SBOM and multiple candidate feeds for each package. Doing big joins across multiple feeds on the FeedPackages is something we need to very carefully do. On the same performance note, "Pulling from the source" can be expensive -- especially when you aggregate multiple feeds into one using connectors. So we need to be really careful before doing that. But like I said, this is something we are redesigning in ProGet 2024; you can think of ProGet SCA features as a "2.0" right now (I guess "1.0" was the old package consumers feature?), and hopefully "3.0" will be a lot closer to getting it right. Cheers, Alana

@jw thanks for the bug report! We'll get this fixed in the an upcoming maintenance release via PG-2491 :)

Hi @jw , The version number is a bit buried in the logs I believe, but it sounds like things are working now... and it's too much of a guessing game to figure out what might have happened now. Cheers, Steve

@lm thanks for letting us know that it worked! I'm glad you were able to find the issue on GitHub. Looking closer, it is a NuGet client bug; I posted an update on the issue. The only workaround is what you described (setting a separate API key).

You're right, caching SourceLink enabled PDBs would be somewhat useless for outages. Though there are still plenty of "old-school" PDBs around, especially for native code (C/C++).

Ok, thanks for the information.

Hi @jw , Ah, I can see how that would happen; I logged this as PG-2425 and we'll try to get it fixed in the upcoming maintenance release. Steve

Hi @lm, We do not currently have any way to be actively notified on new ProGet releases outside of the notification in ProGet. We do, however, perform regular releases of ProGet and we typically release them every 2 weeks. The best place to check for updates would be the https://my.inedo.com/dowloads page or the Offline Installers page. Thanks, Dan

Hi @lm , We've considered this over the years, but realized it'd be more engineering effort that just changing cookie duration; we'd want to track login sessions on the server side, allow them to be invalidated, etc. It's possible, but it seems the "Remember me" function on most services (GitLab, etc.) seems to be very forgetful anyways (for security purposes), and with Integrated Windows Authentication and browsers managing passwords, it seems not so valuable for the effort. Cheers, Steve