Make gsudo installable through winget

[IamAdiSri]

Microsoft has released their own package installer for Windows called winget. gsudo should also be added to their package list here.

I would add it myself, but there isn't an executable installer that I can link to, which is needed if you make the manifest using the WinGetYamlGenerator tool.

[gerardog]

I am waiting for microsoft/winget-cli#140 before uploading a gsudo package... because gsudo ships as a ZIP file, and I rather not maintain yet another installation method such as MSIX.

[Silvenga]

@gerardog - a bit ago I made MSI packing for gsudo for my own purposes (I use SaltStack, MSI's are easier to deploy declaratively then zips). It has MSI install gsudo.exe into the standard location and symlink to sudo.exe, plus add the directory to the path. Yay Wix!

https://github.com/Silvenga/gsudomsi

With #62 fixed, it should just work with WinGet's silent install.

I would be more the happy maintaining it as a "community supported version" until superseded by the official version.

[gerardog]

This is great news @Silvenga. All contributions are greatly appreciated.

I see you used MSI, instead of MSIX. Fine by me if it gets the job done.
You picked 'program files (x86)' folder, which means a system-wide install that requires admin privileges. That is good because most complicated flows work with that install.
A community installer won't have a digital signature, not sure at which point WinGet goes thru UAC and what will show that popup if it is not signed.

In the short term, here is my blessing to you if you want to upload your project as a 'community supported version'.

Next I will happily accept you as a contributor. I've added your installer source to this repo as an experiment in FeatureInstaller branch, next it should integrate with the current build process:
Please note gsudo has a CI build via AppVeyor... But unfortunately the official release build process (in the build folder) is just a bunch of scripts meant to be run locally. I am forced to run locally since apply the code-sign, I need the smart card app. I could sign the MSI as well.

[Silvenga]

I see you used MSI, instead of MSIX.

To my knowledge, MSIX won't work, since it requires gsudo to be ran within a sandbox, which I'm not sure will work. API calls, like to the registry hive, would be redirected to a separate hive mounted within gsudo's namespace.

program files (x86)

I assumed that was best, since .NET should work under x86/x64 swimmingly, the WOW64 compalitibly layer shouldn't be a problem.

A community installer won't have a digital signature, not sure at which point WinGet goes thru UAC and what will show that popup if it is not signed.

WinGet doesn't ever activate UAC directly. It relies on the MSI Engine to request an elevated context if MSI deems it necessary. But you're right. During install, MSI will show that yellow "this is unsigned" prompt without signatures.

In the short term, here is my blessing to you if you want to upload your project as a 'community supported version'.

Awesome!

I could sign the MSI as well.

Yeah, let's move this to a PR or something.

I'm really good with anything. I can work in-tree (if you're good with installing all the Wix dependencies when releasing) - or I can work in my repo - set up some automation to automatically rebuild when you create a release on this repo or something. I've been meaning to get some code signing certs too, since I have other Open Source MSI projects that need signing, so that's not really a problem.

Getting Wix to be happy can get a little annoying, TBH. So definitely don't want to force that on other developers 😆. I work with Wix, quite a bit, at my day job 🤷.

Let me know what you're comfortable with - in-tree or separate. MSI packaging can continue to be a "community supported" deployment, at lot of Open Source projects do that (assuming because Wix really is an acquired taste).

[gerardog]

I've already installed Wix, imported part of your project and signed one MSI locally from gsudo repo. Check the FeatureInstaller branch / compare. I was able to sign the MSI as well. Please note the code-signing certificate I bought is physically impossible to be shared.

Also note I've based the branch from dev instead of master, which has a few commits that includes 2 more files to redistribute other than 'gsudo.exe' and I wanted to test that. These files are quite experimental (issues #55 & #56) and may take a while to get released. (EDIT: I rebased from master now so I can package v0.7.3)

Let's aim only for the next gsudo release to include an .MSI installer file. Let's say that all logic to publish to winget is out of the scope of THIS repo at this point. Also it looks like you already have that working on Silvenga/gsudomsi, so maybe use that?. After gsudo oficially releases an MSI, the manifest should link that .msi from gsudo repo.

Btw, unfortunately this error came on the 2nd run:

Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor.  Action CreateSudoExeLink, location: C:\Program Files (x86)\gsudo\, command: cmd /c mklink sudo.exe "C:\Program Files (x86)\gsudo\gsudo.exe" 

Looks like mklink fails if the file already exists. Can we ignore errors on that?

[gerardog]

Try
https://github.com/gerardog/gsudo/releases/download/v0.7.3/gsudoSetup.msi

[Silvenga]

Looks like mklink fails if the file already exists. Can we ignore errors on that?

That error should not occur since the action CreateSudoExeLink is only occurring during install. Something is wonky, it shouldn't be ignored.

<Custom Action="CreateSudoExeLink" Before="InstallFinalize">NOT Installed</Custom>

My best guess is that on your computer, the MSI DB is in a bad state (common in local development when accidentally forgetting to change the product version). Make sure you completely uninstalling the MSI using the installed MSI before building a new one. This is because the product id is auto-generated.

---

• IMO, the symlink is a little flaky, since it disallows MSI's file tracking (and healing) - meaning things like repairs and rollbacks might be a little funky. It might be better to just duplicate the file twice with different names. I was kind of on the border with that one. Maybe not 100% normalized, but at least it plays nicer with MSI. What do you think?

