@jw thanks for additional insight!

Unfortunately we simply won't have the opportunity to explore this until well past ProGet 2024, and only after we've gotten sufficient feedback from other early adopters on other gaps. I think there are other important things we need to consider as well, and handlign this is so much more complicated to handle this than it may seem, especially at scale and with how our ProGet is configured in the field.

There are also other mechanisms like policy exceptions built-in that could easily handle System.* and runtime.* packages, as I suspect the only thing you would worry about those are vulnerabilities.

As an alternative, I would if you could just write a tool/script to:

1. query for inconclusive builds
2. download inconclusive/missing package builds through a feed
3. trigger a reanalysis of the build

That's not optimal, but that is one thousand times easier than getting something liket his working in PRoGet.

Hi @jw ,

Although the released version will be able check for vulnerabilities without needing the package metadata, reading server properties (deprecation/unlisting), checking if it's latest patch version, doing license detection, etc. require having the package metadata.

However, the package metadata should already be in ProGet by the time you upload the sbom. When doing package restores from ProGet, the packages will be cached automatically. If that's not happening for you, make sure to clear your nuget package caches.

Ultimately we designed the SCA feature is designed to be used in conjunction with ProGet as a proxy to the public repositories. It's not a "stand-alone" tool, so it won't work well if packages aren't in ProGet.

The reason is, if the package metadata isn't in ProGet, it has to be searched for on a remote server. In your sample (one build, two packages), you're right.. it's just a few seconds to search that data on nuget.org. But in production, users have 1000's of active builds each with 1000's of packages... and that *currently * takes about an hour to run an analysis.

Adding 100k's of network requests to connectors to constantly query nuget.org/npmjs.org for server metadata would add hours to that time, triggers api rate limits, and causes lots of performance headaches. Plus, this "leaks" a lot of data about package usage, which is an added security concern. This is a major issue with tools like DependencyTrack - they're basically impossible to scale like ProGet.

Thanks,
Alex

Hi @jw ,

First, the reason you're getting "Package not in feed" (which would also happen in the ProGet 2023 feature as an Issue) is because that Sqlite package has not been cached or pulled to ProGet. However, if you just click Download (and thus cache) the package, then it would be in the feed, and this would go away.

When you browse a remote package in the UI, ProGet is querying nuget.org and displaying whatever their API shows. This query/data is not cached or retained otherwise - which is why it's missing when doing an analysis.

