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