Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

iaito_5.9.2_m1.dmg is not working #170

Open
a-levra opened this issue May 24, 2024 · 36 comments · May be fixed by #209
Open

iaito_5.9.2_m1.dmg is not working #170

a-levra opened this issue May 24, 2024 · 36 comments · May be fixed by #209

Comments

@a-levra
Copy link

a-levra commented May 24, 2024

Environment

Chip : Apple m2 pro
OS : Sonoma 14.0

Description

I downloaded iaito_5.9.2_m1.dmg

On opening the downloaded .dmg file, i got :

Screenshot 2024-05-24 at 18 51 05
@a-levra a-levra changed the title iaito m1.dmg is not working iaito_5.9.2_m1.dmg is not working May 24, 2024
@a-levra
Copy link
Author

a-levra commented May 24, 2024

The name of the release is also a bit confusing (unless this means it only supports m1 and no other chips).
Maybe name it iaito_5.9.2_arm64.dmg, or even iaito_5.9.2_apple_silicon.dmg ?

@trufae
Copy link
Collaborator

trufae commented May 25, 2024

Works for me. Do you have r2 installed? Try running it from the shell and see whats the error

@a-levra
Copy link
Author

a-levra commented May 25, 2024

On Iaito 5.9.2 releases notes, there's :

Build from Source

curl -sL https://github.com/radareorg/iaito/releases/download/5.9.2/5.9.2.tar.gz | tar xzv
iaito-5.9.2/sys/install.sh 



But https://github.com/radareorg/iaito/releases/download/5.9.2/5.9.2.tar.gz does not seem to exist.

Here's what I tried :

git clone https://github.com/radareorg/iaito.git
cd iaito
./configure
make

the end of the build indicates :
ld: warning: search path '/usr/local/opt/qt@5/lib' not found

even though I had qt@5 which seems to be installed :

brew install qt@5
[...]
Warning: qt@5 5.15.13_1 is already installed and up-to-date. 

And exported to path via : echo 'export PATH="/opt/homebrew/opt/qt@5/bin:$PATH"' >> ~/.profile
Anyway,
executing make run successfully launched Iaito, but the .dmg that was downloaded from the 5.9.2 release and mounted still had an issue (interesting enough, with a different error message):

 open /Volumes/iaito/iaito.app
The application cannot be opened for an unexpected reason, error=Error Domain=NSOSStatusErrorDomain Code=-10661 "(null)" UserInfo={_LSLine=4106, _LSFunction=_LSOpenStuffCallLocal}

Double-clicking on the .dmg made the following pop up :
Screenshot 2024-05-25 at 14 29 08

TLDR :
It works via the Makefile, but still not via the .dmg

@Kyle-Ye
Copy link

Kyle-Ye commented Jul 1, 2024

The 5.9.2._m1.dmg can be unzipped and installed to my /Application/ folder.

But when I open it, it will crash due to some signature issue.

image

Env: macOS 14.5 (23F79)

Here is the script I use to re-codesign everything to workaround it.

#!/bin/bash

APP_PATH="/Applications/iaito.app"
IDENTITY="-"  # Replace "-" with your actual identity if needed

# Sign all the nested frameworks, libraries, and executables
find "$APP_PATH" -type f \( -name "*.dylib" -or -name "*.so" -or -name "*.framework" -or -perm +111 \) -exec codesign --deep --force --options=runtime --sign "$IDENTITY" {} \;

# Sign the main application bundle
codesign --deep --force --options=runtime --sign "$IDENTITY" "$APP_PATH"

@trufae
Copy link
Collaborator

trufae commented Jul 1, 2024

Any idea how to run this script in the ci? I will probably need to push my key somewhere but its not clear to me the way to go

@Kyle-Ye
Copy link

Kyle-Ye commented Jul 1, 2024

Any idea how to run this script in the ci? I will probably need to push my key somewhere but its not clear to me the way to go

You can use GitHub secret to upload your p12 keychain. And then import it to your workflow.

Some article I found on the Internet may help you here.

@Kyle-Ye
Copy link

Kyle-Ye commented Jul 1, 2024

Any idea how to run this script in the ci?

BTW, What do you mean of running the script in the CI?

It is intended to be a temporary local re code sign solution to fix the upstream releasing bug.

If you are the author of the app and is working on a fix to it, there is probably some easier way to do it. (Properly code signing it right after building)

@trufae
Copy link
Collaborator

trufae commented Jul 2, 2024

Thanks for pointing out the links, yes i'm the only maintainer and developer here, just busy so i appreciate you pointing to the link.i'll try to setup the proper signing in the CI before cutting a new release

@chinmuzic
Copy link

chinmuzic commented Aug 12, 2024

Thanks @a-levra! I had this same issue with iaito 5.9.4.

Enviroment

