MSIX installer

[davidanthoff]

This is very much WIP, and I'll clean up the history etc. later. It also still uses the Julia artwork :) So, just not ready for anything, but if someone wants to take a look the appxmanifest.xml file and see how that is going, here it is.

[dscho]

Yes!!!

It's really good to see this come together. And thank you for adding this directly to the build-extra repository, that's exactly where I'd like these definitions to live.

[davidanthoff]

@dscho, I think this is ready to be merged for a first version. I would suggest you squash this, there are a number of silly commits in there, and I think that way we would also keep the Julia image files out of the history, right? I'll open another PR against the main repo with the workflow edits.

[dscho]

Hrm. I worked on this for a bit, and it looked as if it was going smoothly, right up until I tried to sign. No matter what I am doing, it fails with:

Done Adding Additional Store
Error information: "Error: SignerSign() failed." (-2146889723/0x80091005)
SignTool Error: An unexpected internal error has occurred.

Now, that error means CRYPT_E_UNEXPECTED_ENCODING and occurs also if I use CN=Johannes Schindelin as identity, which makes me start wondering whether signtool.exe is just utterly broken when it comes to encodings (the only way for it to receive a Unicode character is by reading it from the certificate and/or the signature, in both of which cases the encoding is actually correct).

Not sure how to continue from here.

[dscho]

Here is my WIP branch: main...dscho:msix

[dscho]

that error means CRYPT_E_UNEXPECTED_ENCODING

What a red herring!

I eventually finally found the correct place to look for error messages: the event viewer, Event Viewer (Local) > Applications and Services Logs > Microsoft > Windows > AppxPackagingOM > Microsoft-Windows-AppxPackaging/Operational. And the problem was actually not the encoding, but it was the hash algorithm. I did specify -td sha256, so naturally I thought that would be the end of this problem, but I also had to specify -fd sha256. For the record, the full command-line I used was this:

/c/Program\ Files\ \(x86\)/Windows\ Kits/10/bin/10.0.19041.0/x64/signtool.exe \
    sign -a -f certificate.p12 -p password  \
    -fd sha256 -td sha256 -tr http://timestamp.sectigo.com/?td=sha256 \
    Git-2.32.0.2.appxbundle

[dscho]

The next snag are the files/folders in /dev/. We install symbolic links stdin, stdout and stderr pointing to /proc/self/<fd>. Naturally, these must be Cygwin/MSYS2 symlinks, read: they are typically system files starting with a specific sequence. But I did not manage to bundle files in the .appx with the system file attribute, therefore they are represented by MSYS2 as plain files instead. Likewise, when I try to emulate the symlinks via Cygwin/MSYS2 .lnk files, the read-only attribute is not preserved, and again, I see the plain files, not the emulated symlinks.

Also, there appears no way to create the empty directories /dev/mqueue/ and /dev/shm/.

To fix this, we might have to patch our MSYS2 runtime to pretend that those files/directories are there, when they are actually not there. That's a bit of a bigger project than I can take on right now.

[dscho]

To fix this, we might have to patch our MSYS2 runtime to pretend that those files/directories are there, when they are actually not there.

Here are some pointers how to do that. First of all, here is a document how to build the MSYS2 runtime: https://github.com/git-for-windows/git/wiki/Building-msys2-runtime

Then, there is the question how to provide a virtual /dev/stdin and friends. This would need to imitate the way e.g. /dev/mounts is handled: https://github.com/git-for-windows/msys2-runtime/blob/12e88192b84673b81c6550e48fb7df9b607dada3/winsup/cygwin/fhandler_proc.cc#L64

Basically, we would need to augment fhandler_dev::open(), fhandler_dev::fstat() and fhandler_dev::readdir().

The biggest complication in this endeavor is that fhandler_proc extends fhandler_virtual, but fhandler_dev does not: it extends fhandler_disk_file instead.

Having said that, ROADMAP in winsup/cygwin/ says that path.cc is in charge of handling emulated files in /dev (which the symlinks stdin, stdout and stderr are not technically, they are symlinks), but I haven't had time to dig deeper yet.

[soredake]

Any progress on this?

[dscho]

The /dev/mtab and /dev/shm question is still open: https://inbox.sourceware.org/cygwin-patches/[email protected]/

We'd still need to solve for those, I think.

[dscho]

There are still too many unsolved challenges for this to work, because we'd essentially need to have ways to unzip Git for Windows without running any post-install steps, and then have a nice GUI for configuring the options that Git for Windows' installer lets you choose.

In the interest of focusing the resources Git for Windows has (which are very much finite), let's drop this PR.

@davidanthoff I am sorry for that, you put in a lot of work and effort. I'd have liked to see you rewarded for that, and if there is still any way you can get what you want, and I can accommodate that, I will.