Issues with code signature on MacOS

[navionguy]

Bug report

Program hangs on launch with Mac OS Big Sur, v11.0.1

Problem PC-BASIC v1.2.14 was installed and working with Macos v10.~

Upgraded to Big Sur, v11.0.1. Now when PC-BASIC is launched from finder, or from terminal, blank main window appears but program hangs and must be forced closed from activity monitor.

Uninstalled and re-installed with no affect.

Steps

1. Install PC-BASIC on a mac running OS version 11.0.1
2. Launch PC-BASIC

Program

Crash log No crash, just hangs

Notes

PC-BASIC version: 1.2.14 Operating system version: 11.0.1

[robhagemans]

Thanks for reporting. Unfortunately I don't have access to Big Sur so won't be able to investigate the issue myself - if anyone has access and is able to debug what's going on here, please let me know.

[navionguy]

I'll be happy to take a swing at it. Have to get setup to build/debug first so not soon. I am hoping that simply rebuilding with updated libraries may clear it. Either way, a learning adventure awaits.

Don

On Thu, Nov 26, 2020 at 9:05 AM Rob Hagemans notifications@github.com wrote:

Thanks for reporting. Unfortunately I don't have access to Big Sur so won't be able to investigate the issue myself - if anyone has access and is able to debug what's going on here, please let me know.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/robhagemans/pcbasic/issues/131#issuecomment-734316589, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADDD3FTTFCX5I6W2GLJ4LADSRZOCZANCNFSM4UDYPMKA .

[robhagemans]

Hi Don, great! Just one thing I just noted - you're using v1.2.14, could you try v2.0.3 first? I'm asking because I'm planning to retire the 1.2 branch relatively soon so it may not be worth while to debug this issue on it; it depends on some older libraries and active development has moved to the 2.0 branch. Note v2.0.3 has its own problems on macOS in that at present it only seems to run correctly from the terminal; from Finder it fails to launch.

[navionguy]

Hi Rob,

Tried 2.0.3 and it is slightly better. Instead of hanging, it starts up and then exits so at least no hanging process. I just sat down to setup my development environment. Should be interesting. I haven't done python in a few years. I'll have to dust off that corner of my brain.

Don

On Thu, Nov 26, 2020 at 10:43 AM Rob Hagemans notifications@github.com wrote:

Hi Don, great! Just one thing I just noted - you're using v1.2.14, could you try v2.0.3 first? I'm asking because I'm planning to retire the 1.2 branch relatively soon so it may not be worth while to debug this issue on it; it depends on some older libraries and active development has moved to the 2.0 branch. Note v2.0.3 has its own problems on macOS in that at present it only seems to run correctly from the terminal; from Finder it fails to launch.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/robhagemans/pcbasic/issues/131#issuecomment-734368005, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADDD3FTKLYRAK3A6XPYDL7DSRZZQ5ANCNFSM4UDYPMKA .

[robhagemans]

The latest release 2.0.4 has improvements in the Mac package and the issues of 2.0.3 were resolved on my (ancient) MacOS. Can you please try again?

[navionguy]

I'm getting an installation crash when fire up the .dmg. 2 year old macbook with the latest OS.

Process: pcbasic [468] Path: /Volumes/VOLUME/*/PC-BASIC-2.0.app/Contents/MacOS/pcbasic Identifier: PC-BASIC-2.0 Version: 0 Code Type: X86-64 (Native) Parent Process: ??? [1] Responsible: pcbasic [468] User ID: 501

Date/Time: 2021-11-09 09:23:31.255 -0500 OS Version: macOS 11.6 (20G165) Report Version: 12 Bridge OS Version: 5.5 (18P4759a) Anonymous UUID: C85138A4-C138-506D-EDC0-DCD197045CD6

Sleep/Wake UUID: FC32D5A7-7C08-4175-9434-03733A6FBC89

Time Awake Since Boot: 130000 seconds Time Since Wake: 450 seconds

System Integrity Protection: enabled

Notes: Translocated Process

Crashed Thread: 0

Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY

Termination Reason: DYLD, [0x5] Code Signature

Application Specific Information: dyld: launch, loading dependent libraries

Dyld Error Message: Library not loaded: @executable_path/lib/Python Referenced from: /Volumes/VOLUME/*/PC-BASIC-2.0.app/Contents/MacOS/pcbasic Reason: no suitable image found. Did find: /private/var/folders/sb/m6d9kb_92tx7sdmyjwnmhcb00000gn/T/AppTranslocation/892B5D3E-A13E-4226-909A-408309045A68/d/PC-BASIC-2.0.app/Contents/MacOS/lib/Python: code signature invalid for '/private/var/folders/sb/m6d9kb_92tx7sdmyjwnmhcb00000gn/T/AppTranslocation/892B5D3E-A13E-4226-909A-408309045A68/d/PC-BASIC-2.0.app/Contents/MacOS/lib/Python'

