Posts made by steviecoaster

We have the full gamut of environments. Those with unfettered access to the unwashed internet, proxied environments, a single machine with access we can tunnel through, to, yes, SCIF-levels of lockdown.

In all of those scenarios, we offer an offline prep script that bundles everything needed for the installation into a zip file, which you can then sneaker-net into the environment and continue the installation.

I think we can make the offline installation work based on what I'm seeing in the documentation. I just wanted to make sure it was a "supported" mechanism of installation.

SQL Server is super fun!

So the account you initially installed ProGet with in Inedo Hub will have permissions in SSMS to modify permissions for the SQL instance. This is because Proget installs SQL for you if you don't already have it installed.

If you have the credentials the Proget service used to use, log in to SSMS with those credentials, then create the SQL Server login for the NetworkService account following @atripp's guidance above. Then, when you start the ProGet service, it should "see" the database.

Hello,

When it comes to installing to ProGet in an air-gapped environment where InedoHub will be unable to reach the internet to download the necessary Proget installation items, what level of support can be expected of Inedo should issues arise?

We are working to standardize on an Inedo Proget repository solution inside all of our pre-built environments here at Chocolatey, and I need to ensure that any method we put in place follows a supported path.

I understand that we will be deploying the free version of Inedo Proget to these environments, which provides an opportunity to upgrade to a paid version later for our customers, and as such "support" options are limited to these forums, but I'm curious how much support Inedo can and/or is willing to provide here should we opt to use the offline installation media to perform the Proget install.

Looking forward to the conversation!

Hi,

Fashionably late here, but what @atripp said is accurate. Chocolatey's moderation process on the Chocolatey Community Repository is a completely separate process to the vulnerability management features available in ProGet.

Our moderation process was put in place shortly after the Chocolatey Community Repository went live 15 years ago, and some packages were added to the feed and haven't received updates since then.

While our moderation process is really good, and we've never seen malicious content make it to approved status, you should always detonate-test a package in your own environment before promoting it to a production repository.

In the web interface I can create an API key for all feeds by selecting all feeds from the drop down menu.

This seems to be some sort of "special" handling, as via the HTTP api or pgutil I must specify a feed name, or feed group name. Dev tools wasn't too helpful in deciphering what was going on in the calls unfortunately, so I'm a bit confused on how best to do that. In the free version they'll apply to all feeds anyway, so for my particular use case I just pick a feed and use it, but I'd still like to just say "all" :)

I would only push back slightly in that I think securing the ProGet instance is core functionality, but that's a personal opinion and nothing more.

It may be an idea to provide a callout at the top of the pages to say something like:

Available in:

* ProGet Free
* ProGet Standard
* ProGet Enterprise

(or whatever the actual product names are) :)

I'm using the free version of ProGet, where I am able to create Groups, and add users to those groups via the web UI.

When attempting to do so via the API, using pgutil or Invoke-RestMethod against the api endpoint, I get this message: ProGet Free Edition does not support this API.

The documentation does not mention this. I would argue that if I can perform an action via the web interface in the free version of the product, it stands to reason that I should be able to use the API to do the same thing.

Is anyone deploying ProGet in Azure behind an application gateway? Looking for any gotchas or guidance on doing so.

I recently published a new version of Pagootle that supports working with Asset directories, includes some other fixes, and improves the documentation.

@Jonathan-Engstrom something like this? https://steviecoaster.github.io/Pagootle/Commands/Set-ProGetSslConfig/

Hey @atripp,

Thanks for the update! We've got a lot of customers moving from Sonatype to Inedo. How many of those will use connectors is unknown. Thanks for linking to your internal issue for this. We can provide that to customers so they can see the status of the fix.

@imm0rtalsupp0rt, it would be good to provide searches across both in case of a weird difference in the URLs. (That shouldn't be the case as this is an api, but I've been staring at code long enough to know that hamsters fall off wheels in the oddest places and most inopportune times!)

We're working on putting all the data together to share :)

choco search relies on the endpoint. If you use a nuget v2 url, we'll use v2, if you use a v3 source (meaning the url ends in index.json, we'll use v3.

Hey @erich_1530,

I wrote that Chocolatey package :)

If you accept the defaults, you'll be able to access the ProGet WebUI via http://localhost:8624.