In ProGet 2024, "missing packages" wont be issues per se. Instead, an analysis will be "Inconclusive" -- and this means that there's not enough information to complete the analysis. If your policies don't check license rules (or there's an exception for license checking of Microsoft.* packages), then we wouldn't need the local package to analyze it - and this would be considered compliant.

However, this functionality doesn't work yet. That's just how it will work.

Alex

Hi @andy222 ,

The Git issue should be resolved; that was related to some authentication issues with newer versions of GitHub Enterprise. It broke a lot of tools across the board, apparently. Anyway, I see it just got fixed today. Check out BuildMaster 2023.10-rc.5 if you can

How about pushing a NuGet package instead? That's a much more common scenario (folks migrating from Octopus), and it's one we're going to add some good first-class support for in BuildMaster 2024.

Thanks,
Alex

Hi @andy222,

Very sorry for the frustrations here - it's frustrating for all of us too (me especially) when it doesn't work

Just to give some context here --- we made a huge investment in BuildMaster 2022/23, and one of the areas was a major improvement for how we integrate with ProGet. The feed::FeedName and directory::AssetDirName convention is brand new, and it's an improvement/simplification on the "Secure Resource" convention that you discovered. However, both conventions -- as well as directly specifying those values on the operation -- are still supported. There's a lot (too much?) flexibility.

Unfortunately this particular scenario / use case (downloading assets from ProGet) was simply not one that we focused on:

• Uploading assets is uncommon, but still happen
• Downloading assets is rare... and not something I've seen done in BuildMaster much

NuGet packages are not uncommon when coming from TeamCity/Octopus model. Regardless, we didn't focus on this use case. We felt most new users are seeking Git, .NET, Maven, Build, CI Import, and Docker, so that's where most of our effort was focused..

That said.... I would love to make your scenario / use case something really easy to set-up, so hopefully that will give you the confidence to continue!

In this case, it's a "trivial problem" where something just didn't get "wired" up the right way. I can clearly see from the code that the ApiUrl parameter is not being wired-up as it should be.

We'll get this fixed ASAP, just an extension fix. We just need to set up the scenario and make sure it works on our end first.

Cheers,
Alex

@emer-connelly_2117 very cool, thanks for sharing!!

Hi @sebastian-lieschke_5424 ,

Thanks for the request; this is something that is close to requesting a new feed type, so I'll use that rubric to decide.

As we wrote in that link, new feeds can be very time-consuming to research, develop, document, maintain, etc. Like with all software, even estimating the cost is costly - so we can't really even begin the initial research until there's sufficient demand or market opportunity to justify the possible investment.

To be honest, I don't see there being much demand or any market opportunity for this. Time will tell, and maybe someone will comment on this in the future. But for now this seems really niche.

That being said - I took a quick look at the document you linked, and I don't see API docs (i.e. those missing endpoints you mentioned). Maybe it's something as simple as a basic JSON document. Maybe it's an absurdly complex and undocumented API.

However, if you can figure how the API works, and it turns out to be something like a simple JSON/XML index file.... and you can prototype/fake that using a static file inside of a ProGet Asset Directory... then we can likely implement that quite easily.

I know that's how RPM and Helm Chart feeds got started long ago :)

Alex

Hi @sebastian ,

This will all get a pretty big overhaul in ProGet 2024. I'll share the details in the coming weeks, but here is a sneak peak:

This is what it would look like when viewing the MyFeed licensing rules:

The "Scope" refers to the name of a policy, and you can create shared policies, so this would mean shared sets of licensing rules. You can also bulk-edit license rules on a policy:

I think the new features will change your workflows a bit... maybe you'll use "Warn"? Or perhaps maybe you won't block Non-compliant packages? So for now, I'd wait and see :)

Alex

@valeon @miles-waller_2091 @olivier @It-purchasing_9924 @entro_4370

Took a bit, but CRAN (R) feeds have arrived

https://blog.inedo.com/inedo/introducing-cran-feeds-in-proget/

@mrbill @entro_4370 CRAN (R) feeds have arrived

https://blog.inedo.com/inedo/introducing-cran-feeds-in-proget/

@dima-tinte_1260 @rob-leadbeater_2457 @sdohle_3924

Debian (Apt) Connectors are here! Check out this blog article to learn more:
https://blog.inedo.com/inedo/new-debian-feeds/

@shfunke_1795 @jrottmann_6111 @sdohle_3924 @bahues_9728 @appplat_4310

Thanks for insight into this! I'm happy to report that starting in ProGet 2023.22, you can create Alpine (APK) feeds with connectors :)

@paul_6112 said in Do you plan to upgrade JQuery in a future ProGet release?:

This was picked up by nessus on BuildMaster v7

Lol wow - that's ridiculous

As I mentioned before, it's a forked library thus not vulnerable. So I suppose you can continue reporting it as a "false positive" to whoever seems to care, and perhaps we'll also just edit the version number out to appease that the security tool

Thanks @carl-westman_8110 , I appreciate the feedback!!

As someone coming from Azure Artifacts, I'd love to get your impression on our draft ProGet vs Azure Artifacts page - we're slowly starting to try to articulate the high-level differences and benefits to ProGet. But I swear marketing copy about the software is harder to write than the software itself

We also have BuildMaster vs. Azure DevOps comparison page too, though it's quite a bit more involved.

Hi @carl-westman_8110 ,

Thanks for the feature request! I'm afraid this one's a bit too niche to implement as described, and this use case isn't something we'd want to support for Universal Packages.

However, Asset Directories are a good fit for this, and one of the use cases is a Static CDN. So that means you could use it for web assets like docs if you wanted.

You'll still need to publish the docs like you would to the other webserver. And of course you could hyperlink to the document root from the universal package description as well.

Cheers,

Alex

Thanks for the feedback @philippe-camelio_3885 !

The Applications page is "ancient", and was originally designed to show "what build is in what server/environment". That was super-useful at the time, and I suppose still is, depending on the use case.

But with multiple pipelines per application (like you have now) this view isn't so useful. I'm definitely open to redesigning / rethinking some of these dashboard/aggregate pages.

This is something we can think about for v2024 (since v2023 is just a couple weeks away ). I've put a note onto our roadmap planning board, and may jump back or email you directly for some feedbakc/insight

@shayde @sebastian really appreciate the help, we'll get this incorporated ASAP !!

Hi @jchitel_9895 ,

Thanks for the additional info! We "moved" your new topic back to this one, since we link these on this page in the docs and want to keep everything in one place: https://docs.inedo.com/docs/proget-feeds-other-types

Keep in mind that feed types are a significant initial and ongoing investment (it's a product in a product), and at first glance, Homebrew doesn't seem to make any commercial sense.

First and foremost, there doesn't seem to be a market here. Homebrew itself isn't commercialized. They tried a Kickstarted from 2013, but it seems to remain a hobby-type project. Compare that to Chocolatey (which may be a little older, and also did a kickstarter I think) -- they now have a decent size fulltime staff now.

But secondly (and on a technical level), there isn't a "Homebrew Repository" or "Homebrew Server" - as you mentioned, it's Git-based - which means all it's doing is cloning Git repositories, and probably using tags and specific repo layouts to determine packages.

Cheers,
Alex

Thanks for clarifying @philippe-camelio_3885. I see the issue in the code now. I think it's been this way for quite a while

On the View Page, there seems to be some special handling for credentials;

return "ssh-rsa " + Convert.ToBase64String(cred.PublicKey);

I'm just going to delete the "ssh-rsa " bit, since apparently that can be incorrect. That's an SDK change actually, so it'll take a bit to be reflected in the products.

On the View Secret Fields page, we're just coercing the value to a string:

return InedoLib.UTF8Encoding.GetString(bytes);

That doesn't seem right either, but I'll just leave that as is. I know we redid that page in BuildMaster and eventually will bring to Otter.

There probably should really be a special page altogether for this type of credential, instead of using the generic "Edit credentials" page. Not a big priority but perhaps some day :)

@hwittenborn awesome! I'm not sure if you saw it yet, but we have a new API called the Common Package API; I hope to fold in Promotion, Repackaging, and Deployment under this so it can be consistent