Posts made by stevedennis

Hi @Ashley ,

It should have been; I just double-checked and see a commit for "Add full PEP 700 conformance for PyPI feeds" that appears to add the fields discussed here and some more.

Thanks,
Steve

@Nils-Nilsson FYI quick update, but it does look like LDAP searching is having issues in the UI.. so perhaps it's some kind of UI//library upgrade regression. Anyway we'll update once we have a fix.

Hi @Nils-Nilsson,

Aside from library/dependency upgrades, I'm not aware of any changes to AD/LDAP that would yield this change. So it's definitely possible a dependency update caused that, we'll keep our eyes out... but things did pass our ordinary LDAP/AD testing, so any other info would be really helpful ... like if it's easy to do a new testing instance so you can upgrade/downgrade to find if that's definitely the issue.

As for permissions/tasks, there were definitely no changes here. The tasks/permissions data were not touched as part of the upgrade, nor was the data/schema changed; the renaming of "Feed Groups" to "Feed & Project Groups" is entirely cosmetic.

Behind the scenes (in the database), it's still FeedGroup_Id. The only schema changes were related to creating new tables for vulnerability data and adding a column to projects table to support grouping. There were no data updates.

Thanks,
Steve

Hi @ybaskar-temp_3339 ,

Thanks for confirming that.

I think it'd be worth exploring how to change those migration/environment constraints. While it's unfortunate to "lose history" and need to navigate to a separate instance, there's a moderate amount of risk in things simply not working the way it did before.... we're talking a decade of evolution, including platform, architectural, and even usage changes.

That said, for an in-place upgrade, here's the approach that I would use.

1. Use the Legacy (Traditional) installer to get to BuildMaster 6.1.
2. Verify things work as expected on BuildMaster 6.1, agents updated, etc
3. Upgrade to BuildMaster 6.2, again using the traditional installer
4. Verify things work as expected in same manner
5. Uninstall
6. Ensure all components (iis site, service, program files.... except database, artifacts) have been removed
7. Install BuildMaster 2025 as per normal, pointing to existing database

Note that there's a decent change that you'll run into database or binding errors after #7, so make sure to run buildmaster.service.exe run from the commandline to better see messages and errors if things don't start up.

Cheers,
Steve

@steviecoaster sure thing!

https://github.com/inedo/inedo-docs/tree/master/Content/proget/feeds/chocolatey#.md

There's a "hidden in plain sight" GitHub link under the heading of each article, mostly for us :)

Figured a PR/example would be easier than back-forth on forums. Thanks!

Hi @pg_user_8607 ,

Unfortunately, the only information we receive from the underlying library is LdapReferralException, so there's nothing else we can log. My understand is that the server is limiting the information and you ought to see more information from the LDAP/AD server's query logs (they are like HTTP access logs). That's the absolute best place to look.

In our experience, a referral typically means the domain name is incorrect (e.g. user@domain.com instead of user@domain.local), but it could be any of the things you mentioned to. Unfortunately, LDAP/AD configuration can be a pain in rare cases (which it sounds like you are), and there's just no way around that.

As for monitoring, here is what we recommend:

• periodic monitoring of the /health endpoint (every 5 minutes)
• (optional) HTTP access logs (retain for 7 days)

There's nothing required beyond that. Those "container logs" (i.e. proget console output) that you see are primarily intended for us (product engineers) to troubleshoot problems and there's not much value in trying to use/storing them.

For a tool like ProGet, trying to do extract/monitor detailed metrics is counter productive and leads to information overload. Many "errors" are not problems are a total waste of everyone's time to troubleshoot.

For auditing, ProGet maintains internal audit logs (you can query them from the database if you really want to "export" them), or you can use webhooks if you want to publish events. But again, we don't think that's productive; they just become a "secondary log" that no one looks because it's harder to query than ProGet database.

For authentication-related information, a combination of HTTP log monitoring (403 errors) and LDAP/AD server is the best thing to check.

Cheers,
Steve

Hi @ybaskar-temp_3339,

Upgrading from BuildMaster 5.7 to 2025 has never been supported; you'll need to first upgrade to BuildMaster 6.1, and then you can upgrade to BuildMaster 2025. Please see:
https://docs.inedo.com/docs/buildmaster-upgrading