I can see some possible enhancements to the package to allow for opening of firewall ports and emitting connection info to the console upon successful installation.

I'd suggest going to the package page and following the link to the Package Source and raising those changes as a feature request and I'll get them added!

If APIs are made available for things, I'd much prefer that route and will replace using Stored Procs as I can.

As pgutil.exe matures I see this module slowly becoming a Crescendo wrapper around it.

@apxltd

Me too! I couldn't not hear it every time I talked about it, so it had to change. I stumbled across that pronunciation documentation and the lightbulb went off

I've published the initial release of my module for managing Inedo ProGet to the PowerShell gallery! Pagootle (formerly InedoOps) allows you to manage your ProGet server via PowerShell.

You can via the source code for Pagootle at https://github.com/steviecoaster/Pagootle, read the documentation at https://steviecoaster.github.io/Pagootle/, or via the release on the PowerShell gallery at https://www.powershellgallery.com/packages?q=pagootle

If you're wondering Why the name Pagootle? Well it's a play on the pronunciation of their command-line executable: pgutil.exe! See: https://docs.inedo.com/docs/proget/api/pgutil#how-is-pgutil-pronounced

In the latest version of ProGet, when creating a Chocolatey Feed via the web interface, both v2 and v3 apis are enabled by default.

However, when creating a feed via pgutil, only the v2 endpoint is enabled. For consistency, can we have v3 endpoints be enabled for Chocolatey feeds the same way they are in the web interface?

Late reply (was out at a conference), but this was in fact permissions related. I've added a check to ensure the Inedo service account has been granted modify permissions on the drop path upon creation, and it is working appropriately!

According to https://forums.inedo.com/topic/1038/drop-path-contents/4?_=1747409857938 the Drop Path folder should remove a package once it has been successfully imported into a feed.

I've configured a drop path for a chocolatey feed and the folder does not seem to be clearing of nupkg files once they are ProGet.

See:

ProGet version 2024.35 (Build 2)

Hello. Me....again.

As the title suggests, can one programmatically assign a license to ProGet itself, or must it be done through the WebUI as shown here:?:

I had a quick look through the stored procedures to see if anything jumped out, but it all seemed related to licenses tied to assets being stored in ProGet feeds, not the actual server license itself.

I'm away to play with DevTools to see if the browser points in the right direction, but figured I'd ask here as well as you'll provide a much better answer :)

Ah, that makes more sense! Yeah, Github is weird like that. I think if I provided the raw link then that right-click would have worked. Sorry for the confusion!

Well, it makes my eyes bleed

v20250407 doesn't follow any sort of semver convention that I am aware of, that looks more like a git tag (but even those usually follow at least semver 2? I'd expect this to be 2025.04.07. Perhaps they published this malformed upstream, and ProGet can't handle it?

Just a hunch :)

Thanks @dean-houston! That's good enough for me. Looking forward to trying the new migrator once it lands, sounds really really good!

Hi friends!

Firstly, I gotta say that that package migration utility you've built into Chocolatey feeds in ProGet is awesome.

That said, I'm looking to extend it. We're doing a webinar together in a few weeks and I'm looking to build some automation that not only migrates the packages, but builds the feeds as well.

I can trivially do this with PowerShell and choco.exe, but the overhead of using choco slows the process down considerably. It would just absolutely wonderful if you could provide the secret sauce that you use to get the list of packages from the source repo before you start pulling them down into the destination.

I imagine you are skipping using choco or nuget but rather using the nuget api directly, but I can't quite grep which endpoints are in play here. I can get a single package easily.

But....I need to get every package. I can craft urls once I have a list of packages that need migrated. I just can't.....get that. Help?

We can take this offline if you don't want/can't reveal the secret sauce here :)

It just occured to me that you probably only need the Set-CertPermission function. If you're just renewing a cert, everything else should be fine in your config.

You can call this on its own as well: https://github.com/steviecoaster/InedoOps/blob/main/source/private/Set-CertPermissions.ps1

The issue on windows is that the Service user running the Inedo web service doesn't have permissions to the private key on WIndows. The script can run 100% offline standalone. There are 0 references to the internet inside of it. The only way you would need the internet to use it is if you use Install-Module to install the entire InedoOps module, which you do not need to do. You could simply copy the function, and run it.

