Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MAUI dotnet Publish Signs msix but the exe is not Signed #13462

Closed
igalfsg opened this issue Feb 21, 2023 · 9 comments
Closed

MAUI dotnet Publish Signs msix but the exe is not Signed #13462

igalfsg opened this issue Feb 21, 2023 · 9 comments
Labels
area-publishing Issues with the app packaging/publishing process (ipk/apk/msix/trimming) platform/windows 🪟 s/needs-attention Issue has more information and needs another look t/bug Something isn't working

Comments

@igalfsg
Copy link

igalfsg commented Feb 21, 2023

Description

When running
dotnet publish -f net7.0-windows10.0.19041 -c Release /p:GenerateAppxPackageOnBuild=true /p:AppxPackageSigningEnabled=true /p:PackageCertificateThumbprint="YOURTHUMBPRINT"
the MSIX package that is created is signed. However the exe that is created to run the MAUI application is not signed, meaning that if you are running the app in elevated process the user will get the untrusted publisher notice.
MSIX
image
App when elevating (you can see the path to the exe)
image

To fix this, the exe must be signed before being packaged into the MSIX

Steps to Reproduce

  1. Clone the provided repo.
  2. Run dotnet publish -f net7.0-windows10.0.19041 -c Release /p:GenerateAppxPackageOnBuild=true /p:AppxPackageSigningEnabled=true /p:PackageCertificateThumbprint="YOURCERTTHUMBRINT"
  3. Validate that the MSIX is signed
  4. Install the application
  5. Run the application and note how it says that the exe is not signed.

Link to public reproduction project repository

https://github.com/coding-flamingo/AdminMAUI

Version with bug

7.0 (current)

Last version that worked well

7.0 (current)

Affected platforms

Windows

Affected platform versions

net6.0-windows10.0.19041

Did you find any workaround?

No response

Relevant log output

No response

@igalfsg igalfsg added the t/bug Something isn't working label Feb 21, 2023
@drasticactions
Copy link
Contributor

If you try to do this on a new WinUI 3 template application (One that doesn't use the MAUI UI code) would it do the same thing?

@jsuarezruiz jsuarezruiz added the area-publishing Issues with the app packaging/publishing process (ipk/apk/msix/trimming) label Feb 21, 2023
@igalfsg
Copy link
Author

igalfsg commented Feb 21, 2023

I don't know I just use MAUI

@jfversluis
Copy link
Member

@igalfsg we we understand, but the point of this question is to investigate where the root cause is. If we can determine that effectively then we can route this issue to the right people and come up with a solution faster.

My hunch, probably just as Tim above, is that the tool that is doing the publishing/creating the MSIX just doesn't do this and while you are using this to create a .NET MAUI app, this is not something that we control, but we're happy to help you figure out the right place to deal with this issue.

If you would be willing to try it out for a WinUI app and let us know, that would be amazing, thank you!

@jfversluis jfversluis added s/needs-info Issue needs more info from the author platform/windows 🪟 labels Feb 22, 2023
@ghost
Copy link

ghost commented Feb 22, 2023

Hi @igalfsg. We have added the "s/needs-info" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

@igalfsg
Copy link
Author

igalfsg commented Feb 22, 2023

Hi @jfversluis just did it, and your hunch is right, it is still the case that is not signed.

While I know that the next response is going to be to go ask the winUI3 team to fix this, I prefer to fix it faster, I know that you have a video on creating an exe for MAUI, is there a way to package that exe into an MSIX? or what are the MAUI system requirements that you mention that must be installed for the exe to run?

@ghost ghost added s/needs-attention Issue has more information and needs another look and removed s/needs-info Issue needs more info from the author labels Feb 22, 2023
@jfversluis
Copy link
Member

@igalfsg I don't think the right team for this would be the WinUI team. Basically we're only using the dotnet publish tool, which is independent of which UI framework is used. I don't know if MSIX for WinForms is a thing, but if it is, I'm pretty sure this would happen for them as well.

To be honest I'm a bit out of my depth here. I know you can sign your executables with SignTool and you can bundle your MSIX as you already know. But I'm not really sure how to combine the two and make that all work together.

I think that no fix is actually necessary here, it's more of a question of knowing how to do this.

@igalfsg
Copy link
Author

igalfsg commented Feb 23, 2023

Hi @jfversluis I actually disagree, it when create a package all the packages contained in that package must be signed. So if dotnet publish supports signing (which it does) it should sign all packages (that is a cybersecurity fact). So there is something to be fixed, that being said, I cannot let my user run an unsigned exe for the time it will take the publishing team to fix this, so if there is a guide on how to build an exe and bundle it, then I am happy to add the codesigning part of it and contribute it back to the project (cryptography happens to be my expertise :)).