• Let's change the UpgradeCode on this repo. Just a best practice with MSI authoring - so if our projects deverge at any point, it'll be safer. I can make a pr for that - likely tomorrow - to cleanup this repo's id's.

• Could we do this in a pr? It'll make it easier to review and I can call out best practices.
  e.g.

<!--
            <File Id="GSudoBash" KeyPath="no" Name="gsudo" Source="..\gsudo.extras\gsudo" />
            <File Id="GSudoPowerShell" KeyPath="no" Name="gsudo.ps1" Source="..\gsudo.extras\gsudo.ps1" />
-->

We should key component these things. A key for a component basically tells MSI how to repair/upgrade/etc. If "key file" is missing, it knows to install the component. But say, if the component's "key file" exists, and MSI is trying to upgrade, it won't touch any other files in the component. During repairs, MSI will look at the key file's hash in the MSI DB, to figure out of any of the components need to be update.

Think of MSI as a declarative "snapshot" of what should be. At the end of the install xyz should exist in abc. MSI goes and figures out what needs to be done based on the current system state.

[Silvenga]

Try
https://github.com/gerardog/gsudo/releases/download/v0.7.3/gsudoSetup.msi

Looks good! Want to make that the one on wget?

[gerardog]

Let's change the UpgradeCode

Agree. Merged.

We should key component these things.

Sure, I was doing an experiment. Thanks for the info.

IMO, the symlink is a little flaky since it disallows MSI's file tracking (and healing) - meaning thin/gs like repairs and rollbacks might be a little funky It might be better to just duplicate the file twice with different names. I was kind of on the border with that one. Maybe not 100% normalized, but at least it plays nicer with MSI. What do you think?

The Symlink has been problematic in many ways, but IMHO it is still the best possible sudo alias I could find. For security considerations, gsudo speaks with it's elevated instance only if it's named pipe is rooted on the same .exe file. Duplicating gsudo.exe to sudo.exe means the credentials cache would also split if you don't stick to just one gsudo/sudo alias. (To be honest It should split the credentials cache, but given it was not a supported scenario, it just fails).

Another option: To use a shim. For example kiennq/scoop-better-shimexe which seems to have addressed all the mayor shim issues. See this relevant discussion on how problematic a shim can be: ScoopInstaller/Scoop#3634. I should sign the shim. Also load time is a little bit reduced given that now sudo must load sudo.exe and then gsudo.exe...

IMHO is just easier to deal with MSI limitations. not reintroducing other problems. Lets try to bring on the best possible workaround. Can you check if the file exists and if not, execute the mklink? (For Install, Reinstall & repair).
On uninstall, what is best than 'ignore failures'?

Looks good! Want to make that the one on wget?

Yes, I do. But only after we resolve these issues.

[gerardog]

MSIX won't work, since it requires gsudo to be ran within a sandbox

I've just read MSIX Desktop Bridge and yes, it sounds like it won't work.

[davidjade]

This may not apply, but I thought I'd just point out that the new Windows Terminal is both a store app and stand alone installer from an .msixbundle file . However, it behaves like any normal desktop app and doesn't seem to have any sandbox restrictions, considering gsudo, works when called from inside the Terminal. I'm not sure how as the source (https://github.com/microsoft/terminal) doesn't look like it contains the MSIX package process, but it's clearly an app that once installed behaves like any other desktop app. And it could still be that the Terminal itself is somehow in a sandbox but the processes it runs are not. Or maybe MS has granted it special restricted store privledges. Just thought I'd mention this as it may help figure out MSIX packaging.

[Silvenga]

That is a good point. Hmmm... I wonder if the marketing exaggerates how "containerized" msix apps are... or the campatibly layer is just that good e.g. WOW64. e.g.

Apps that are packaged using MSIX run in a lightweight app container. The MSIX app process and its child processes run inside the container and are isolated using file system and registry virtualization.
[...] An MSIX app writes to its own virtual registry and application data folder, and this data will be deleted when the app is uninstalled or reset.

IMO - there aren't any benefits to using MSIX over a properly made MSI:

• The application files are effectively read-only.
• MSI tracks all it's files, and supports healing of said files.
• Uninstalls are clean of installed files.

I think the cons of using MSIX e.g. microsoft/terminal#1386 are rather large though. Plus, using MSI means that GSudo can be installed on anything Windows 7+ e.g. Windows Server 2016.

[Silvenga]

IMHO is just easier to deal with MSI limitations.

Sounds good!

Can you check if the file exists and if not, execute the mklink?
On uninstall, what is best than 'ignore failures'?

Yeah, the actions (mklink and del) are currently marked as ignored. So the MSI engine will execute it, and wait for an exit, but suppress any errors propagating and triggering a rollback of the transaction. While it is possible to check for existence, that makes things a lot more complex - since that involves running a custom action.

Is the the error blocking the install on your machine?

[gerardog]

Turns out gsudo is available in winget since Dec-26! Not sure if the PR was uploaded or inspired by you guys or if someone else found the MSI and pushed it. Anyway a nice surprise, including the fact I haven't got much complaints on the MSI after almost 400 downloads. Thanks everyone!

Is the the error blocking the install on your machine?

It works in my machine. 😉

[Silvenga]

Awesome!

(😆 wasn't me)

[gerardog]

Still, thank you @Silvenga for creating the MSI.