Chip: Apple M3 Max
OS: Sonoma 14.6.1

Make a working app

I was able to get a working app by using the makefile in the macos folder.

For anyone that just wants the app file, run this instead.

git clone https://github.com/radareorg/iaito.git
cd iaito/dist/macos
make app

It will make a zip file in the macos folder with the app in it. Then just move the app to the applications folder.

@ac0d3r
Copy link

ac0d3r commented Aug 28, 2024

My solution is to re-sign

$ xattr -rc /Applications/iaito.app
$ codesign --force --deep --sign - /Applications/iaito.app

@trufae
Copy link
Collaborator

trufae commented Aug 28, 2024

@ac0d3r your solution works for me, so ive updated the readme in the release page to share those instructions. The only thing i changed is that xattr -r doesnt exist. But just doing -c is enough to work for me.

Screenshot 2024-08-28 at 10 53 43

@tanis2000
Copy link

tanis2000 commented Oct 24, 2024

Even replacing the signature does not make it work for me. It does seem to start but then it crashes with the following error:

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

Termination Reason:    Namespace DYLD, Code 1 Library missing
Library not loaded: /usr/local/lib/libr_reg.dylib
Referenced from: <EBA85510-AC4A-379A-9B72-169A792DAF24> /Applications/iaito.app/Contents/Frameworks/libr_egg.dylib
Reason: tried: '/usr/local/lib/libr_reg.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/usr/local/lib/libr_reg.dylib' (no such file), '/usr/local/lib/libr_reg.dylib' (no such file)
(terminated at launch; ignore backtrace)

I can't understand why it is not looking into its own Framework folder, though... libr_reg.dylib is inside there.

@trufae
Copy link
Collaborator

trufae commented Oct 24, 2024

You need to install r2 separately

@tanis2000
Copy link

You need to install r2 separately

I do have r2 installed separately, but on Apple Silicon the path to shared libraries installed with homebrew is not /usr/local/lib but /opt/homebrew/lib.

You should not hardcode the path of shared libraries as it is different between x64 and ARM.

@SoCuul
Copy link

SoCuul commented Dec 14, 2024

@trufae in /src/Iaito.pro you're hardcoding the library paths to /usr/local which is extremely problematic, as libraries are installed to /opt/homebrew on apple silicon machines.

This makes it essentially impossible to run (or build) currently, as it cannot find any of the required libraries.

@trufae
Copy link
Collaborator

trufae commented Dec 14, 2024

What would you suggest to do?

@SoCuul
Copy link

SoCuul commented Dec 15, 2024

I would say, in every case where /usr/local is hardcoded, it should check for the existence of /usr/local and /opt/homebrew and pick the "better" option based on the current architecture, falling back to the other if errored.

The easiest fix however, would just be to swap out /usr/local with /opt/homebrew if the CPU architecture is darwin arm64. In this case, an override via a make flag (or something of that sort) could be useful as well to bypass the architecture-based directory selection, and force your own path that the binaries are installed to.

@trufae
Copy link
Collaborator

trufae commented Dec 15, 2024

That would be a problem for everyone installing r2 from source. Like me for example. Maybe a shellscript wrapping some env vars may be a better solution and avoid hardcoding any path?

@SoCuul
Copy link

SoCuul commented Dec 15, 2024

Yeah, that would probably be the best solution. Search through multiple paths (usrlocalbin/opthomebrew) and find the best one (or use one explicitly provided by the user).

@trufae
Copy link
Collaborator

trufae commented Dec 17, 2024

can you submit a PR with the fix and try it in your environment? im a little busy in so many other fronts right now and i will probably take more time to go there. maybe @prodrigestivill can take a look too. thanks!

hopefully that should be the last frontier before closing this ticket

@prodrigestivill
Copy link
Collaborator

prodrigestivill commented Dec 29, 2024