/private/var/folders/sb/m6d9kb_92tx7sdmyjwnmhcb00000gn/T/AppTranslocation/892B5D3E-A13E-4226-909A-408309045A68/d/PC-BASIC-2.0.app/Contents/MacOS/lib/Python: stat() failed with errno=1 /private/var/folders/sb/m6d9kb_92tx7sdmyjwnmhcb00000gn/T/AppTranslocation/892B5D3E-A13E-4226-909A-408309045A68/d/PC-BASIC-2.0.app/Contents/MacOS/lib/Python: code signature invalid for '/private/var/folders/sb/m6d9kb_92tx7sdmyjw

Binary Images: 0x10f309000 - 0x10f30afff +PC-BASIC-2.0 (0)

<29F21A7F-09D0-3B37-99F8-C4662C015A4A> /var/folders/*/PC-BASIC-2.0.app/Contents/MacOS/pcbasic 0x117fc1000 - 0x11805cfff dyld (852.2) <0CC19410-FD43-39AE-A32A-50273F8303A4> /usr/lib/dyld Model: MacBookPro15,1, BootROM 1554.140.20.0.0 (iBridge: 18.16.14759.0.1,0), 8 processors, 8-Core Intel Core i9, 2.3 GHz, 16 GB, SMC Graphics: kHW_IntelUHDGraphics630Item, Intel UHD Graphics 630, spdisplays_builtin Graphics: kHW_AMDRadeonPro560XItem, Radeon Pro 560X, spdisplays_pcie_device, 4 GB Memory Module: BANK 0/ChannelA-DIMM0, 8 GB, DDR4, 2400 MHz, SK Hynix, - Memory Module: BANK 2/ChannelB-DIMM0, 8 GB, DDR4, 2400 MHz, SK Hynix, - AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x7BF), wl0: Aug 10 2021 19:55:28 version 9.30.444.18.32.5.71 FWID 01-93db3422 Bluetooth: Version 8.0.5d7, 3 services, 27 devices, 1 incoming serial ports Network Service: Wi-Fi, AirPort, en0 USB Device: USB 3.1 Bus USB Device: USB-C dongle USB Device: USB2.0 Hub USB Device: Hub USB Device: Hub USB Device: USB2.0 Hub USB Device: Matias Keyboard USB Device: KVM PORT SWITCH USB Device: USB Multimedia Keyboard USB Device: USB Receiver USB Device: Wired Keyboard 600 USB Device: Apple T2 Bus USB Device: Touch Bar Backlight USB Device: Touch Bar Display USB Device: Apple Internal Keyboard / Trackpad USB Device: Headset USB Device: Ambient Light Sensor USB Device: FaceTime HD Camera (Built-in) USB Device: Apple T2 Controller Thunderbolt Bus: MacBook Pro, Apple Inc., 47.5 Thunderbolt Bus: MacBook Pro, Apple Inc., 47.5 On Mon, Nov 8, 2021 at 4:22 PM Rob Hagemans ***@***.***> wrote: > The latest release 2.0.4 has improvements in the Mac package and the > issues of 2.0.3 were resolved on my (ancient) MacOS. Can you please try > again? > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > , > or unsubscribe > > . >

[robhagemans]

Thanks for trying. Unfortunately I have no idea. Please use the Pip install to use PC BASIC going forward.

I think I will give up on trying to release for MacOS as all this is taking too much time and Apple and its OS are simply hostile to cross platform development, so I will focus on Linux and Windows only.

Open call: if someone is willing to step up as Mac package maintainer and continue releases for this platform, please contact me.

On Wed, 10 Nov 2021, 12:34 Don Hinds, @.***> wrote:

I'm getting an installation crash when fire up the .dmg. 2 year old macbook with the latest OS.

Process: pcbasic [468] Path: /Volumes/VOLUME/*/PC-BASIC-2.0.app/Contents/MacOS/pcbasic Identifier: PC-BASIC-2.0 Version: 0 Code Type: X86-64 (Native) Parent Process: ??? [1] Responsible: pcbasic [468] User ID: 501

