Hi @wechselberg-nisboerge_3629 ,

Given how you uploaded the file, the only scenario that I could see this happening is if the file on disk is somehow corrupted. For example, if you were to locate one of the .rpm files on disk and change a few bytes with a hex editor, I would expect this exact error to occur.

A feed reindex could would never fix this and obviously files cannot "heal themselves". However, this is exactly how hardware behaves, so I would look into that.

Thanks,
Steve

Hi @wechselberg-nisboerge_3629 ,

This error is the result of a "bad rpm package" (basically one that is compressed using a method we don't support) getting accepted into ProGet. It should have been rejected on load -- if ProGet cannot open a package file due to unsupported compression, then I'm not sure how it would have indexed the package.

You should be able to find which package it is by going to the "packages" tab at the top of the UI; when you click on the rpm package, it will give a similar error.

How did you add this package? What package is it? This is an error we can definitely fix if we can figurer out how you got the unsupported package in there.

Thanks,
Steve

Hi @wechselberg-nisboerge_3629 ,

These specific errors would have no impact on performance, feed loading, nor would they cause ProGet to "break down" in any manner. And rebooting would most definitely not help, since they stem from bad/corrupt data.

One possibility is that you have bad hardware - that causes peculiar and sporadic errors just like these that cannot be reproduced,.

I can only imagine how frustrating this is, but your experience is atypical and without reproduction cases we really don't know how to help. I would focus on trying to reproduce -- if it's indeed "bad data" that you are uploading, it would happen every single time.

Thanks,
Steve

@albert-pender_6390 great news!

And thanks for the heads up, I just updated the docs

Hi @albert-pender_6390 ,

This was renamed to proget, so it would just bew

/usr/local/proget/service/proget upgradedb

Thanks,
Steve

Hi @wechselberg-nisboerge_3629 ,

These messages are all unrelated and seem to stem mostly from a combination of bad/corrupt input data. Honestly I've never seen these errors before, but that's what they all sound like to me.

Are these impacting any actual usage, or are you simply "seeing" them in the Diagnostic Center?

If they are impacting usage, please put together a reproduction case so that you can consistently recreate the problem and we can study it.

Otherwise, if they are jjust "showing up" then you can disregard them. The Diagnostic Center is not intended for "proactive health" checking, just to troubleshoot usage errors. Messages logged there many not be problems at all, especially if users are doing things like uploading bad data.

Thanks,
Steve

Hi @wechselberg-nisboerge_3629,

I'm not sure what I'm looking at in the screenshot, but it's most certainly not a piece of process memory. Based on the string literal, it's likely a compiled library (i.e. DLL) that's invoking methods in that system library; you'd need to study the contents in a hex view look for executable headers if you really wanted to know.

Anyway, when it comes to downloading files, those are streamed directly from disk. In every instance of "corrupt downloads" that we've encountered, it was either due to network errors or hardware failures. And those are equally "impossible" to reproduce and nearly impossible to detect.

I would just try new hardware, that usually does the trick. We see this quite a bit in cloud environments (Azure mostly, but every now and then AWS and GCP).

Thanks,
Steve

In retrospect, I don't think pgutil would display the output like that exactly, but you get the idea. It'd basically be a bunch of label/text pairs -- basically not that different from what's in the ProGet UI

Hi @fabrice-mejean,

This begs the question of whether [obsolescence] should remain this way or if it should be managed more globally, similar to how vulnerabilities are handled. However, that would go beyond a simple API addition.

I could see this making sense for OSS packages hosted at their official source (e.g. NuGet.org, npmjs, etc) -- but you're right, much more than an API change and we should limit scope for now :)

Additionally, I would like to ask about the use of 'pgutil packages audit' and whether it indicates compliant or non-compliant. Does this status utilize all the rules (license, vulnerability, and others), and is there a plan to provide insights into the reasons behind the result? If it takes into account all the rules, then the 'other rules' are dependent on the feed, making the 'feed' parameter essential.

Good point -- the feed parameter would be important if you wanted feed-scoped policies. Otherwise, only the global policy could apply... which is limiting.

As for "reasons behind the result", there is a short text available in the compliance system that is displayed in the UI and error messages for non-compliant results. So I think we could bring that into the pgutil output like this:

$> pgutil packages metadata --feed=myNugetFeed --package=Junk.Package --version=1.2.3

Junk.Packge-1.2.3 (Deprecated, Unlisted)
 Compliance      : Warn (Deprecated; Unknown License)
 License         : RSGPL
 Vulnerabilities : None

So to summarize my understanding... here's what I'm thinking.

1. The pgutil packages metadata command will provide package metadata (i.e. from the manifest file), server metadata (listed, unlistd), vulnerabilities, and compliance -- similar to what the ProGet UI shows
2. It will work like the other packages commands, which require a feed parameter
3. We will not do the pgutil packages audit command afterall, since we don't have an easy way to work on a "set of packages" with regards to feeds

And of course, the new API call would return the data in a structured manner. We can share that as we get closer to implementation.

How's this sound?

Thanks,
Steve

Hi @shijiyong_6709 ,

This is a known limitation; when we implemented our Maven2 feed, we followed the 20+ year old Maven rule that "versions begin with numbers, artifacts begin with letters". Unfortunately there are some "ancient artifacts" and "broken versions" that don't follow this rule.

Since ProGet is not just a "dumb file server", knowing whether Arabba-SR13 is a version or artifact is important - and it's a nontrivial effort to address these "bad" artifacts. We will consider doing that in the future but it doesn't seem to impact a lot of artifactsa nd hasn't been a priority

Thanks,
Steve

@aristo_4359 thanks for letting us know! You are the first person to inquire about it over very many years :)