It's certainly possible there was a bug/oversight in newer versions of the Inedo Hub that didn't "block" the upgrade, but it should never have been possible. Also I do believe we removed really old versions from the Inedo Hub, so you may need to download the offline installer to get to BuildMaster 6.1.

Another approach to consider is to just "start from scratch" with BuildMaster 2025, and maintain BuildMaster 5.7 as a separate instance... moving to read-only over time. If a lot of your applications are templatized anyway, you may find the built-in Build Scripts work with minimal configuration. And as long as you're on the latest version of Inedo Agent (on the servers), they should be able to both communicate fine. This approach is the lowest risk by far.

Cheers,
Steve

@steviecoaster sounds good, feel free to submit a PR with suggestions if you'd like anything to add. For us, we usually just point to connectors documentation, though the topic doesn't really come up with this feed

Hi @steviecoaster ,

We haven't had any users ask for help on this; it's pretty straight-forward in ProGet, as the UI guides users to do this and even pre-populates the default URLs. But if you think there's some nonobvious things or issues you've seen, then a technical note would be great (like we have on Connectors for Debian Feeds).

I should note... we did not create a dedicated HOWTO guide for this use case (unlike, for example, HOWTO: Proxy Packages from NuGet.org in Visual Studio or CLI), mostly because we don't generally recommend it. Instead, we recommend internalizing the packages.

What do you think about editing this section to clarify that?

https://docs.inedo.com/docs/proget/feeds/chocolatey#internalizing-chocolatey-packages

Thanks,
Steve

@dwilson_7533 that sounds about right! In modern versions of BuildMaster, it's possible to change Pipelines ("new" name for Workflows) a little easier, or even create builds without them.

Speaking of, I'd recommend giving it a shot, we've got some pretty cool Git integration these days :)

Hi @caterina,

Well, it's Microsoft, so their teams and guidance is all over the place... and that article is "AI-assisted" (labeled as such), so it's probably even more inconsistent than Microsoft's normal docs :)

But, I definitely agree on the convenience of WIA over tokens. In any case, we don't have a plan to discontinue it from our products - but it is a "risky" feature, both in terms of making ProGet less secure and regressions (from Windows updates, or client/ProGet upgrades). So that's why we encourage users to move away.

Anyway.... as for the issue, can you try adding ?bypassIntegrated=false to the URL? We are linking directly to the NPM API, which is bypassed. I'd like to see if that solves it.

Thanks,
Steve

Hi @caterina,

I was referring to Windows Integrated Authentication (WIA) in general; while it's not "formally deprecated" yet, a lot of Microsoft's guidance and support it's basically treat it as a legacy technology used for existing internal intranet scenarios (especially now that NTLM has been disabled by default), and Microsoft’s modern web application guidance explicitly recommends token-based authentication instead.

So, that drives our guidance as well.

In any case, it sounds like you're doing port sharing:

Our ProGet instance is bound to a hostname and a port.

If you can bind it to just a port, then this should work. The reason is that hostname-binding requires operating system components (i.e. HTTP.SYS) to handle the request, and ProGet cannot disable it on a per-url basis.

Thanks,
Steve

@pg_user_8607 sorry I accidently deleted that when trying to fork it into a new topic... I briefly saw the logs and wanted to review w/ team to see if we can figure them out

Can you repost them again as a new topic? Thanks, we can then track it separately.

Hi @caterina ,

First and foremost, Microsoft has effectively discontinued Windows Integrated Authentication (WIA) in favor of more modern and secure environments. As such, we strongly advise taking this opportunity to simply move away from it.

Our recommended environment is:

• No authentication required to view/download packages
  • the only exception to this is packages containing things like trade secrets.
  • that should not be the default, as "when everything is secret nothing is"
• API Key required to publish packages
  • minimal permissions (i.e. no overwrite)
  • limit to feeds when appropriate, so you don't have too many keys
  • consider rotating annually

That said, WIA is still supported in the Integrated Web Server and unsupported feeds (like npm) are automatically excluded from WIA when Kestrel is used (i.e. when you are NOT doing port sharing, and binding to a port). You can also explicitly exclude NuGet feeds.

However, it's not possible to do "authentication by port", like what was possible by creating two sites in IIS.