For what I understand there are 3 things here.

  1. Signing the macos binary:
    a. Uploading the signing key to GitHub Actions Secrets and sign the mac app on each release.
    b. Update the main project README or releases notes to include the process.
    c. Append a README file in the DMG to (similar to SuperDude88/TWWHD-Randomizer@2a3cc10).

  2. Renaming the dmg names from m1 to arm64
    This can be done easily if it causes some confusion.
    (Rename m1 to arm64 for mac builds radare2#23845, Rename m1 to arm64 for mac builds #206)

  3. Homebrew installation paths

Currently the official dmg build is intended work with the official radare2 build (the .pkg file from their releases page) and both use /usr/local prefix for both architectures.
This path is configurable at build time and currently is working in the CI on both architectures.

Homebrew team have decided some time ago to split the prefix depending on the platform in order to be able to mix x64 and arm64 installs in the same machine.
So both paths can get used on arm64 machines by homebrew, but also /usr/local is used by other official packages (like docker or rancher desktop, etc...).

Since there are no homebrew formula of radare2 nor iaito I don't see any need to use /opt/homebrew as a prefix for those installs since I believe it should be restricted their usage for homebrew managed apps.

@tanis2000,@SoCuul: Regarding detecting radare2 installation or any compilation problems using the default /usr/local prefix, can you please detail more what errors do you find? is it trying to load the x64 version of a library instead of the arm64?

This path should only be used to locate radare2 libraries as an extra place to lookup. This is because for mac builds since 2023 dyld will not look for libraries into any folder by default unless specified as rpath or DYLD_FALLBACK_LIBRARY_PATH env var, as exposed in their man page:

For new binaries (Fall 2023 or later) there is no default.
For older binaries, there is a default fallback search path of: /usr/local/lib:/usr/lib.

@tanis2000
Copy link

@prodrigestivill I can't say whether it is trying to load the x64 version of the libraries or if it is just that someone set the arm64 path to the same location as the x64 ones. What I can tell you for sure is that it tries to look into /usr/local/lib on an Apple Silicon (armn64) box, while it should actually look for the arm64 ones in /opt/homebrew/lib which is the default path that homebrew adopted for arm64 libraries.

@SoCuul
Copy link

SoCuul commented Dec 30, 2024

I agree with @tanis2000. A possible workaround is to symlink each binary to /usr/local/lib, but that's not a reasonable solution for most users. A good 90% of macOS developers will be using homebrew as their package manager, and not being compatible with apple silicon macs using hb is affecting (and will increasily affect) developers.

@prodrigestivill
Copy link
Collaborator

@SoCuul I don't follow the issue you are comenting...

Can you detail what binaries are you proposing to symlink to /usr/local/lib as a workarround?
Maybe with this infromation I can follow you better.

Thanks in advance

@tanis2000
Copy link

@prodrigestivill @SoCuul symlinking libraries from opt/homebrew/lib to /usr/local/lib is not really an option. It's a quite ugly workaround. The best option is to set the correct path to look for libraries based on the architecture the application has been compiled for.

I am not familiar with this code-base, but it's something trivial with CMake and similar build systems.

@prodrigestivill
Copy link
Collaborator

prodrigestivill commented Dec 30, 2024

@tanis2000 can you clarify me what libraries are you talking about?
this was my previous question, and I belive the answer will help me undestand better your point of view.

Iaito dmg is not using homebrew prefix nor usr/local prefix to install anything.

Having said that, I belive we must not use the /opt/homebrew path since for my interpretation this is clearly reseverd for packages installed using their package system, and the pkg files generated in radareorg/radare2 aren't in integrated with brew.

If this prefix was about the architecture, homebrew team wouldn't have named like that, so to me that path it's clearly reserved for their use only, and using it might corrupt brew installs and most provably is why they decided to change it from local in the first place.

So, alternatively, I can undestant a proposal use /opt/radare2 instead of /usr/local as its default installation path from the pkg, following the same spirit as homebrew team. But this would need to be changed into the rest of radareorg projects, since iaito insn't installing anything there.

This was about the install path, but I undestand that here we are talking about dyld serch path that iaito has set.
This path is in the build files because radare2 and r2pm (radare2 package manager) installs have /usr/local install prefix path by default on mac.
So it means iaito needs to look there for libraries too in order to ensure all the plugins work.

So changing this means changing it at least in radare2 and r2pm default paths for mac to, for example, /opt/radare2.

But the question I still don't undestant is why this is an issue?

Again, my M3 mac has a lot of arm64 files installed in /usr/local.
And some come from brew indirectly, since some casks install files there on launch (docker, rancher,...).

@tanis2000
Copy link

@prodrigestivill I am not saying that you should install Iaito somewhere else than where it is (btw it lives in /Applications just like all apps on macOS and it self-contained, so all good).

What I am saying is that the Iaito binary is loading some dynamic libraries and those dynamic libraries are in /opt/homebrew/lib by default on Apple Silicon devices.

If you look at the crashlog I posted, you can see the following:

Termination Reason:    Namespace DYLD, Code 1 Library missing
Library not loaded: /usr/local/lib/libr_reg.dylib
Referenced from: <EBA85510-AC4A-379A-9B72-169A792DAF24> /Applications/iaito.app/Contents/Frameworks/libr_egg.dylib
Reason: tried: '/usr/local/lib/libr_reg.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/usr/local/lib/libr_reg.dylib' (no such file), '/usr/local/lib/libr_reg.dylib' (no such file)

Iaito is compiled to load dynamic libraries from the paths you see above. Which is fine for x64 versions of macOS but it is not for arm64c versions.

As an example, libr_reg.dylib is here on my system:

➜  ~ ls -al /opt/homebrew/lib/libr_reg.dylib
lrwxr-xr-x  1 tanis  admin  42 Dec 27 10:57 /opt/homebrew/lib/libr_reg.dylib -> ../Cellar/radare2/5.9.8/lib/libr_reg.dylib

which is the standard place for radare2 libraries when you install radare2 using homebrew, which is quite common.

The easy and clean solution would be to add /opt/homebrew/lib to the list of paths to look for dynamic libraries. Is this explanation better?

@prodrigestivill
Copy link
Collaborator

yes, now I follow your point, thanks for the clarification.

So I undestand that the issue is when using iaito from dmg with homebrew installation of radare2.

Again, the iaito dmg from releases is build to be compatible with the pkg from radare2 relases page.

So I undestand that you are asking to make it compatible with the homebrew installation too, or maybe makes more sense to have a homebrew formulae for iaito that set those paths, so that brew users will install both using their install prefix.

@prodrigestivill prodrigestivill linked a pull request Jan 21, 2025 that will close this issue
@JeffyLikesApples
Copy link

So any update to this? I would like to use iaito but find it really silly that the only way to do so on an Apple Silicon mac is to either be forced to use the x86 release or the m1 (odd name) release myself. You could also just release a universal binary and make changes needed to account for homebrew installs, like every other app on the internet.

@JeffyLikesApples
Copy link

Again, the iaito dmg from releases is build to be compatible with the pkg from radare2 relases page.

This is kind of an odd stance to take here. Why is radare2 on homebrew then? Is this not the "official" GUI for radare2? There is zero reason as to why this application cannot make a few lines of changes to support official releases of radare2.

@JeffyLikesApples
Copy link

I would also like to add that the prooper xattr command is:
xattr -d -r com.apple.quarantine /Applications/iaito.app
The com.apple.quarantine attribute is what causes the error regarding it being "unsafe". This would also be fixed if a universal binary was built as the x86 version of your macOS releases does not have this issue.

@prodrigestivill
Copy link
Collaborator

As far as I know next iaito version will fix those things:

Also once we have this new release we plan to try to ask to add iaito to homebrew, but as of now iaito is not there :(.

Regarding updating the xattr command, can you please create a PR to update this file dist/macos/doc/README.txt with your proposal?

@SoCuul
Copy link

SoCuul commented Feb 3, 2025

#209 goes against the core homebrew packaging philosophy. Binaries should be distributed as formulae, and Applications as casks. When defining the cask, you can mark a formulae (eg. radare2) as a dependency, and it will be installed alongside the cask.

However, this does mean that you have to fix the behaviour of this app only checking /usr/local/bin instead of /opt/homebrew/bin for proper compatibility. Additionally, nearly every macOS developer will be using homebrew for dependency management so if this app does not work properly alongside it, the barrier for entry will be too high for most.

@prodrigestivill
Copy link
Collaborator

prodrigestivill commented Feb 3, 2025

@SoCuul I believe there is no need to get this confrontational, this issue has been taken care of, and we dedicated a lot of our free time to fullfill your requirements aiming also not to break what other users have.

What I have read their guidelines to submit Applications says that they dont want us to point to a dmg for homebrew only, they want to use the same dmg intended to use outside homebrew. This toghther with that homebrew don't allow formulae1 for Applications and having iaito binaries require the specific radare2 version on which it has been linked against.

Note that right now you must have the exact same radare2 version on which iaito has been build against in order to be able to launch iaito dmg from releases.

All toghether means that we don't want to use the one outside since all updates will break iaito because releases of radare2 and iaito aren't sync while there aren't any restriction on building.
And we can't have a specific homebrew iaito build in sync with homebrew radare2 versions, since this isn't alingned with what homebrew wants.

Regarding the second part, there is no need to have none of that paths you mentioned if radare2 is embded inside the dmg.
That path was to locate the radare2 install (pkg) with the same version iaito was build against.
If you take a look in the PR, you will see this isn't been used for mac builds when radare2 is bundled.

Footnotes

  1. Acceptable Formulae:

    Don’t make your formula build an .app (native macOS Application); we don’t want those things in Homebrew. Encourage upstream projects to build and support a .app that can be distributed by homebrew/cask (and used without it, too).

@SoCuul
Copy link

SoCuul commented Feb 5, 2025

Apologies if it came off confrontational, could have phrased it much more constructively. Upon further inspection, homebrew will not allow unsigned apps to be added to the casks repository.

As an alternative you can host your own tap in this (or another) repository. This gives the added benefit of not having to follow their packaging guidelines, allowing you to distribute whatever you want in whichever form.

@prodrigestivill
Copy link
Collaborator

Thank you for bringing up the signing issue, we had this in mind some time ago, not sure what has been decided.
Thanks for linking it here too.

Also nice proposal to create our own tap repo, we will evaluate it too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants