Posts made by stevedennis

Hi @koksime-yap_5909 ,

Good catch; that is most definitely a bug. I just checked, and it's isolated to assets - packages and Docker images work as expected.

This will be fixed in the upcoming maintenance release via PG-3150; it's shiping Friday, but we can provide a pre-release if you're interested in testing earlier.

Thanks,
Steve

Hi @koksime-yap_5909,

In the event that the artifact has not been downloaded (i.e. the last download date is "null"), then the publish date will be considered. So if you set "90 days", then an artifact will be deleted at earliest, 90 days from publication if it hasn't been downloaded.

Thanks,
Steve

Hi @koksime-yap_5909,

The command will recreate the user, restore administrative privileges, etc. It's safe to run - and you'll ultimately be left with a Admin/Admin user that you can log-in as.

On ProGet 2025, the command is proget or proget.exe We should update the docs for sure

Thanks,
Steve

Hi @Sigve-opedal_6476 ,

There are some known issues that we intend to fix with PG-3144 in the next maintenance release (scheduled for Friday). This will likely be resolved then.

The inedo/proget:25.0.14-ci.10 container should have these changes inthem, if you'd like to try it out sooner.

Thanks,
Steve

@yakobseval_2238 thanks for letting us know, I just updated it!

Hi @k-lis_1147,

Based on what you described, it should show up.

Can you confirm what feed type you're using, and whether or not you're using PostgreSQL (this is the default for ProGet 2025).

I just discovered a bug (PG-3145) that would impact PostgreSQL (all feeds probably) and certain feed types on SQL Server (Maven) that would cause that information not to display on that page.

Easy fix, but just want to double-check

Thanks,
Steve

Hi @koksime-yap_5909 ,

If you ever get "locked out" of an Inedo product, either due to misconfiguration or a lost password, you can restore the default Admin/Admin account and reenable Built-in User Sign-on by using ProGet.exe resetadminpassword

Here's more information on this procedure:
https://docs.inedo.com/docs/installation/security-ldap-active-directory/various-ldap-troubleshooting

Thanks,

Steve

Hi @tayl7973_1825 ,

Thanks for the feedback; this is all a relatively new space, so we're in the process of building best practices / advice as well as tools to help teams solve these problems.

Right now, based on your suggestion, it sounds like the workflow would require us to manually identify which applications depend on a vulnerable library, notify each owning team

You are correct - the SCA Builds & Projects functionality is designed to "provide that link" between specific package versions and specific builds of applications. The builds are a moving target, as they may or may not be active/deployed.

The "Project" in ProGet is not intended to the "source of truth" about the project itself, but be sort of sync'd with the truth (e.g. like an Application in BuildMaster). That's why there's a "stages timeline" for builds in PRoGet.

hope it fits within their priorities, and then track remediation through individual tickets.

Our advice here is to think of it more like, "advise them of the identified security risk and unavailability of the impacted library they are using". Ultimately it should be up to the team (their product owner) to evaluate the risk you identified and mitigate it. For example, TeamLunchDecider1000 can probably live with a security risk, but let the team decide.

Once you've removed the library from ProGet, they can't use it anymore and it's "no longer your problem" to worry about or track through tickets.

Ideally, we were hoping our package management system — since it already governs distribution and security controls — could act as that “one stop shop” to track and visualize which applications still rely on a vulnerable version along side it's assigned severity rating.

ProGet already provides visibility into consumers through SCA, and you can already see how OSS Vulnerabilities impact builds.

HOWEVER, our core advice here is to not try to establish your own in-house "vulnerability database" for in-house libraries your organization. Even large orgs (2000+ developers) won't do that.

Instead, it's a simple binary decision: PULL or KEEP the library. If you PULL, then notify consumers it's unavailable going forward and let them decide how to mitigate.

That approach is superior to OSS Vulnerability workflows, but it's obviously not possible for OSS library authors to do.

Cheers,
Steve

Hi @tayl7973_1825 ,

Thanks for clarifying it. Based on that, I would say that "Vulnerabilities" are most definitely the wrong tool for the job. You can certainly "hammer in a screw" but there's a better way to do it - and we don't make "screw hammers" at Inedo

We're working on best practices / guidance on how to build security policies around these topics, but I'll try to give some tips now.

What you're describing isn't a vulnerability per se, but a SAST Issue: a potential weakness in code detected by a static analysis security tool. Most of these are false positives and present no real security risks, but some are.

If you discover a SAST Issue in one of your libraries, then you should use the following process:

1. Evaluate if it's a false positive or not
2. Unpublish the library internally if there's a security risk
3. Enumerate the consumers (i.e. applications in flight or deployed to production)
4. Evaluate the security risk (low, high), based on the consumers/usage
5. Notify the application teams to upgrade the library as appropriate

Note how this process is fundamentally different than OSS packages / vulnerability workflows:

• you can unpublish/block packages from your repository
• you know which applications are consuming your packages
• you know which teams maintain which applications
• you can work with those teams to assess the risks

Bottom line: if a package causes a real security risk, then unpublish it and fix the consuming applications as appropriate. Otherwise, don't.

There's really no middle ground or room in this process for "Vulnerabilities" - and trying to curate an internal "vulnerability database" is just going to make things less secure in your organization.

That's a theme in our upcoming content, but the general idea is when you treat all issues/vulnerabilities as security risks, then it's impossible to focus on the ones that are actual risks -- and it's as meaningless as saying "everything is a top priority".

Thanks,
Steve

Hi @tayl7973_1825 ,

This is not possible nor is it a workflow we'd recommend to support. Vulnerabilities have a very specific meaning / use case -- third-party discoveries in open-source packages that may impact your code (but probably won't) -- and it's not a good idea to "abuse" them for other purposes.

Deprecated is one solution, but a better would be to use SCA and monitor how that package is being used, so you can understand impact on library consumers:
https://docs.inedo.com/docs/proget/sca/builds

Thanks,
Steve

Hi @yakobseval_2238 ,

Can you let us know the commands/arguments you're using?

Thanks,
Steve

Hi @jlarionov_2030,

I haven't tested or tried it, but I can't help but wonder the API is responding with some kind of "license required" error, and blocking the seting.

I suppose we could investigate and try to resolve the error, but automated setup with a license key isn't so common of a requirement.... if tis is not really something you will do that often, perhaps it's not worth the effort.

Let us know your thoughts.

Thanks,
Steve

Hi @jlarionov_2030 ,

As of ProGet 2023 (or maybe earlier?), license keys are no longer requested / entered at installation time, but in the software itself now. This only matters on new instances.

You can use pgutil settings to set a license key if you'd like.

Thanks,
Steve

Hi @parthu-reddy,

Thanks for discovering/confirming that; unfortunately we're not able to reproduce this issue, as the multi-part / chunked uploads already take into account multiple servers.

• Chunked upload sessions are persisted in the shared database (ChunkedUploads table)
• Bytes are appended to a file stored in shared store

Would you be able to dig into the request patterns a little more? I suspect there's "something" configured on the load-balancer that's "doing something weird" with these ranged requests.

The Multipart Upload API explains what's happening behind the scenes, and you may find that using pgutil assets upload is easier to troubleshoot.

Thanks,
Steve

Hi @jw ,

It definitely looks like there's some "drift" in the documentation and behavior. I already see some stuff about "allowedFeeds" in there, which isn't even a thing since policies. And you're right, you can't update code/title, which aligns with the pgutil behavior as well.

We'd rather have "no documentation" than wrong documentation, any suggestions on what to delete from here? https://github.com/inedo/inedo-docs/blob/master/Content/proget/api/licenses/update.md

Feel free to submit a PR if you've got a clear idea.

In general, we want to make sure the pgutil docs are accurate (those are very easy to test), and we figure... someone can just look at the pgutil code to learn the HTTP endpoint or library.

Thanks,
Steve

Hi @udi-moshe_0021 ,

My guess is that your proxy server is blocking certain things or having issues with redirects; you'd really have to monitor the back-and-forth traffic to see what's going on.