Hope that helps,
Steve

Hi @pg_user_8607 ,

Can we move this issue to a new topic? I would "split" it for you, but then it won't show up on our dashboard when a reply comes through.

Separate threads make it a lot easier to manage things on our end and keep track of things better :)

But before you do that, just a hint - look at the container output startup logs. Basically just run without the -d and you'll be able to see the console output, and post anything related to the databse there.

Thanks,
Steve

Hi @brandon_owensby_2976 ,

The image that's being used is mcr.microsoft.com/dotnet/sdk:6.0, which is technically a "fat manifest" that points to a number of platform-specific images. But that's all handled by the Docker engine.

So if you're getting a Windows-based image, then it means the Docker engine is not using Windows. I haven't used DockerDesktop in years, since WSL2 is much more reliable and a similar-to-production experience.

I mentioned this in my other reply, but I would suggest to "play around" with the commands using docker run ... to see if you can get this working using that container.

Once you can get it working from the CLI, then it won't be problem for Buildmaster to do the same thing.

Thanks,
Steve

Hi @brandon_owensby_2976 ,

You can run Linux VMs on your laptop without an issue. They don't require much disk space or memory, and that's what WSL2 does behind the scenes.

Docker containers aren't designed as or intended to be "servers" per se; they are meant to just run a single program without worrying about any operating-system dependencies. You can technically SSH into them and run other programs, but that's really only done in specialized debugging scenarios.

In other words, you should not be "running commands" inside a Docker container, whether using SSH another means. Instead, you use the docker run command, which will create a container from an image, execute a command, and then stop the container.

As far as getting unit tests to work, that may require additional dependencies. I don't really know. But they way to test that is by running commands like this:

docker run --rm -v "$PWD:/src" -w /src mcr.microsoft.com/dotnet/sdk:10.0 dotnet test

That basically just spins up a container to run dotnet test. That is what BuildMaster is doing behind the scenes.

When you do docker run proget.inedo.com/productimages/inedo/buildmaster:2026.0 it's doing exactly the same thing, you just don't get to choose get to choose the command that runs when the container "spins up".

Hope that helps

Thanks,
Steve

Hi @brandon_owensby_2976 ,

This isn't really something that makes sense in the Docker paradigm. Keep in mind that a Docker container is essentially a wrapper for a single executable and is designed to be disposed after the command runs. That's how the Image-based services work as well.

If you want to get Linux builds working, I'd start with a Linux-based server (create a VM) and SSH into it. You later try out Image-based services as well, but that also requires a Linux-based host.

Thanks,
Steve

Hi @brandon_owensby_2976 ,

Based on the error message, it looks like you've got Docker Desktop configured to use Windows-based containers, not Linux. I'm not sure if this can work on Docker Desktop; it's just a not a stack anyone considers/supports for use cases like this.

The underlying error appears to becoming from the dotnet tooling. Though it's hard to say without troubleshooting further. Basically, something in the stack is calling the Linux tool id , which isn't going to work on a Windows container.

If you're evaluating/testing, I would just use a virtual machine and pretend it's a remote server or something to that effect.

Thanks,
Steve

Thanks for sharing all the details @sgardj_2482.

You shouldn't need to modify the Embedded Database like this when using a GMSA. It should continue to work just fine using a username/password as configured. If you ran into an issue when changing the service account, please let us know.

Note that we don't support modifying the Embedded Database like this, so please be aware this may suddenly break in a future upgrade.

Hi @certificatemanager_4002 ,

This is really easy to do in ProGet and no need for a "scan". I can't even imagine how such a "scan" could work.

Anyway, you just simply need to add a connector filter that prefixes your internal packages. For example, our filter for NuGet packages would look like Inedo* - which prevents any package named that coming through a connector.

Check out this article to get some more details:
https://blog.inedo.com/software-supply-chain-security/three-things

Thanks,
Steve

Hi @daniel-mccoy_4395 ,

About the only way I can imagine that happening is if you delete the version from the feed and navigate to that page. Or, if it was a remote package, and somehow the connector stopped working between pages.

I would try to find a pattern and see if you can reproduce this more consistently.

Thanks,
Steve

Hi @Nils-Nilsson ,

