Hi @Nils-Nilsson ,
Good news - this is actually on our ProGet 2026 roadmap.
The general idea is to "reuse" Feed Groups -- I guess we'd call them "Feed & Project Groups" or something? Anyway, the projects would be grouped in the UI similarly, and you could scope project-based permissions to a group.
We will try to get it as a preview feature in the coming weeks, assuming it can be done in low risk. It seems like this would be the case.
Cheers,
Alana
Hi @mikael ,
We plan to add this support via PG-3213 in an upcoming maintenance release -- perhaps Feb 20 if all goes well!
Cheers,
Alana
Thanks for the inquiry! The changes are available in the inedo/proget:25.0.24-ci.4 container image, and we'd love to get a second set of eyes. Are you using Docker?
They're relatively simple, but we just avoid changing stuff like this in maintenance releases... so it's currently slated for ProGet 2026.
But it should be okay for a maintenance release. Please let us know, we'll decide to release based on your or other user feedback.
Here's what we changed.
First, we added a "sixth" component called IncrementalVersion2 that will support versions like 1.2.3.4-mybuild-678 (where 4 is the second incrementing version), so that vulnerability identification can work better. Our implementation is based on the the Maven version specs, which in retrospect, seems to be followed only by ProGet. Pretty low risk here.
Second, we changed our "path parsing" logic, which identifies the groupId, artifactId, version, artifactType from a string like /junit/junit/4.8.2/junit-4.8.2.jar into /mygroup/more-group/group-42/my-artifact/1.0-SNAPSHOT/maven-metadata.xml.
It's a little hard to explain, so I'll just share the new and old logic:
//OLD: if (urlPartsQ.TryPeek(out string? maybeVersion) && char.IsNumber(maybeVersion, 0))
if (urlPartsQ.TryPeek(out string? maybeVersion) && (
char.IsNumber(maybeVersion, 0)
|| maybeVersion.EndsWith("-SNAPSHOT", StringComparison.OrdinalIgnoreCase)
|| (this.FileName is not null && !this.FileName.Equals("maven-metadata.xml", StringComparison.OrdinalIgnoreCase))
))
{
this.Version = maybeVersion;
urlPartsQ.Pop();
}
Long story short, this seems to work fine for v8.5.0 and shouldn't break unless someone is uploading improperly named artifact files (e.g. my-group/my-artifact/version-1000/maven-metadata.xml or e.g. my-photo/cool-snapshot/hello-kitty.jpg).
Thanks,
Alana
Thanks @joshua-mitchell_8090 , we'll consider merging it in then!
As for "how the dependencies are identified within the project build vulnerabilities", I suppose so - the IncrementalVersion2 will allow for proper vulnerability associated with packages that use "incorrect" versions (like 1.2.3.4). Jackson Databind is the one we kept coming across.
Note you can request another trial key from my.inedo.com to try it out :)
Hi @devops-user @joshua-mitchell_8090 ,
Thank you so much for testing! We'll merge this in via PG-3251 in tomorrow's maintenance release.
As for the other error, it's technically unrelated - but that package has such a long "compliance analysis report" that it's getting truncated in the database cache. PostgreSQL complains about that, SQL Server silently does it. Anyway w'ell fix via PG-3250 perhaps in tomorrow's release as well.
Cheers,
Alana
Thanks for checking; for a short-term like this no problem!
Cheers,
Alana
Hi @geraldizo_0690 ,
I think the best way for us to proceed with this investigation is to get a copy of your database backup. And as a bonus, we'll validate your database to make sure the upgrade to ProGet 2026 and the new vulnerability management features work nicely :)
I created a secure public link for you, which you can access in this ticket that I've created for you: https://my.inedo.com/tickets/view?ticketNumber=EDO-12790
Just let us know once you've uploaded the BAK file, and we'll take a look and figure it out from there.
Thanks,
Alana
Hi @Ashley,
Thanks for testing it! That was the intended behavior here - to count "days" not "24H blocks". That's a more intuitive pattern in general, as people think "the next day" or "a few days later" and don't really consider the time.
That does lead to some strange behaviors like 2026-05-03 23:59:59 to 2026-05-04 to 00:00:01 being considered "1 day". However, in this use case, I guess we're talking just a difference of hours which isn't going to make a package any "safer" realistically.
Thanks,
Alana
PS good catch on typo, I adjusted it on 2026 branch.
You can reset the Admin user account password by stopping the ProGet Windows service, then running ProGet.Service.exe and selecting the "ResetAdminPassword" option. Make sure to restart the Windows service when finished.
Hello; I've updated the documentation to clarify this, but it's available starting in ProGet 5.2.9. So, you'll need to upgrade to enable it :)
I'm not very familiar with PyPi packages, but I know there are some oddities with - and _, and that they are sometimes supposed to be treated the same, and sometimes not. We don't totally understand all the rules, to be honest (even after reading PEP503 specifications).
In this case, the package is actually websocket_client, not websocket-client.
See: https://pypi.org/project/websocket_client/
When you search for websocket_client in ProGet, it shows up, as expected.
We've got some major container improvements coming in ProGet 5.3, and will revamp our product; hopefully we'll be able to present this pretty soon!
I think, once you see what we have planned, you'll want to change/improve your workflows to simplify things, and this may not even be necessary... anyways, stay tuned.
You're right, I guess that's showing the "layers" instead of the "tags"; I think it should be showing container registries separately (they're not really feeds), but that's how it's represented behind the scenes now.
Anyways we are working on ProGet 5.3 now; there's a whole bunch of container improvements coming, so I've noted this on our internal project document, to make sure we get a better display for container registries.
As @apxltd mentioned, we've got a whole bunch planned for ProGet 5.3.
I've logged this to our internal project document, and if it's easy to implement in ProGet 5.2 (I can't imagine it wouldn't be), we'll log it as a bug and ship in a maintence release.
Do note, this is not an IMAGE description, it's a REPOSITORY (i.e. a collection of images with the same name, like MyCoolContainerApp) description; so this means the description will be there on all images/tags in the repository.
In ProGet 5.3, we plan to have a couple tabs on each Tag (i.e. container image) that would provide this info: Metadata (will be a key/value pair of a bunch of stuff), and Layers will show details about each of these layers.
That might help, but otherwise, we have retention policies which are designed to clean up old and unused images.We'll also have a way to detect which images are actually being used :)