It is obviously good practice to read any code you find online before you blindly run it, but there are 0 references to the internet. Unless you are referring to the -Urls parameter. That is so you can control what port your ProGet web interface is bound too with your SSL certificate, not the internet in general.

It seems like you are dancing around the fact that this is permissions issue on the private key. This is a windows host, correct? and you are attempting to use a certificate that is inside an Windows Certificate store?

If so I urge you to try the code I linked, instead of fighting it :)

Awesome! Thanks for the quick response on this one!

Since Chocolatey CLI 2.0.0 we have added NuGet v3 support. As all the other repository vendors have deprecated NuGet v2 apis, the majority of our customers on other platforms have migrated their configuration to v3 endpoints.

It is also worth mentioning that other repository vendors don't provide an option, both v2 and v3 are just available without needing to manage configuration.

Hey @udi-moshe_0021,

My InedoOps PowerShell module has a Set-ProGetSSLConfig function that helps setups ProGet to server up content via HTTPS.

The nice thing about this particular function is that, since it doesn't interact with ProGet's web interface, but rather configuration, it can be ran standalone.

You can find the function here: https://github.com/steviecoaster/InedoOps/blob/main/source/public/Utility/Set-ProGetSSLConfig.ps1

The first example is likely the one you'll want to follow, but pay attention to the URL parameter and adjust it as needed as you'll likely want to use https://*:443/ for the value (or whatever port you typically serve SSL traffic over to ProGet).

As mentioned by @rhessinger this is likely a permissions issue on the private key, which the above handles for you.

Hope that helps!

@jipianu_mihnea_1277 said in Creating Users with Native API:

ant to use the Native API to create users and groups, but I do not know how to generate the password because I am unaware of th

Thanks for the shout-out @atripp! Yes, you can do Set-ProGetUserPassword -Credential (Get-Credential) and supply the username of the account you with to set the password, as well as the new password.

The New-ProGetUser function will do this internally for you when you pass in the credential object that function expects.

If you run into trouble, please do file an issue so I can try to fix it!

Thanks! I've gone ahead and made it public at https://github.com/steviecoaster/InedoOps. Still have a while before I put it on the Gallery, but I like developing in the open when I can!

I'm laboring on a new PowerShell module I'm tentatively calling InedoOps, which enables an administrator to administer an Inedo ProGet instance via PowerShell. It is shaping up quite nicely, though I've got quite a bit more to do before I would consider it "ready".

Would there be objections to my publishing this to the PowerShell Gallery once I'm done? Right now the code is private on my Github. If any Inedoers want to have a sneak peek, leave your Github username and I'll invite as a contributor, or if you are OK with it being flipped over to public, I can do that and share the link.

I'd really rather like a set of eyes on it from your side so you can see my approach to things and get your blessing on it. Particularly around my use of stored procedures for some things! I'm.....unsure how "stable" those are in terms of them changing in future versions, etc.

I'VE DONE IT!!! What a wild ride. I ended up using the Stored Procedures for things. Going that route did the trick nicely. Though I did have to spend the weekend learning SQL to understand exactly what the hell is going on inside of Stored Procedures haha.

But, I've now got the code I need to go from 0 to a deployed ProGet instance programmatically. Still a bit of polishing left to do, and a whole heck of a lot of testing but I am super excited about this! Thank you very much for the Stored Procedure hint!!! I very much appreciate it.

@atripp said in Manipulate users using pgutil:

tech/marketing partnership

That is above my pay grade as well to iron out he specifics but it is in my wheelhouse to push for it internally :)

My end goal is to either replace Sonatype Nexus with Inedo ProGet or at least allow the choice of repository solution included with one of our canned Environments that we offer customers here at Chocolatey.

Right now we are able to fully provision a Sonatype Nexus server via the API so that the server has

1. The necessary repositories created
2. The necessary scripts/packages stored
3. Security configured on the repositories.

Today I can get ~80% of the way there with Inedo, but until I can lock it down I can't start the work of baking it into our stuff. ProGet is the only repository in our testing that plays very very well with Chocolatey (thanks for that, btw), but without being able to natively do the security bits I'm afraid I can't move forward.