This will be fixed via PG-3266 in the upcoming maintenance release (next Friday). It looks like it was a separate, SQL Server only bug. It's easy to patch if you'd like the SQL Script. Just let us know!

Cheers,
Steve

Hi @scusson_9923 ,

Looks like this is a bug in not overriding the job/execution status; the force normal statement should make it "green" and a normal execution status. Anyway we'll get it fixed via OT-524.

Cheers,
Steve

Hi @adoran_4131 ,

It looks like the 404 error is occurring while trying to download the Release file (i.e. the index) for the repository. The file is being downloaded from this URL:

{connector-url}/dists/{distro}/Release"

And that URL is returning a 404. So make sure you are entering the correct distro in the connector.

Thanks,
Steve

Hi @matthias-schmitz_2037 ,

The "Signature ... was created after the --not-after date" message is coming from sqv (Sequoia-PGP verifier), which newer versions of APT use for signature verification.

It almost always indicates a system clock problem on the affected machine, not a repository problem, and often means "The system clock is behind the signature creation time."

So bottom line, I would check the clocks to make sure they are accurate.

Thanks,
Steve

Hi @scusson_9923 ,

The message is expected, but you should see scriptExists: false written at the end, and aNormal status (i.e. green) for the execution.

Is that not the case?

Thanks,
Steve

Hi @scusson_9923 ,

Sorry on the slow reply; i wanted to test this, but didn't get a chance and figure I'd just share this now (which should work):

set $scriptExists = true;

try
{
    Get-Asset FooBar.ps1
    (
        Overwrite: true,
        Type: Script,
        To: D:\temp\FooBar.ps1
    );
}
catch
{
    set $scriptExists = false;
    force normal;
}

Log-Information scriptExists: $scriptExists;

Cheers,
Steve

Hi @v-makkenze_6348 ,

This is a regression introduced from ProGet 2025.20's changes to malicious package handling. It's not intentional, and only the specific versions should be blocked (8.10.1, 9.1.1, 10.1.6, 10.1.7)

We'll get it fixed via PG-3227 in the next maintenance release (scheduled for this Friday, but we may do a pre-release sooner). For now your best bet is to rollback to ProGet 2025.19.

Thanks,
Steve

Hi @daniel-pardo_5658 ,

This behavior is expected; the UI is meant for creating basic, case-insenstiive archives.

As for the permissions.... File metadata (including owner, execute permissions, etc) are stored within the filesystem (or as metadata in a zip file)... so once you transmit a file, that information is irrevocably lost.

Best to upload a package file.

Cheers,
Steve

Hi @daniel-pardo_5658 ,

Thanks for the suggestion; Universal Packages already support tags in the package manifest file: https://docs.inedo.com/docs/proget/feeds/universal/universal-packages#manifest

Otherwise, if you're referring to "tagging" a package already added to a feed - that's a hard pass :)

The reason is that a package is designed to be self-contained (i.e. all the metadata about the package is stored within the package) and cryptographically sealed (i.e. so you can't edit/mutate a package). Tags break these, as they apply semantic metadata outside of the package.

These have caused big issues in ecosystems that have tried them (like npm) - but long story short, there's a good reason they don't exist and there's most certainly a better way to accomplish what you're trying to :)

Cheers,
Steve

Hi @geraldizo_0690,

Thanks for the pointers -- now as an FYI, these settings would have to be a Feed-level setting, but the drop-downs would be the same.

FYI, here's the code we use to generate the Release file --- I'm not sure what those other header values do, but we probably wouold just want to add the two you suggested.

What do you think?

I suspect this will be a quick, opt-in change!

