Apple M1 and/or Big Surge compatibility?

[acidjunk]

I tried to get Gorilla running with the Mac instructions. I used the beta 1 and the beta 2: Both with kit 8.6.6 and 8.6.9.

The good news is that the app itself seems to launch OK. But when I try to open a pass file: it crashes after submitting the master password.

The console log is rather clean:

(base) acidjunk@Renes-MBP gorilla % ./tclkit-8.6.6-MacOSX-amd64-mk-tk gorilla-1.6.0-beta-1-5b3be9ba867fb4c74a3a40472931f6b4d849586b.kit 
2021-02-02 09:58:52.440 tclkit-8.6.6-MacOSX-amd64-mk-tk[79805:1425547] WARNING: <NSOpenPanel: 0x7fd85073d2a0> running implicitly; please run panels using NSSavePanel rather than NSApplication.
2021-02-02 09:59:17.960 tclkit-8.6.6-MacOSX-amd64-mk-tk[79805:1425547] Warning: Expected min height of view: (<NSButton: 0x7fd870527a40>) to be less than or equal to 30 but got a height of 32.000000. This error will be logged once per view in violation.
2021-02-02 10:00:44.463 tclkit-8.6.6-MacOSX-amd64-mk-tk[79805:1425547] Warning: Expected min height of view: (<NSButton: 0x7fd82056afe0>) to be less than or equal to 30 but got a height of 32.000000. This error will be logged once per view in violation.

Let me know if you need me to test stuff; I think I can get it running from src if needed.

[rich123]

Is the M1 the new ARM architecture Mac? If it is then it looks like you are running the Intel CPU kits (likely in an Apple provided emulator). If so it may be related to issue #206 and #196 which I thought I'd fixed in the beta1/2 code (but given your results, a similar issue may exist somewhere else).

I'd say give the source a try, if for no other reason than to compare the result. As well, if you do try the source, and it has the same result, then also try renaming the MacOS native code librarys under twofish/ and tcllib/sha256c (one at a time) to see if renaming one of them (which turns off loading them) has any effect.

One last question. Do you have another system (Mac or otherwise) that will successfully open this exact same password file? This question is aimed at the thought "is the saved file corrupt?".

The unfortunate part is, that unless I can recreate the issue here under Linux, it will be difficult to find and therefore difficult to fix.

[acidjunk]

I will try to get it running from src. I can already confirm that it's not a corrupted file (1.5.3.7 on Mac OS Catalina, opens it just fine)

[rich123]

Can you try beta2 on the Catalina Mac to see if beta2, with a different OS/CPU architecture, opens it.

If beta 2 on the Catalina aborts the same way, that points towards some change I made between 1.5.3.7 and beta 2.

If beta 2 on Catalina opens it, then that points to an issue with Apple's Intel CPU emulation on the Arm chips, and the temporary fix might be to turn off the twofish compiled extension (rename the dylib file to some other name). It will be slower running the decryption in pure Tcl, but if this was the issue it would work around the immediate block.

And if it is an emulation/extension issue, the final fix might need to wait for tclkits to be created in the Arm architecture for Macs, and then compiling a native Arm twofish extension.

[acidjunk]

I can try that this afternoon. Would its be possible to have a .kit file for 1.5.3.7.2 ?

[rich123]

Yes, very possible. I'll wrap one up later today after I'm done with my workday and put it up on the Gorilla download site.

[rich123]

Ok, that took more effort than I thought it would earlier.

It seems that zdia never actually tagged the 1.5.3.7.2 variant within the git repository, so what I thought was simply going to be a run of my buildscript, pointed at a particular commit, turned out to require more effort.

So I've split the 1.5.3.7.2 mac app bundle on the downloads area apart, filtered out the Tcl and Tk parts that were merged to make an executable, and there is now a .kit up on the PWGorilla archives page (https://gorilla.dp100.com/downloads/archive/) that is the PWGorilla specific files from the Mac bundle for 1.5.3.7.2 in the downloads section.

I tested the .kit under Linux with a tclkit executable and it launched and ran there, but I do not have a Mac with which to test to absolutely verify it indeed will run under a Mac specific tclkit executable. I expect that the success under Linux will carry over to the Mac, but I can't test and verify that.

[acidjunk]

Thanks for the effort: and hurray =>
This version works OK on M1 enabled hardware with Mac OS Surge.

./tclkit-8.6.6-MacOSX-amd64-mk-tk gorilla-15372.kit

Note: on https://gorilla.dp100.com/downloads/tclkit/ -> the names of both the links contain 8.6.6

Note2: With the 8.6.9 kit: the app seems to launch OK; but you'll get a completely transparant window; without any working GUI elements.

Let me know if you need some additional testing from me.

[rich123]

That is good news. That indicates a change somewhere between those two points is the culprit. Unfortunately, since zdia must have forgotten to tag the commit used to create the 1.5.3.7.2 variant, I can't say for certain where it started in the git history. 1.5.3.7 is tagged, so at least that is a starting point that can be used. That one was also created before I wrote the .kit generator makefile that builds a .kit and/or the architecture executables from a specific git commit entry. I suspect zdia may have done some amount of "hand assembly" for that version, further reducing the possibility of being able to recreate it from a specific git commit point.

Were you able to launch the source using Apple's provided Tcl/Tk interpreter (although I should ask first: Is Apple still bundling a Tcl/Tk interpreter on the M1 Macs)? If you can launch the source, that could make tracking down where the issue was introduced easier as you could temporarily clone the git repository locally, then use git bisect to find the commit where the issue first surfaces.

The two tclkit mac executables in the downloads area are Tcl 8.6 version kits. PWGorilla needs at least Tcl 8.5, but will run without problems within an 8.6 interpreter.

As for the blank windows, Apple has had a very bad habit of making breaking changes in their UI support libraries with major MacOS upgrades, and I believe I may have put one (or maybe both) of those executables there because at the time, those Tcl sub-versions had caught up with Apple's breakage. It sounds like they may have changed something else yet again. And if it is a UI breakage, there's nothing you or I can do about it for the Tclkit executables, the Tcl team has to play catchup in that case. The one thing that did hold on Macs was that the bundled Tcl interpreter from Apple was usually modified to work with each major OS release. But I do not think Apple ever bothered to share those modifications with the Tcl developers.

[acidjunk]

It runs ok and is stable. The only bug(?) I encountered so far -> it sometimes seems to not copy the password when I use the keycombo for that. But when I use edit, and then copy the pass from the textinput it works.

Do you know how the current official Mac OS builds are made?

I am willing to try building a Mac OS binary and sign it with my dev account. But my Tcl experience is almost zero (Python/JS/Objective C guy.)

[rich123]

Do you know how the current official Mac OS builds are made?

I build the kits with a GNUMake file that upon checking github now it seems I've omitted ever pushing over to github. So I'm going to try attaching it, and the config file template it needs, here.

build.zip

You also need the kits themselves, for the MacOS ones I let Roy Keene's kitcreator online build system create them, as I have no way to build native MacOS files: http://kitcreator.rkeene.org/fossil/index

You also need an sdx kit (https://wiki.tcl-lang.org/page/sdx) and I usually have kitcreator include "Package: metakit" and select "metakit" as the "storage system" as that always seems to work.

[acidjunk]

I did some reading and downloading. Still not sure how to do the signing. The Apple docs don't seem to mention how an Application Bundle can be signed. This is normally something that is magically done via xCode I suppose. Or maybe there exists some CLI tool that should be used after a successful run of make?

Will have some more time next week.

[acidjunk]

Reminder for self: https://developer.apple.com/library/archive/technotes/tn2206/_index.html

[rich123]

Or maybe there exists some CLI tool that should be used after a successful run of make?

This is possible, but as I have no Mac myself, I can't say that there is, or is not, a CLI signing tool. But it is reasonable to suspect one exists, if for no other reason than to be able to script builds and including 'code signing' in the script.

[acidjunk]

I tried making a build with the web editor but that seems broken, at leas for Mac OS: http://kitcreator.rkeene.org/fossil/tktview?name=160cdeec20

So I tried it with your Makefile: but when I use the pre compiled kit (from the gorilla download site); it's already unsigned before running the Makefile. So that will probably not yield a build that will work ok.

The history of the language itself is a bit overwhelming. I now understand what SDX does: but I probably have to compile my own Mac OS signed TCL kit first. I found some info regarding the codesigning as well: https://sourceforge.net/p/tcl/mailman/tcl-mac/thread/60673.97237.qm%40web57608.mail.re1.yahoo.com/#msg18862282
(there a TCL kit is mentioned that is already codesigned!)

Will have some time again, next week. I can also temporarily sponsor a AWS Mac instance if that helps.

[rich123]

That error from kitcreator appears to have been transient.

I just configured this: Description: Tcl 8.6.11, KitCreator 0.12.1, Platform macosx-amd64, Metakit-based, Threaded, Packages: mk4tcl

And the build went through and delivered the attached (purported) MacOS executable.
tclkit-8.6.11-MacOS-Amd64-Metakit-Threaded-mk4tcl.zip

Also, the 'full package' bundles are a combination of this executable, and an "archive file" (i.e., like a zip) appended to the executable, that contains the Tcl script code and other files. I would think, that for a code signing situation, that the 'signing' would need to be performed after bundling the runtime executable and the Tcl scripts together into the final package.

Signing the executable, before bundling, would seem to invalidate the signature when the executable was modified later to append the additional data. But as I don't have a Mac, and can't test this, I can't say that I know this with certainty.