Date/Time: 2021-11-09 09:23:31.255 -0500 OS Version: macOS 11.6 (20G165) Report Version: 12 Bridge OS Version: 5.5 (18P4759a) Anonymous UUID: C85138A4-C138-506D-EDC0-DCD197045CD6

Sleep/Wake UUID: FC32D5A7-7C08-4175-9434-03733A6FBC89

Time Awake Since Boot: 130000 seconds Time Since Wake: 450 seconds

System Integrity Protection: enabled

Notes: Translocated Process

Crashed Thread: 0

Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY

Termination Reason: DYLD, [0x5] Code Signature

Application Specific Information: dyld: launch, loading dependent libraries

Dyld Error Message: Library not loaded: @executable_path/lib/Python Referenced from: /Volumes/VOLUME/*/PC-BASIC-2.0.app/Contents/MacOS/pcbasic Reason: no suitable image found. Did find:

/private/var/folders/sb/m6d9kb_92tx7sdmyjwnmhcb00000gn/T/AppTranslocation/892B5D3E-A13E-4226-909A-408309045A68/d/PC-BASIC-2.0.app/Contents/MacOS/lib/Python: code signature invalid for

'/private/var/folders/sb/m6d9kb_92tx7sdmyjwnmhcb00000gn/T/AppTranslocation/892B5D3E-A13E-4226-909A-408309045A68/d/PC-BASIC-2.0.app/Contents/MacOS/lib/Python'

/private/var/folders/sb/m6d9kb_92tx7sdmyjwnmhcb00000gn/T/AppTranslocation/892B5D3E-A13E-4226-909A-408309045A68/d/PC-BASIC-2.0.app/Contents/MacOS/lib/Python: stat() failed with errno=1

/private/var/folders/sb/m6d9kb_92tx7sdmyjwnmhcb00000gn/T/AppTranslocation/892B5D3E-A13E-4226-909A-408309045A68/d/PC-BASIC-2.0.app/Contents/MacOS/lib/Python: code signature invalid for '/private/var/folders/sb/m6d9kb_92tx7sdmyjw

Binary Images: 0x10f309000 - 0x10f30afff +PC-BASIC-2.0 (0)

<29F21A7F-09D0-3B37-99F8-C4662C015A4A> /var/folders/*/PC-BASIC-2.0.app/Contents/MacOS/pcbasic 0x117fc1000 - 0x11805cfff dyld (852.2) <0CC19410-FD43-39AE-A32A-50273F8303A4> /usr/lib/dyld Model: MacBookPro15,1, BootROM 1554.140.20.0.0 (iBridge: 18.16.14759.0.1,0), 8 processors, 8-Core Intel Core i9, 2.3 GHz, 16 GB, SMC Graphics: kHW_IntelUHDGraphics630Item, Intel UHD Graphics 630, spdisplays_builtin Graphics: kHW_AMDRadeonPro560XItem, Radeon Pro 560X, spdisplays_pcie_device, 4 GB Memory Module: BANK 0/ChannelA-DIMM0, 8 GB, DDR4, 2400 MHz, SK Hynix, - Memory Module: BANK 2/ChannelB-DIMM0, 8 GB, DDR4, 2400 MHz, SK Hynix, - AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x7BF), wl0: Aug 10 2021 19:55:28 version 9.30.444.18.32.5.71 FWID 01-93db3422 Bluetooth: Version 8.0.5d7, 3 services, 27 devices, 1 incoming serial ports Network Service: Wi-Fi, AirPort, en0 USB Device: USB 3.1 Bus USB Device: USB-C dongle USB Device: USB2.0 Hub USB Device: Hub USB Device: Hub USB Device: USB2.0 Hub USB Device: Matias Keyboard USB Device: KVM PORT SWITCH USB Device: USB Multimedia Keyboard USB Device: USB Receiver USB Device: Wired Keyboard 600 USB Device: Apple T2 Bus USB Device: Touch Bar Backlight USB Device: Touch Bar Display USB Device: Apple Internal Keyboard / Trackpad USB Device: Headset USB Device: Ambient Light Sensor USB Device: FaceTime HD Camera (Built-in) USB Device: Apple T2 Controller Thunderbolt Bus: MacBook Pro, Apple Inc., 47.5 Thunderbolt Bus: MacBook Pro, Apple Inc., 47.5 On Mon, Nov 8, 2021 at 4:22 PM Rob Hagemans ***@***.***> wrote: > The latest release 2.0.4 has improvements in the Mac package and the > issues of 2.0.3 were resolved on my (ancient) MacOS. Can you please try > again? > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > < https://github.com/robhagemans/pcbasic/issues/131#issuecomment-963586480>, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/ADDD3FXQOFTADVZIUQCOKSLULA5RDANCNFSM4UDYPMKA > > . > — You are receiving this because you commented. Reply to this email directly, view it on GitHub , or unsubscribe . Triage notifications on the go with GitHub Mobile for iOS or Android .