private void WriteReleaseFile(Stream output)
{
    using var writer = new StreamWriter(output, InedoLib.UTF8Encoding, leaveOpen: true) { NewLine = "\n" };
    writer.WriteLine($"Suite: {this.Distro}");
    writer.WriteLine($"Codename: {this.Distro}");
    writer.WriteLine(FormattableString.Invariant($"Date: {this.Generated:ddd', 'dd' 'MMM' 'yyyy' 'HH':'mm':'ss' UTC'}"));
// NotAutomatic: yes  <-- add here
// ButAutomaticUpgrades: yes <-- add here
    writer.WriteLine($"Architectures: {string.Join(' ', this.indexes.Select(i => i.Architecture).Distinct(StringComparer.OrdinalIgnoreCase))}");
    writer.WriteLine($"Components: {string.Join(' ', this.indexes.Select(i => i.Component).Distinct(StringComparer.OrdinalIgnoreCase))}");

    var desc = FeedCache.GetFeed(this.feedId)?.Feed_Description;
    if (!string.IsNullOrWhiteSpace(desc))
        writer.WriteLine($"Description: {desc.ReplaceLineEndings(" ")}");

    writeHashes("MD5Sum:", i => i.MD5);
    writeHashes("SHA1:", i => i.SHA1);
    writeHashes("SHA256:", i => i.SHA256);
    writeHashes("SHA512:", i => i.SHA512);

    void writeHashes(string name, Func<IndexHashData, byte[]> getHash)
    {
        writer.WriteLine(name);
        foreach (var i in this.indexes)
        {
            writer.WriteLine($" {Convert.ToHexString(getHash(i.Uncompressed)).ToLowerInvariant()} {i.Uncompressed.Length,16} {i.Component}/binary-{i.Architecture}/Packages")
            writer.WriteLine($" {Convert.ToHexString(getHash(i.GZip)).ToLowerInvariant()} {i.GZip.Length,16} {i.Component}/binary-{i.Architecture}/Packages.gz");
        }
    }
}

Hi @brandon_owensby_2976 ,

It sounds like you're on the right rack with troubleshooting; the issue is definitely on the server-side in this case, so I asked ChatGPT. Who knows if any of this is accurate, but...

This is a very common situation with older versions of Bitbucket Server (especially pre-6.x / pre-7.x era, but even up to some 7.x versions in certain setups).

The REST API (e.g. /rest/api/1.0/...) and the Git Smart HTTP protocol (/scm/.../info/refs, /git-upload-pack, etc.) are handled by different authentication filters in Bitbucket Server.

Most likely you're using a Personal Access Token / HTTP Access Token (most frequent cause in older versions). In many Bitbucket Server versions (especially ≤ 7.17–7.21), HTTP access tokens were designed mainly for REST API and did not work reliably (or at all) for Git over HTTPS in many cases.

As a workaround , you need to use a real username + password (or username + app password if 2FA is on) for Git operations

We've seen similar in really old version of ADO, GitHub, etc, where API tokens wouldn't work for Git.

Anyway, I would try that - at least from the curl side of things. And maybe upgrading will help as well. If it works, then you'll likely only be able to use a Generic Git repository with a real username/password -- and just create a special builds user which effectiveely acts like an APi key.

Cheers,
Steve

Hi @Stephen-Schaff,

It seems pretty easy to add these up and display them on the screen! I suppose the "hard part" is the UI...

A "Total" line doesn't seem to look right. And it seems like too little information to put in one of those info-boxes. "Total Size: XXXX MB" at the bottom just looks incomplete.

Any suggestions? I'm struggling a bit to see how it could be displayed without looking a little out of place... and since it was your idea I figured I'd ask ;)

Thanks,

Steve

Hi @geraldizo_0690,

Hello,

I'm not all that familiar with Debian/APT... but I briefly researched this, and it seems like this involves adding values like this at the top of the Release file like this:

NotAutomatic: yes 
ButAutomaticUpgrades: yes

Is that it really? And this setting would impact the entire feed... but have no real relation/impact to connectors or packages?

If that's the case, how would you envision configuring this? I'm thinking on the Feed Properties page, but perhaps as a checkbox? How do other products/tools do it in your experience?

Thanks,
Steve

Hi @brandon_owensby_2976 ,

Thanks for the feedback. Based on what you described, it sounds like...

• BitBucket Server API is working fine
• Git API is not working due to a failed/failing authentication challenge

You were able to confirm this with the "Generic Git Repository" also not working. If you were to do a curl -I -u USERNAME;APIKEY https:/.../.git you would most certainly get a 401 response as well.

Anyway that's where I would start -- try to figure out why the Git API is not accepting the credentials. It's most likely related to permissions on theh key, but it's really hard to say... just a guess.

Thankks,
Steve

Hi @Julian-huebner_9077 ,

