Sigil-2.3.0 Released

[KevinH]

Okay, I tested using a Sigil.dmg and when downloaded from github to my Mac it sure enough had the com.apple.quarantine attribute set.

kbhend@MacBook-Pro Desktop % ls -a@l *.dmg
-rw-r--r--@ 1 kbhend staff 198173869 16 Aug 19:04 Sigil.dmg
com.apple.macl 72
com.apple.metadata:kMDItemDownloadedDate 53
com.apple.metadata:kMDItemWhereFroms 684
com.apple.quarantine 57


but worse yet, after double clicking it and copying the Sigil.app out of it, it too was marked with com.apple.quarantine and it generated that horrid error message even though it was properly signed and notarized.

So using dmg is not going to work either unless I can somehow sign and notarize an entire dmg.

Not something I want to do.

[DiapDealer]

Is Apple really so petty that they would add the quarantine attribute to anything downloaded from Github?!

[KevinH]

Originally Posted by DiapDealer

Is Apple really so petty that they would add the quarantine attribute to anything downloaded from Github?!

Yes but they are equally petty about all non-Apple external sources!

Only using curl to move the file results in a download that does not have com.apple.quarantine set.

I tried recursively trying to use xattr -d but they add it to every single file, symbolic link, directory, socket, special character block, etc. It is a real pisser to remove. Your only real chance to remove it is *before* trying to unpack the archive.

This really stinks. Why does it matter that you downloaded an archive or app from github (or anyplace) as long as the application itself inside the archive is fully signed and notarized?

Apple is truly becoming a real bastard using Fear, Uncertainty, and Doubt (FUD) to drive developers to its Mac App store.

[KevinH]

I have been reading up on this, and Apple's GateKeeper (which is what com.apple.quarantine turns on) now requires that there be no "dangling rpaths" in any place in your app but that means when macdeployqt moves the Qt frameworks in it can not just add new rpaths, it must remove the old rpaths otherwise they are considered "dangling".

Worse yet that must be true for every executable and every shared library in your app.

This is going to take lots of work to check for dangling rpaths as neither their signing process or notarization checks for that.

ARRRRGGGGGGGHHHHHHH!

[DiapDealer]

I'm finding lots of horror stories about successfully signed/notarized apps that fail (in this exact same manner) when downloading a zipped version of said "successfully" notarized apps.

But I'm also seeing stuff that indicates that distributing signed/notarized apps by zipping them up and uploading them somewhere should be possible. You might get an "unknown sources" warning, but then it should say that no malware was detected and ask if you still want to install it.

The stapled notarization might not be the notarization that's used. I'm seeing that as long as there's a network connection, the notarization may come from Apple servers. Is it possible there could be a delay between a successful notarization and that notarization being available on Apple servers. A quick test might be to disconnect your machine from the Internet and see if that forces the stapled notarization to be used.

I'm just throwing stuff out there, by the way. Most of my knowledge of these things is what I've gleaned from you!

[DiapDealer]

Originally Posted by KevinH

I have been reading up on this, and Apple's GateKeeper (which is what com.apple.quarantine turns on) now requires that there be no "dangling rpaths" in any place in your app

Which begs the question: why on earth would Apple return a successful notarization ticket on an app that can't possibly get past its own GateKeeper after downloading. Surely the notarization process should be where this sort of thing is caught?!

[KevinH]

I have no idea but after my first shot at searching for "dangling rpaths" in Sigil.app on macOS, I seem to have found them and all inside the embedded Python.framework inside site-packages:

./Sigil.app/Contents/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/PIL/.dylibs/libjpeg.62.4.0.dylib
Load command 13
          cmd LC_RPATH
      cmdsize 32
         path /usr/local/lib (offset 12)


./Sigil.app/Contents/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/PySide6/lupdate
Load command 22
          cmd LC_RPATH
      cmdsize 32
         path @loader_path/../lib (offset 12)
Load command 23
          cmd LC_RPATH
      cmdsize 32
         path @loader_path (offset 12)
Load command 24
          cmd LC_RPATH
      cmdsize 40
         path /Users/kbhend/Qt672/lib (offset 12)

./Sigil.app/Contents/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/PySide6/lrelease
Load command 20
          cmd LC_RPATH
      cmdsize 32
         path @loader_path/../lib (offset 12)