[robhagemans]

Actually, isn't this something you can avoid by setting your Mac to accept unsigned apps?

This kind of thing: https://www.wikihow.com/Install-Software-from-Unsigned-Developers-on-a-Mac

I hope this still works on the latest MacOS, because if not there is nothing I can do but stop building a Mac distribution.

[incanus]

I'm getting "corruption" problems with 2.0.5 and now, even the once-working 2.0.4 last release won't launch on my 12.5 machine since the system Python 2 was removed and I think that changed even the behavior of Python 3 somehow.

I believe I wrote you by email @robhagemans, and I still can't promise anything, but I'd love to try to find the time to help. I have the expertise (though I am just as frustrated at some aspects of dev on Mac).

What would help me is: could folks chime in if they want the Mac version? I'd love to gauge interest (beyond my own, of course).

[navionguy]

I use the Mac version on the regular but currently on vacation. Don’t know python much at all but do software on macs all the time.

Happy to help next week. Tried to download the latest version last week but got the corrupt message.

On Jul 21, 2022, at 19:40, Justin R. Miller @.***> wrote:

 I'm getting "corruption" problems with 2.0.5 and now, even the once-working 2.0.4 last release won't launch on my 12.5 machine since the system Python 2 was removed and I think that changed even the behavior of Python 3 somehow.

I believe I wrote you by email @robhagemans, and I still can't promise anything, but I'd love to try to find the time to help. I have the expertise (though I am just as frustrated at some aspects of dev on Mac).

What would help me is: could folks chime in if they want the Mac version? I'd love to gauge interest (beyond my own, of course).

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.

[robhagemans]

Thanks guys! Label for build issues is a good idea, might even have separate ones per platform.

I intend to add some write up on the packaging process in BUILD.md, but meanwhile the gist is: you need a clone of the repo and all the prerequisites in BUILD.md. The packaging process uses cx-Freeze at the core, in principle it's a matter of running python3 -m packaging from the repo root and all goes automatically.

The package contains a full python distribution so should not depend on what is installed on the Mac. However, the issues you point out may be caused by libraries python depends on which may have been removed. I thought 2.0.4 package used Python3 not Python2 however, but maybe I got that wrong.

[incanus]

Some research here and notes for others possibly digging into it...

I wanted to test a simple "ad-hoc" code signing first before getting into any "official" signing just as a benchmark. It has drawbacks, but I thought it best to start simple; we don't have to necessarily ship that way.

This can be accomplished as follows on a built app bundle:

$ codesign --force --deep -s - PC-BASIC-2.0.app

• --force: replace any existing signature
• --deep: nested code like frameworks should also be signed
• -s -: sign with identity -, which is ad-hoc (see man codesign)

This appears to succeed, as well as verify again using codesign:

$ codesign -vv PC-BASIC-2.0.app
PC-BASIC-2.0.app/: valid on disk
PC-BASIC-2.0.app/: satisfies its Designated Requirement

However, spctl (the security policy tool) fails to recognize things:

$ spctl --assess --verbose PC-BASIC-2.0.app
PC-BASIC-2.0.app/: rejected