Here's some information on file storage paths:
https://docs.inedo.com/docs/proget/feeds/feed-overview/proget-feed-storage

Long story short, if you modify Storage.PackagesRootPath under Admin > Advanced Settings and move your files as needed, then it should work just fine.

Thanks,
Steve

Hi @kquinn_2909 ,

We haven't forgotten about this; the issue is trying to figure out steps to reproduce it based on the information we have... considering it works on our test instance and all. We may consider putting some more debugging code in, though figuring out how to expose that in this context is a little challenging.

Just as a sanity check though, do you have a project that doesn't have a "space" in the name? I want to make sure this isn't something really simple as WebProjects%20Replicator vs WebProjects_Replicator.

The other idea is authentication/authorization, though I would imagine you would get an error accessing the project instead of no builds.

Thanks,
Steve

Hi @jstrassburg_8563,

if the resolved version that npm i underscore chose was released in the blocking period, the npm command would 400?

If you have "Block Noncompliant Packages" enabled (which we generally don't recommend) and you have a rule that new packages are complaint, then the npm command would most certainly give some kind error.

You will probably see a 400 code, but I don't think it will display the message that's sent by ProGet (i.e. "package blocked due to...")? The real issue comes with a large dependency tree, and it'll be hard to know what exactly the issue is.

As such, we recommend running pgutil builds scan/audit in your CI/CD pipelines instead of blocking. This will produce a much easier to understand report, and even allow you to bypass issues reported on a case-by-case basis.

Thanks,
Steve

Hi @sigurd-hansen_7559 ,

Thanks for pointing me to the repository; I was able to reproduce this, and it will be fixed via PG-3194 in the next maintenance release (scheduled for Friday).

Thanks,
Steve

Hi @toseb82171_2602,

In Docker, images must have a namespace. When they don't, the Docker client will transparently append library/ to those namespaces. In general, this behavior is not desirable, and it's recommended to use library/python or, in a ProGet context, myproget.corp/mydockerfeed/library/python.

That said, there is a setting on the connector that may help resolves such images, but these images can be problematic even with that.

AS for extending the trial, no problem - you can actually do this yourself on my.inedo.com, on the day of expiry. Of course, please contact us if you run into any issues or have licensing questions.

Thanks,
Steve

Hi @nachtmahr,

Yes, that's what I would reommend doing -- using the internal storage path. Just make sure to NOT select the option to delete the files and make sure to select "search subdirectories" so everything will be imported.

Cheers,
Steve

Hi @nachtmahr ,

There is no "clone" method per se, but you can accomplish this by bulk-importing packages into a new feed: https://docs.inedo.com/docs/proget/feeds/feed-overview/proget-bulk-import

Cheers,
Steve

Hi @tim-vanryzin_8423 ,

Great question on developer experience! We're very curious to learn that ourselves, so please let us know as you implement it.

First and foremost, if you haven't already, check out the Recently Published & Aged Packages rules blog article to see how this works and our current advice. FYI - we are likely going to change the best practices guidance in 2026 to discourage download blocking.

From an API/technical standpoint, it's simply not possible to "hide" the fact that 1.12.15 is the latest version. So, if you have a connector, ProGet will report the latest version as reported by the connector.

But even it were technically possible, there's no simply great developer experience here. Keep in mind that most never look at the ProGet ui -- they configure things once, and forgeet about it.

So really, it's just a question of when you want the developer to find out they can't use Xyz-1.12.15. Here are the general options:

• Manual Curation (no connectors) - it's always going to be on nuget.org / npmjs.org, so even if you manually curate every page in ProGet, they'll know it exists and will be confused why it's not on ProGet; they may not even know who to ask
• Download blocking - you could simply block downloads of newest packages, but that's just going to look like random "400 errors" to developers and they will become frustrated
• Build Auditing - run pgutil builds audit on your build server, and you can see if the packages are noncompliant; this is where we are shifting our advice, as a failed build at that stage will be so much more obvious than a 400 buried in a package restore step

Ultimately this requires training developers to use lock files and not always get latest. That's why we are shifting to pgutil builds audit -- it's almost self-training. When their builds fail, they will see the reason clearly and should be able to adjust their code/configuration to not use a non-compliant version.

-- Dean

Hi @jonathan-werder_8656 ,

Thanks for clarifying! I'll be honest, I had no idea where you were getting configuration files in the first place... and I forgot that was ever a thing. Sorry about that.

Anyway, I don't think that this has worked in years, and it's most definitely not something we'd recommend today. We'll try to track it down and remove it in the docs / help text.

For your use case (automated installation) just use pgutil settings to set that value.

Thanks,
Steve

Hi @henderkes,

I'm not familiar with module streams, but if you tried it in ProGet and it didn't work then likely not? It sounds like a different API/endpoint, but I haven't researched it at all.

However, based on how you described it ("removed from Fedora 39"), it sounds like one of those "good but old" technologies that don't make sense for us to implement.

Thanks,
Alana

Hi @jonathan-werder_8656 ,

You can set this value under Admin > Advanced Settings.

Thanks,
Steve

Hi @pmsensi ,

You'd need to run through a proxy like Fiddler or ProxyMan, which can capture the outbound / inbound traffic. Or if you provide us with a URL/API key we might be able to play around and attach a debugger. You could always create a free trial or something and set it up that way.

First thing that comes to mind is that your endpoint is incorrect and you may need to "play around" with the URL. Typically it's like this:

• endpoint is https://server.corp/path/my-pypi
• index file is https://server.corp/path/my-pypi/simple
• ProGet automatically appends /simple unless you specify otherwise on Advanced

The "Simple " endpoint is just a list of HTML like <a href="...">. That's what ProGet/connectors/pypi follow.

Thanks,

Steve

Hi @ayatsenko_3635, @dubrsl_1715,

Thanks for the feedback and continued discussion.

So, our Composer feed is relatively new, so we are open to exploring new ideas. One option might be to do an "import" of packages into ProGet, similar to how we handle connectors in Terraform feeds. But that's something that could also be done with a script, so we'd want to see what that looks like as a prototype.

That said, we definitely can't implement "content pointers" to Git repositories. The Git-based "package" model is not only outdated but it has several "fatal" Software Supply Chain problems.

The biggest problem, by far, is that package content is hosted by a third party (i.e. GitHub) and managed by another third party (i.e. the repository owner). At any time, a package author or the host can simply delete the repository and cause a major downstream impact - like the infamous left-pad incident in npm.

This is why other package ecosystems have adopted a "read only" package repositories and disallow deletes (except for rare cases like abuse). Once you upload a package to npmjs, nuget, rubygems, etc. -- it's permanently there, and users can always rely on that being the case.

That's simply not possible with Git-based "packages". The "content pointer" must be updated periodically updated, such as if the author decides to move the Git repo to GitLab, Gitea, etc. Now you no longer have a read-only package repository, but one that must be editable. Who edits? Are they tracked? What edits are allowed? Etc.

There are several of other issues, especially with private/organizational usage, like the fact that there's no reasonable way to QA/test packages (i.e. compared to using a pre-release/repackaging workflow) and that committing/publishing are coupled (i.e. you tag a commit to publish it). This makes governance impractical.

And that's not to mention the fact that there's no real way to "cache" or "privatize" third-party remote Git repositories. Unless, of course, you mirror them into your own Git server... which is technically challenging, especially if the author changes hosts.

We first investigated feeds years ago, but they didn't have package files at the time -- only Git repository pointers. Like Rust/Cargo (which used to be Git-based, and still technically supports Git-based packages), we anticipate this same maturity coming to Packagist/Composer as well.

So while we certainly understand that this is a workflow shift, it's a natural evolution/maturation of package management. Likewise, it took decades for the development world to shift from "file shares" and legacy source control to "Git", but that's what everyone has standardized on.

That's the world ProGet operates in, so it might be a bit "too far ahead", or we might be misreading the tea leaves - but a "package mindset" is a requirement in using ProGet. But hoepfully we can make that easier, possibly with exploring "package imports" or something like that.

Cheers,
Steve

Hi @frank-benson_4606 ,

Thanks for clarifying, that makes sense.

I'm afraid that ProGet does not "crawl" the parent artifacts for metadata; we had considered it, but it's rather challenging to do from an engineering standpoint, difficult to present crawler errors, and fairly uncommon.

Thanks,
Steve