Load command 21
          cmd LC_RPATH
      cmdsize 32
         path @loader_path (offset 12)
Load command 22
          cmd LC_RPATH
      cmdsize 40
         path /Users/kbhend/Qt672/lib (offset 12)

./Sigil.app/Contents/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/PySide6/Qt/libexec/rcc
Load command 20
          cmd LC_RPATH
      cmdsize 32
         path @loader_path/../lib (offset 12)
Load command 21
          cmd LC_RPATH
      cmdsize 32
         path @loader_path (offset 12)
Load command 22
          cmd LC_RPATH
      cmdsize 40
         path /Users/kbhend/Qt672/lib (offset 12)

./Sigil.app/Contents/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/PySide6/Qt/libexec/uic
Load command 20
          cmd LC_RPATH
      cmdsize 32
         path @loader_path/../lib (offset 12)
Load command 21
          cmd LC_RPATH
      cmdsize 32
         path @loader_path (offset 12)
Load command 22
          cmd LC_RPATH
      cmdsize 40
         path /Users/kbhend/Qt672/lib (offset 12)

So the PIL package libjpeg has a hard coded rpath to /usr/local/lib.
And the PySide6 package has hard coded rpaths to the Qt libs for every one of their executables: lrelase, lupdate, rcc, and uic.

None of our code is incorrect. Just those python site packages installed by pip3.

So I am going to have to manually remove each and every one of these rpaths using otool and then hope we have no more.

[KevinH]

And of course the PIL libjpeg one is signed! And removing the rpath will break the signing.
So this will probably need to be fixed by PIL people who make the pip3 packages.

[DiapDealer]

You could cheat with PySide6 and just filter out those executables (or the whole libexec folder in PySide6) when gathering the Python pieces for your app. Will a plugin ever conceivably need to use the lrelease, lupdate, rcc, and uic executables? They won't on Windows! Because I don't deliver any of the pyside exes installed to my Python Scripts directory. I can't seem to find a libjpeg package/exe that gets installed into my Windows Python with the Pillow Module.

[KevinH]

Okay, I manually removed all of those "dangling" rpaths manually using the installname_tool and then rebuilt Sigil then signed and notarized it.

Then created a tar.xz from it and uploaded it to my BuildSigilOnMac github repo.

I then downloaded it from there, checked to verify that the com.apple.quarantine extended attribute was set.

Unpacked it and then double-clicked to run Sigil.app and this time got a different Warning Message saying that this was downloaded from the internet, and asked if a I was sure I wanted to run it. It went on to say that Apple has checked the software for malware (malicious behavior) and none was found.

So I think that is the best we are gonna get.

So the problem was the dangling rpaths made GateKeeper barf even though Sigil.app was fully code-signed and fully notarized.

So we may have a way forward without having to use curl or xattr -d.

What a pain in the ass they are making this.

They call it security but allow our embedded Python to run any code as long as it uses pure .py files which could really do something nasty but that doesn't matter because we would not want "dangling" rpaths would we ....

So insanely stupid.

I am too tired to fight with this anymore tonight. I will try to build new tar.xz packages for both PageEdit and Sigil for both x86_64 and arm64 tomorrow and use them to replace the builds that are there now. That will of course require another full dangling rpath hunt on the arm64 side since the problems will exist there as well and could impact different files given the python site-packages are different.

[odamizu]

I can confirm that both A and B methods below work on my Mac Sonoma 14.6.1.

Sigil opens with no warning or pop-up message or anything. It just opens, voilà

Originally Posted by KevinH

... So in order to prevent that noxious warning message, I need to do one of two things:

A. download with any browser and then delete the resulting "com.apple.quarantine" attribute before unpacking it:

xattr -d com.apple.quarantine Sigil.app-2.3.0-Mac-arm64.txz

OR

B. Use curl to do the download for me and allow github to do the needed relocations:

curl -L -o Sigil.app.txz https://github.com/Sigil-Ebook/Sigil...-Mac-arm64.txz

Using curl just moves the file from github to my machine and does not add any com.apple.quarantine extended attribute

Then I can just double-click on Sigil.app.txz to unpack it and then launch the resulting Sigil.app with no warning then generated.

---

So will some mac user please verify if one or both of these approaches work on their machine as I can not tell if they work only on the machine that built them or will work on any Mac. I am hoping for the latter case.