Digging a bit, this seems to be because the various .dylib and .so files are in the /Contents/MacOS folder alongside the pcbasic binary, instead of in /Contents/Frameworks.

This is corroborated here by Quinn, a longtime Apple dev relations celebrity, and in the macOS Code Signing In Depth documentation about Nested Code.

I'm starting to look at packaging/mac.py now, but @robhagemans you may have a better idea of how to possibly put things in the proper places faster than I.

[incanus]

More on ad hoc signing, particularly on Apple Silicon:

https://wiki.lazarus.freepascal.org/Code_Signing_for_macOS#Ad_hoc_signing

This is especially important on ARM64 M1 Apple processors which require all native code to be validly signed (if only ad hoc) or the operating system will not execute it, instead killing it on launch.

[robhagemans]

@incanus - thanks! I wasn't aware of "ad hoc signing", it may be enough to resolve the issues? Personally when researching code signing I stopped at the membership to the Apple developer programme, asking me to pay ransom^h^h^h^h^h^h tax^h^h^h a membership fee...

If ad hoc signing can generate a keystring like I think regular signing needs, it may be possible to use it with cx_Freeze directly. It does have support for code signing built in and it generates the app and dmg anyway.

See here: https://cx-freeze.readthedocs.io/en/latest/setup_script.html?highlight=codesign#cmdoption-arg-codesign_deep

[robhagemans]

I've tried to include ad hoc signing in a new branch, see https://github.com/robhagemans/pcbasic/tree/packaging-fixes It's based on the guess that I can use - as the identity in cx_freeze as well.

@incanus could you give this a try please? You should be able to start the DMG build with python3 -m packaging on your Mac.

I've also rearranged things so that it now relies on https://pypi.org/project/pysdl2-dll/ to provide the SDL2 binaries and no longer includes them directly. From what I gather, their latest version should include MacOS universal binaries.

So to build locally, you'd first need pip3 install pysdl2-dll pyserial and then run the packaging command. Alternatively, first build a wheel locally with python3 -m packaging bdist_wheel and install that, it will pull in the dependencies.

[incanus]

@incanus could you give this a try please? You should be able to start the DMG build with python3 -m packaging on your Mac.

I'll dig more into this, but two notes:

1. Should be _ not - in the codesign_identity and codesign_deep directives.

2. Fails out after build with:

   build/PC-BASIC-2.0.app: is already signed
   error: Code signing of app bundle failed

   Probably needs some sort of --force option like the direct command line, but I don't see it offhand in the docs.

[robhagemans]

Hmm maybe the codesign options should go under bdist_dmg instead of bdist_mac? The docs certainly say they go under bdist_mac, but who knows...

[robhagemans]

OK, new try - I've pushed (a lot of) updates to packaging-fixes and a few more that make the build much simpler, to packaging-new-no-setuppy.

All this fixes some issues with the dlls and circumvents the "app already signed" problem by using Apple's own codesign tool instead of cx_Freeze. This now runs, on my 10.9 Mavericks virtual install - not sure if it resolves anyone's issues though.

Freezing takes the binaries from the host system, so for this to work on Apple Silicon, someone will need to build the package on a machine with at least macOS 11 Big Sur and universal binaries for Python and everything else. Unfortunately I have so far not been able to gain access to that version.

[robhagemans]

Oh and by the way, I had to change the name of the packaging package to make, as it clashes with newer versions of setuptools or distutils or something, that break if you use the name packaging.

So to build the package it's now python3.7 -m make.

[robhagemans]

Progress update: I managed to get a virtual Big Sur running using this thing: https://github.com/sickcodes/Docker-OSX It's a macOS, wrapped in a QEMU, inside a docker container. A bit clunky, but amazingly it works, unlike VirtualBox.

Big Sur supports ARM and universal binaries so that's promising, and indeed Python3.10 from python.org is universal.