I hear you with the AD thing, but I can't guarantee AD will be available in all the environments we deploy too.

Our goal is to give them a turn-key "thing" they can be up and running with in under an hour and if they need to change things after the fact, they can work with our Support team to make those adjustments. Has worked out fairly well so far!

Are there plans to include the ability to work with user accounts via pgutil? For my use case I would like to be able to programmatically create a user account and assign it a read-only role to a specific feed such that I can configure and consume packages from the restricted feed on an endpoint. Currently there is not a way programmatically (at least that I can get to work) to do this sort of thing programmatically via PowerShell.

I've another thread on the forums which I was pulling on the HTTP api thread, but that led to a dead end as I can't craft appropriate JSON that the endpoint accepts, not for lack of trying haha.

We do have Chocolatey-AU (Automatic Updater) which will keep a version of a package up to date. Once I have everything setup it will look at whatever upstream I point at and keep the package updated for me automatically.

If you wanted to own the automation that's fine with me, but I have no problem with shoving the package source in my Chocolatey package's repository and using a Github Action to keep it updated (this is what I do today with other packages I maintain).

You've got my email, we can take this off the forums and hash out details of things privately if you prefer :)

Thanks, Alex! I have confirmed the request and have added one more person from my team as well so we have double coverage on this package.

As for the delisted packages, they won't show up for others on the community repository or via Chocolatey CLI once they are unlisted, but since you are the owner of those packages, they will continue to display on your profile. So all is right with the world there :)

If you're cool with it I may pick up packaging pgutil as well.

I've reached out via the contact maintainers link on https://community.chocolatey.org/packages/proget but figured I'd post here as well for more visibility. I'd like to publish ProGet as a Chocolatey package. I've got the automation and packaging code working how I expect it should, but I can't publish it as there is already a package available.

While I could publish it under another package id....that seems icky to me so I'd rather be added as a maintainer and then setup a pipeline to keep it updated as you folks release new versions.

Let me know if you have any questions/comments/concerns!

I'm looking to publish a Chocolatey package to the Chocolatey Community Repository which will install the Free version of Inedo ProGet.

In order to do this, I am also going to publish a package for Inedo Hub, and take a dependency. Our Community Repository requires either a LICENSE.TXT include the license terms for an application being package, or a licenseUrl listed in the Nuspec. I cannot find the Licenser terms for either product. Perhaps I am just blind! :)

Can someone point me to those terms please so that I can properly publish these packages? I greatly appreciate it!

@steviecoaster said in Question about Salt_Bytes:

Sweet mother Mary, I got it! It was the content type. I was using application/json and it wanted application/x-ww-form-urlencoded

This code works properly to set the password for a user:

function Set-ProGetUserPassword {
    [Cmdletbinding()]
    Param(
        [Parameter(Mandatory)]
        [String]
        $Username,

        [Parameter(Mandatory)]
        [SecureString]
        $OldPassword,

        [Parameter(Mandatory)]
        [SecureString]
        $NewPassword
    )

    begin {
        $confirm = Read-Host "Please re-enter your new password" -AsSecureString

        $identical = Compare-SecureString -SecureString1 $NewPassword -SecureString2 $confirm

        if (-not $identical) {
            Write-Error 'Passwords do not match!'
            break
        }
    }

    end {

        $unmanagedString = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($NewPassword)
        $plainTextPassword = [System.Runtime.InteropServices.Marshal]::PtrToStringBSTR($unmanagedString)
        [System.Runtime.InteropServices.Marshal]::ZeroFreeBSTR($unmanagedString) # Clean up
        $iterations = 10000
        $saltLength = 10
        $hashLength = 20

        $rfc2898 = [System.Security.Cryptography.Rfc2898DeriveBytes]::new($plainTextPassword, $saltLength, $iterations)
        $passwordBytes = $rfc2898.GetBytes($hashLength)
        $saltBytes = $rfc2898.Salt

        $base64Password = [System.Convert]::ToBase64String($passwordBytes)
        $base64Salt = [System.Convert]::ToBase64String($saltBytes)

        $body = @{
            User_Name = $Username
            Password_Bytes = $base64Password
            Salt_Bytes = $base64Salt
        }

        Write-Verbose $body

        $Params = @{
            Slug     = '/api/json/Users_SetPassword'
            Method   = 'POST'
            Body = $body
            ContentType = 'application/x-www-form-urlencoded'
        }

        Invoke-ProGet @Params
    }
}