As you can see, there are a lot of "redirects" going on and URLS/Domains that you will not expect and can be hard to predict.

Thanks,
Steve

Hi @it_9582,

First and foremost, we don't recommend the "package promotion" feature as a means to indicate which "stage" (i.e. tested quality) a package is in relative to a CI/CD pipeline.

Instead, repackaging should be used:
https://docs.inedo.com/docs/proget/packages/repackaging

Having multiple feeds is fine; we do that for Products and PreReleaseProducts on proget.inedo.com, but that's to make it "harder" for someone to accidently use a prerelease version. Otherwise, you can just use one feed and have retention policies cleanup the "-ci" builds.

As for having the "build promotion" feature in ProGet be used as a workflow engine (i.e. to trigger actions upon promotion), I don't think we would consider that. At the most, we would do a webhook of sorts... though it doesn't make a ton of sense to be honest.

The reason is that ProGet isn't intended as the "source of truth" for build status - the idea is that you would have something like a pipeline in BuildMaster) update the statuses in ProGet.

The main benefit to having this status in ProGet is retention of builds/SBOMs.

Hope that helps,
Steve

Hi @it_9582 ,

You can specify licensing information in the description or in a custom metadata field like _licenseCode or something. It's not something that ProGet "reads" or "understands", mostly we didn't imagine users would package and upload third-party content with unwanted licenses.

If that's a use case that your mid/long-term implementation, we could definitely explore working together and properly adding/supporting it as a feature. It's not something we'd want to just "quickly throw in" from a forum post :)

Definitely chat with your account manager / point of contact once you're closer to or past the "purchase" side of things and we can make it happen. I've forwarded this message to him as well.

Thanks,
Steve

Hi @mickey-durden_1899 ,

Just to double check, can you try.... resetting to disk-based storage, reconfiguring cloud storage, and then making sure that DisablePayloadSigning is checked. And tehn open settings, to make sure DisablePayloadSigning is checked and stays checked.

Thanks,
Steve

Hi @alexvanini_5999 ,

I would try using the Inedo Agent instead; if you are getting this error, it most certainly means that there is some kind of security/hardening/account setting that is blocking WinRM. This is the underlying technology that PS Remoting and the PowerShell-based agent use.

In this state, it's a real pain to get working - and the Inedo Agent is much more stable, anyway. It will not be "randomly blocked" by a new GPO or Patch Tuesday bug as we've seen a lot with WMI.

Otherwise, you'll need to scour the web for obscure settings that may have been applied to the server. You may see information logged on the target machine under Windows Event Log under Windows Logs → Application or System related to WinRM.

It's possible that the domain account lacks needed rights, even though it's a local admin. Sometimes subtle rights (like SeRemoteInteractiveLogonRight, etc.) can block initialization.

Good luck, let us know what you find!

Thanks,
Steve

Hi @jw ,

I'm not able to reproduce any issues on my end; I'm not entirely sure how you're testing, but let me share with you the code on the server side in ProGet:

    private static async Task UpdateLicenseAsync(AhHttpContext context, LoggedResponseStream output, WebApiContext apiContext)
    {
        EnsureMethod(context, "POST");
        EnsureCanManageLicenses(apiContext);

        var input = await JsonSerializer.DeserializeAsync(context.Request.InputStream, LicenseApiJsonContext.Default.LicenseInfo, context.CancellationToken)
            ?? throw new HttpException(400, "Expected license object.");

        var license = await DB.Licenses_GetLicenseAsync(External_Id: input.Code)
            ?? throw new HttpException(404, "License not found.");

        List<int>? nameIds = null;
        if (input.PackageNames?.Count > 0)
        {
            nameIds = [];
            foreach (var n in input.PackageNames)
            {
                if (!PackageNameId.TryParse(n, out var nameId))
                    throw new HttpException(400, $"Invalid package name: {n}");

                nameIds.Add((await nameId.EnsureDatabaseIdAsync()).Id!.Value);
            }
        }

        List<int>? versionIds = null;
        if (input.Purls?.Count > 0)
        {
            versionIds = [];
            foreach (var v in input.Purls)
            {
                if (!PUrl.TryParse(v, out var purl))
                    throw new HttpException(400, $"Invalid purl: {v}");

                versionIds.Add((await ((PackageVersionId)purl).EnsureDatabaseIdAsync()).Id!.Value);
            }
        }

        await DB.Licenses_UpdateLicenseDataAsync(
            License_Id: license.License_Id,
            PackageVersionIds_Csv: versionIds?.Count > 0 ? string.Join(',', versionIds) : null,
            PackageNameIds_Csv: nameIds?.Count > 0 ? string.Join(',', nameIds) : null,
            SpdxIds_Csv: input.Spdx?.Count > 0 ? string.Join(',', input.Spdx) : null,
            Urls_Csv: input.Urls?.Count > 0 ? string.Join(',', input.Urls) : null
        );
    }