Initially SDL2 crashed dereferencing a null pointer (i.e. an error code I don't catch) but that was resolved by adding a hint about framebuffer acceleration and OpenGL. I think this means it was looking for hardware acceleration, couldn't find it and gave up, and the hint convinces it to use software instead. It may be specific to the QEMU setup, but the hint doesn't seem to hurt elsewhere.

So now everything works on Big Sur and the packaged end result runs locally. But disappointingly the main entry point in the app is still x86_64 only, per lipo -archs. Which means that that binary won't run on Apple Silicon.

I'm not sure why that is, as far as I can see every other bundled library and binary is x86_64 arm64. At this point I'm inclined to think it's a bug in cx_Freeze so looking into where it may be doing something Intel-only.

@incanus - if you have the time, could you try again on your setup? This needs branch packaging-new-no-setuppy and python3.10 -m make. Other Pythons may work too, so long as they have universal binaries.

[robhagemans]

And this may well be the root cause...

rob@bigsur ~ % lipo -archs /Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/cx_Freeze/bases/Console-cpython-310-darwin
x86_64

[robhagemans]

Turns out cx_Freeze publish a universal wheel on pyPI, but pip picks up the Intel one instead. So downloading manually from https://files.pythonhosted.org/packages/96/20/24cb687426893c3b029ebc93cd421030cb7fa1db9bc0922537131ff847b7/cx_Freeze-6.11.1-cp310-cp310-macosx_10_9_universal2.whl and installing with `pip install ./cx_Freeze-6.11.1-cp310-cp310-macosx_10_9_universal2.whl' does the trick!

Now to try the end result on an ARM Mac...

[robhagemans]

Please check if release 2.0.6 has resolved the issue. This bundle reports in codesign as correctly (if ad-hoc) signed, and in lipo as suitable for both Mac architectures.

[incanus]

Version 2.0.6 looks great on my Apple Silicon! I didn't get into any of the building of the project, but I successfully ran:

• ./run-pcbasic.py in a checked-out working copy
• pip install pcbasic && pcbasic
• Right-click opening (and confirming running) the GUI app from the .dmg in Finder

@robhagemans I would say that all of your work has paid off. The binary on the .dmg is also shown as Universal, but I have yet to try it on my Intel Big Sur machine. When I do, I will report definitively, but it would be pretty ironic (though not impossible) for a problem to crop up there.

Thanks again! 💪

[robhagemans]

Thanks @incanus, that's awesome, thanks for the testing and help!

Let's see on the Intel machine, but I also don't expect to see new issues there - if anything, the .dmg was built on an intel architecture and ran there. Though of course running locally doesn't necessarily imply no problems running on another machine, especially with all the codesigning hoo-ha

[incanus]

No issues on the Intel, all three methods mentioned above work well there, too.

[incanus]

Wow, talk about ironic timing — just saw this:

https://gregoryszorc.com/blog/2022/08/08/achieving-a-completely-open-source-implementation-of-apple-code-signing-and-notarization/

I'm very excited to announce that we now have a pure Rust implementation of a client for Apple's Notary API in the apple-codesign crate. This means we can now notarize Apple software from any machine where you can get the Rust crate to compile.

[robhagemans]

Thanks for the link - tbh you'd still need a Big Sur machine to build the package, as cx-Freeze doesn't "cross compile" packages.

I suppose it would in theory be possible, maybe using a binary distribution package from python.org for each target architecture and picking the libraries you need from there, much in the way cx-Freeze and its colleagues do it for the host architecture using the installed Python library and a precompiled interpreter executable. Difficulty would be finding anyone to test and support such a solution...

On Tue, 9 Aug 2022, 00:29 Justin R. Miller, @.***> wrote:

Wow, talk about ironic timing — just saw this:

https://gregoryszorc.com/blog/2022/08/08/achieving-a-completely-open-source-implementation-of-apple-code-signing-and-notarization/

I'm very excited to announce that we now have a pure Rust implementation of a client for Apple's Notary API in the apple-codesign crate. This means we can now notarize Apple software from any machine where you can get the Rust crate to compile.

— Reply to this email directly, view it on GitHub https://github.com/robhagemans/pcbasic/issues/131#issuecomment-1208722251, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB25RESGBBZFQ2QH57WFFW3VYGJ3XANCNFSM4UDYPMKA . You are receiving this because you were mentioned.Message ID: @.***>

[incanus]

Yeah, I figured it would be a stretch, but I thought it was interesting that such a signing breakthrough had been made. I'm glad the current toolchain seems to work though!

[robhagemans]

Resolved as tested by @incanus