Spoke to soon. This code functions and doesn't produce an error. However, the user cannot login with the credential set. More playing to do!

Sweet mother Mary, I got it! It was the content type. I was using application/json and it wanted application/x-ww-form-urlencoded

This code works properly to set the password for a user:

function Set-ProGetUserPassword {
    [Cmdletbinding()]
    Param(
        [Parameter(Mandatory)]
        [String]
        $Username,

        [Parameter(Mandatory)]
        [SecureString]
        $OldPassword,

        [Parameter(Mandatory)]
        [SecureString]
        $NewPassword
    )

    begin {
        $confirm = Read-Host "Please re-enter your new password" -AsSecureString

        $identical = Compare-SecureString -SecureString1 $NewPassword -SecureString2 $confirm

        if (-not $identical) {
            Write-Error 'Passwords do not match!'
            break
        }
    }

    end {

        $unmanagedString = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($NewPassword)
        $plainTextPassword = [System.Runtime.InteropServices.Marshal]::PtrToStringBSTR($unmanagedString)
        [System.Runtime.InteropServices.Marshal]::ZeroFreeBSTR($unmanagedString) # Clean up
        $iterations = 10000
        $saltLength = 10
        $hashLength = 20

        $rfc2898 = [System.Security.Cryptography.Rfc2898DeriveBytes]::new($plainTextPassword, $saltLength, $iterations)
        $passwordBytes = $rfc2898.GetBytes($hashLength)
        $saltBytes = $rfc2898.Salt

        $base64Password = [System.Convert]::ToBase64String($passwordBytes)
        $base64Salt = [System.Convert]::ToBase64String($saltBytes)

        $body = @{
            User_Name = $Username
            Password_Bytes = $base64Password
            Salt_Bytes = $base64Salt
        }

        Write-Verbose $body

        $Params = @{
            Slug     = '/api/json/Users_SetPassword'
            Method   = 'POST'
            Body = $body
            ContentType = 'application/x-www-form-urlencoded'
        }

        Invoke-ProGet @Params
    }
}

In my playing around yesterday, I did try to convert that to base64 and it still produced the same error. I'm very perplexed! For my use case I really need this functionality so I'm hopeful I can find a solution.

Here's what I'm using currently, but it's complaining about Salt_Bytes. I'm fairly certain this is a PowerShell problem, but more eyes on it never hurt.

function Set-ProGetUserPassword {
    [Cmdletbinding()]
    Param(
        [Parameter(Mandatory)]
        [String]
        $Username,

        [Parameter(Mandatory)]
        [SecureString]
        $OldPassword,

        [Parameter(Mandatory)]
        [SecureString]
        $NewPassword
    )

    begin {
        $confirm = Read-Host "Please re-enter your new password" -AsSecureString

        $identical = Compare-SecureString -SecureString1 $NewPassword -SecureString2 $confirm

        if(-not $identical){
            Write-Error 'Passwords do not match!'
            break
        }
    }

    end {

        $unmanagedString = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($NewPassword)
        $plainTextPassword = [System.Runtime.InteropServices.Marshal]::PtrToStringBSTR($unmanagedString)
        [System.Runtime.InteropServices.Marshal]::ZeroFreeBSTR($unmanagedString) # Clean up
        $iterations = 10000
        $saltLength = 10
        $hashLength = 20

        $rfc2898 = [System.Security.Cryptography.Rfc2898DeriveBytes]::new($plainTextPassword, $saltLength, $iterations)
        $passwordBytes = $rfc2898.GetBytes($hashLength)
        $saltBytes = $rfc2898.Salt

        $base64Password = [System.Convert]::ToBase64String($passwordBytes)

        $body = @{
            User_Name = $UserName
            Password_Bytes = $base64Password
            Salt_Bytes = $saltBytes
        }

        Write-Verbose ($body | ConvertTo-Json)

        $Params = @{
            Slug = '/api/json/Users_SetPassword'
            Method = 'POST'
            Body = $body
        }

        Invoke-ProGet @Params
    }
}