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/c0814aec-3f82-673b-37b7-e7b20c9c1f15@gmx.de/

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