@jfversluis
Copy link
Member

I think https://github.com/dotnet/sdk would be the right place for this. I see a few issues that seem to touch upon this subject: https://github.com/dotnet/sdk/issues?q=is%3Aissue+is%3Aopen+publish+not+signed+

From what I gather as a workaround you would want to run a build, use signtool to sign the executables and then dotnet publish with --no-build to pick up the signed executables and pack them in a signed msix.

Unfortunately there is not much we can do about this on our end, I wish I had a better answer for you. I understand that you'd want to dotnet publish command to be optimized so that it does this all in one go, the repo to discuss this is the one I linked about.

Thanks

@jfversluis jfversluis closed this as not planned Won't fix, can't repro, duplicate, stale Feb 23, 2023
@igalfsg
Copy link
Author

igalfsg commented Feb 24, 2023

thanks @jfversluis got me on a closer path, just adding here if someone has the same issue they can solve it (not the cleanest way to solve it but it gets the job done and I don't care that my build server works for an extra 10 seconds per package).

So doing what Gerald recommended, for some reason when you run dotnet publish it would replace the signed exe from the directory and pack the unsigned one it replaced it with. So instead I started googling solutions to pack my own thing and came across https://msixhero.net/, to not have to manually figure out all the dependencies what I did is run dotnet publish, then unpack the published app with msixhero, sign the APNAME.dll and APPNAME.exe then pack it with MSIXHero and sign it. Here is a quick powershell you can use to be cool like me and sign your code:

# Create Classic MSIX
dotnet build -f net7.0-windows10.0.19041.0 -c Release
dotnet publish   -f net7.0-windows10.0.19041.0 -c Release --no-build  /p:configuration=release /p:GenerateAppxPackageOnBuild=true /p:AppxPackageSigningEnabled=true /p:PackageCertificateThumbprint="YOURCertificateThumbrint"

# Unpack MSIX
msixherocli.exe unpack --directory C:\PATHTOWHEREYOUWANTTOPUTIT --package C:\PATHTOYOURMSIX\PUBLISHCREATEDMSIX.msix

# Sign EXE
SignTool sign /fd SHA256 /a /t http://timestamp.digicert.com  /n "Keytos LLC" C:\PATHTOWHEREYOUWANTTOPUTIT\APPNAME.exe
SignTool sign /fd SHA256 /a /t http://timestamp.digicert.com  /n "Keytos LLC" C:\PATHTOWHEREYOUWANTTOPUTIT\APPNAME.dll

# Pack and Sign Again
MSIXHeroCLI.exe pack -d "C:\PATHTOWHEREYOUWANTTOPUTIT" -p ".\bin\APPNAME.msix"
msixherocli.exe sign --sha1 YOURCERTTHUMBPRINTALLCAPSORITWILLFAIL --timestamp http://timestamp.digicert.com ".\bin\APPNAME.msix"

@ghost ghost locked as resolved and limited conversation to collaborators Mar 26, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-publishing Issues with the app packaging/publishing process (ipk/apk/msix/trimming) platform/windows 🪟 s/needs-attention Issue has more information and needs another look t/bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants