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.

[rich123]

Here is the tip of pre160 branch packed into an "executable bundle' using the above executable as the destination: gorilla-3dd07148dbe6b0bf3ae2599aad1f584a9defcedc-pre160-3dd07148dbe6b0bf3ae2599aad1f584a9defcedc-macos.zip

[acidjunk]

Made a developer ID cert in the apple account section of xcode.

DEVID can be looked up with:

security find-identity 

First attempt on sign:

codesign -s "MYDEVID" -f ./gorilla-3dd07148dbe6b0bf3ae2599aad1f584a9defcedc-pre160-3dd07148dbe6b0bf3ae2599aad1f584a9defcedc-macos

Error: main executable failed strict validation

Second attempt:

codesign --no-strict -s "MYDEVID" -f ./gorilla-3dd07148dbe6b0bf3ae2599aad1f584a9defcedc-pre160-3dd07148dbe6b0bf3ae2599aad1f584a9defcedc-macos

Error:

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate: fatal error: the 

__LINKEDIT segment does not cover the end of the file (can't be processed) in: /Users/acidjunk/Downloads/gorilla-

3dd07148dbe6b0bf3ae2599aad1f584a9defcedc-pre160-3dd07148dbe6b0bf3ae2599aad1f584a9defcedc-macos

This explains the signing process in more detail. My these: Every time when stuff is added tot the kit; it should be signed.

So I would probably need to create the kit myself; sign it, add gorilla to it and sign the final result.

[acidjunk]

Will have more time on tuesday.

[bkaradzic]

I have Password Gorilla 1.5.3.7.3 run on M1 / Monterey / 12.2.1, but after login window main window doesn't ever appear. Is this known issue?

[rich123]

Issue #190 reported a similar issue with Mojave and (I believe) an Intel based Mac. Read through the details in that issue and see if what works there also works for you.

[bkaradzic]

I think the issue is described in your last post there (Apple basically breaking something with UI lib), but I didn't see any info about work-around...

My install process is:

brew install --cask password-gorilla

xattr -d com.apple.quarantine /Applications/Password\ Gorilla.app/

[rich123]

@niallor indicated in #190 that version 1.5.3.7.2 worked with Catalina. Possibly that might work with the Arm based Mac and Monterey.

Alternately, try downloading a source archive from Github and see if the Apple installed Tcl interpreter will successfully run it. It seems a reasonable assumption that Apple made sure the Tcl interpreter they supplied with the OS actually worked with that OS version. The packaged single file blobs include an Intel CPU version of the Tcl runtime, and this might be additionally indicative of a bug in the M1's Intel emulation. I do not know of a way to create an Apple "app bundle" that uses the Apple supplied Tcl interpreter to run the Gorilla Tcl code. Note, I'm not saying there is no way, but simply that I do not know of a way.

Also, until the TclKit maintainer's release an Arm specific compilation of the Tcl runtime, I can't fix anything if this is related to running the Intel version files. And this issue is likely related to some Arm vs. Intel difference, possibly compounded by Apple's continual breaking changes in each new OS release, because nothing about the Gorilla Tcl code would simply not open any windows, as what the code does is create the appropriate window upon startup, with the assumption that the GUI libraries will in fact draw the window on screen.

[rich123]

You might also try the 1.5.3.7.2 version on the download site: https://gorilla.dp100.com/downloads/

It was reported to work with Mojave, but I am unable to test with either an Arm CPU or Monterey, so I can not say it will work with either.

[bkaradzic]

Yes, I can confirm that 1.5.3.7.2 from above works on OSX Monterey 12.2.1. Thanks!

[csonuryilmaz]

I can confirm that version 1.5.3.7.2 works on macOS Sonoma (14.4.1) 🎉

[jschuman]

Trying to get up and running on a new M3 mac running macOS Sonoma. I can get the app running but when trying to login to my database (stored in dropbox) I am getting the error:

"Can not open password database [db name]: end of file while reading header."

I can open the database just fine on an intel mac running Big Sur and on iPhone running pwSafe. Any ideas?

[rich123]

Any ideas?

When you say "open the database" do you mean the same db, while it is stored in dropbox?

If yes, try making a copy from dropbox via the intel mac to a usb flash stick of the DB. Then test on the intel mac that you can, in fact, open the db from the usb stick using the intel mac.

If that succeeds, then move the usb stick to the M3 mac, and see if it will open from the usb stick on the M3 mac. If that works (opens from USB stick) then the issue would look to be dropbox on the M3 mac having some issue.

If you get the same error trying to open a known working file on the usb stick, then that points to something odd on the M3 mac.

Are you trying to run one of the "mac specific" packages on the M3, or are you trying to run the source version on the M3? If it is one of the "mac specific" packages, this would point to some subtle issue in Apple's intel binary interpreter on the M3 mac.