We'll see if anyone else is interested in this and then we can consider adding it!

Hi @antonio-oliveira_8481 ,

We have already assessed the vulnerabilities; the container image is not susceptible to any of these vulnerabilities. Only two ports are exposed on the container (for http/https) and the overwhelming majority of packages built-in to the base container image (debian) are not used.

Thanks,
Steve

Hi @antonio-oliveira_8481 ,

proget.inedo.com points to one of our edge node in an ProGet Edge Computing Edition network and is continuously replicating content from our hub server. Currently, we do not support replicating "non-content" (i.e. vulnerability assessments, license assignments, policies, etc.) -- only packages, containers, and assets.

Technically... that vulnerability information should not be displayed at all, since we disabled the feature on the feed. So that must be a bug of some kind.

Long story short, please disregard - we check all this on our central hub, but it's just not replicated to edge nodes.

Thanks,
Steve

Hi @parthu-reddy ,

That image is not actually hosted on Docker Hub, but in MCR (mcr.microsoft.com).

Confusingly, the Docker Hub is now used to "advertise" third-party containers in other registries, in addition to its own. In this case, there are no "tags" published on the docker hub page, so you know it's just an "ad" and not a real image

Thanks,
Steve

Hi @aristo_4359 ,

As you noticed, the feed does not support that endpoint. So there's no really way to get it working aside from us writing code to support it :)

Thanks,
Steve

Hi @fabrice-mejean,

Good point, it would not have PackageStatus. So let's jus say we add that in, like this:

Azure.Core-1.35.0 (Deprecated)
 Compliance      : Compliant
 License         : MIT
 Vulnerabilities : None

Obviously the API would return it in a structure manner, and it could also show downloads etc.

However, all this data (including package status) means we need a feed in context. So the command would have to look like:

pgutil packages audit --project=c:\projects\MyProject.csproj --feed myFeed

I'm not sure how I feel about that. Packages can be in multiple feeds, and often times users build from multiple feeds.

Anyway.... I have a new idea... what do you think about this:

pgutil packages metadata --feed=myNugetFeed --package=myNugetPackage --version=1.2.3

That could return the normal metadata, but also server-side metadata (package status, downloads, etc).

I guess it would require multiple API calls, though I doubt that's going to cause any more performance overhead than a "bulk" kind of API call that just "looped" over packages and looked them up in the same manner.

Let me know your thoughts.

Thanks,
Steve

Hi @pariv_0352,

Thanks! I'd try out 25.0.10-ci.10 -- it should work in theory! And if not then we'll just need to fix it anyway :)

Thanks,
Steve

Hi @inedo_1308 ,

This is likely a regression due to PG-3074 -- we'll take a look and report back!

Thanks for letting us know.

-- Dean

Hi @misael-esperanzate_5668 ,

When one of the connectors reports a 404, ProGet should move on to the next connector to search. Can you help set up a reproduction case using the ProGet UI and URLS (perhaps some basic curl commands)? You should be able to do everything with basic GET requests, and see different results.

That'll make it a lot easier to test and see if we can reproduce the issue.

Thanks,
Steve

@yaakov-smith_7984 great news!

We are planning to include it as is in the next maintenance release, later today. So it's "stable enough" we figure :)