I'm not sure if that's helpful, but if not... can you put a specific reproduction case?

Also note that the license data in the UI is cached, but it's invalidated when you visit the /licenses page and others.

Thanks,
Steve

Hi @fabrice-mejean ,

I'm not sure what you mean by "Custom OSS provider", can you clarify?

Thanks,
Steve

@aristo_4359 oh I see! The "search" function does not work by version in that case

Hi @rob-leadbeater_2457,

I'm afraid a "search by file hash" isn't supported, but you could relatively easily write a script to iterate through the feeds using pgutil. Or you could just search in the databse as well (FeedPackageVersions_Extended).

Thanks,
steve

Hi @aristo_4359,

You can see "all versions" of a package in the UI by clicking the package name in the breadcrumb or by selecting "All Versions" in the multi-button dropdown.

Thanks,
Steve

Hi @pmsensi ,

Can you take a look at this thread?

https://forums.inedo.com/topic/5493/request-for-creation-of-api-for-package-auditing-before-dependency-restoration/7

I believe that new API proposal ( pgutil packages metadata) would contain that information -- please share your thoughts in that thread so we can keep it in one place.

Thanks,
Steve

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 :)

Hi @jim-borden_4965 ,

Thanks for the feedback! We will add a note to the migration wizard via PG-3080 that clarifies that mounting the volumes are required - there's no easy way for us to tell if the user did that.

Thanks,
Steve

Hi @arose_5538 , we will have this fixed in Friday's maintenance release via PG-3077

Thanks,
Steve

Hi @m-lee_3921 ,

Sounds like you're off to a great start with Universal Packages - that's exactly what we intended them for.

Great spot on the docs. In retrospect, using the word "deprecated" was incorrect - we should have said "legacy", for the exact reason you mentioned. We intended to add those capabilities to the common packages API when we wrote the docs, but priorities...

Anyway I clarified the docs:

Legacy Universal Feed Endpoints:

The following endpoints are duplicative of the Common Packages API endpoints and should be avoided when possible:

• List Universal Packages - lists specified packages
• List Universal Package Versions - describes versions of specified packages
• Delete Universal Package - deletes a specified package
• Download Universal Package - downloads a specified package

While we don't plan on removing them in the foreseeable future, they are considered legacy. Once the Common Packages API includes metadata queries, we will likely call these endpoints "deprecated".

It wouldn't be "too hard" to add metadata queries to common packages API now that everything has been refactored... but there hasn't been any real user demand for it. And it's already easy to do with upacks as you can see.

Anyway, when folks start asking for this from other package types, we'll add it to our roadmap. For now, "legacy" is good enough.

Thanks,
Steve

@yaakov-smith_7984 good news -- we're working on a new version of the Active Directory integration that may address this problem -- want to give it a shot?

It's in our pre-release feed:
https://docs.inedo.com/docs/proget/administration/extensions#pre-releases

The extension is InedoCore 3.0.5-CI.2:
https://proget.inedo.com/feeds/PrereleaseExtensions/inedox/InedoCore/3.0.5-CI.2

We have been running it in our environment for a while.

This would be an ideal place to fix the issue, or at least add some kind of option to make it work better.