Installer is clobbering i386 slice of DesktopServicesPriv

[mralexgray]

Symptom: Launch some i386 something or other... and you'll hear cries...

dyld: Library not loaded: /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv Referenced from: /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit Reason: no suitable image found. Did find: /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv: mach-o, but wrong architecture [1] 14389 trace trap _whatever it was that called

And goddamnit, she's right... file /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv

Mach-O 64-bit dynamically linked shared library x86_64

but...

file /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A_Backup/DesktopServicesPriv

Mach-O universal binary with 2 architectures Mach-O 64-bit dynamically linked shared library x86_64 Mach-O dynamically linked shared library i386

This can be fixed ONLY, it seems, with a MANUAL restore from the backup...

sudo cp -f /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A_Backup/DesktopServicesPriv /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv

Not good, right? I don't quite see why it's not including both slices of the universal binary in the "fake" DesktopServicesPriv... but I checked to make sure my codesign wasn't linked to something weird/sketchy, etc. and didn't find anything local to my machine that might be f-ing it up. Any ideas?

[mralexgray]

i'm tempted to close this... i had to do a whole bunch of weird stuff, but seems like it is working.. not sure what happened... whether it was a botched install from the stable binary-release installer, or what.... quick question... when you patch that Private framework.. which copy that's made.. i'm guessing its _A.. is the actual backup. that shit is kind of confusing, yo.. why do many backups.. and why.. after patching.. is the Code Signature folder not put back in with the framework? is that the little trick? just sort of trying to better comprehend whats all going on here :-)

[darwin]

I'm sorry I can't really answer those question. I would have to load the context of this project into my head.

I'm doing many backups, because it is safer. Older version was overriding just one backup location and this could theoretically lead to overriding a good backup with a bad backup. Imagine a case when someone interrupts installation or uninstallation to the point that DesktopServicesPriv is broken, asepsis installer would not detect it and next installation would save it as a backup.

[mralexgray]

This is definitely broken... After a CLEAN install, albeit on 10.10.3 beta (14D113c).. I cannot open a lot (but not all apps).. Wish I could attach a log about it, but they're dying silently...

All the same as I said above remains relevant... The patched DesktopServicesHelper is missing it's 32-bit slice.. and the only way to repair the system is to manually restore the backed up A_Backup_Panic or to run the apesisctl uninstaller.

I am tempted to "fatten" the binary with the hacked 64-bit only, and a slice of the backup via a lipo -create "franken-framework", but I am too sketched / unable to predict the consequences.

I can't be the only one experiencing this.... Or are we at the point that so few people are using this that I may just be the guinea pig?

[bergerc]

Same problem, OS X 10.10.2, after "sudo asepsisctl install_wrapper" some apps (including Truecrypt, NTFS for Mac...) do not work anymore. Error message: Reason: no suitable image found. Did find: /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv: mach-o, but wrong architecture

Only solution is to restore the A folder (delete A and move A to A). But after restore asepsis is no longuer working, it asks for a diagnose and reinstall.

[mralexgray]

On a side note - looking at the guards in uninstall_wrapper.rb and install_wrapper.rb I would (naïvely) venture to suggest that... the backup routines - those that create the different A_Backup_Panic_20150330042814 etc create versions based not on Time, but on System version?

Back to the topic at hand...

1 - I noticed DesktopServicesPriv is getting copied to backup with -a aka Preserves structure and attributes of files but not directory structure. Could that be problematic?

2 - I noticed last time I tried that the version of DesktopServicesPriv that gets left in place (that doesn't work) is TINY. NOT ~3.5MB, but like 3-400K. I can't figure out where the code is getting slashed... I thought it might be when doing codesign, and that adding --all-architectures might help, but according to the manpage...

This is the default unless overridden with the -a (--architecture) option.

[bergerc]

Hi,

lipo -info ./A/DesktopServicesPriv Non-fat file: ./A/DesktopServicesPriv is architecture: x86_64 lipo -info ./A_OriginalYosemite/DesktopServicesPriv Architectures in the fat file: ./A_OriginalYosemite/DesktopServicesPriv are: x86_64 i386

So, what about removing the build option "Build active architecture only" introduced by XCode 3.2 I heard about a --fat-binary but I'm not familiar with XCode, somone does now where to put these options ? my tests didn't work.

[darwin]

"Build active architecture only" does not help I guess (https://github.com/binaryage/asepsis/pull/26 does not fix this issue).

I have just checked 1.5 release and the compiled wrapper coming from the installer has both architectures. The i386 slice must be lost during codesign step during install_wrapper task. https://github.com/binaryage/asepsis/blob/092bb8c9cd118a05f0336769e223cf76ea53d0c6/ctl/cmd/install_wrapper.rb#L49

@mralexgray is probably right and we have to add some flag to codesign to preserve all architectures.

[darwin]

I just did testing on my clean 10.10.4 system with Asepsis 1.5 (I downloaded installer from the web).

The installer definitely contains fat version of the wrapper. Also installing it first time, my codesign properly re-signs original fat binaries and preserves both slices. Tried to do asepsisclt install_wrapper and asepsisctl uninstall_wrapper several times. Always watched for errors and validated that resulting binaries have both slices and are properly signed. All seems to be ok on my machine.

My theory is that you guys might have some bad version of codesign which does not do the right job. This is a theoretical danger. Asepsis install_wrapper is quite paranoid about having codesign available, but it only checks for a presence of codesign, it does not check for its version or proper function.

Ideas?

[darwin]

Above I spoke about the main DesktopServicesPriv binary. Resources and XPCServices get copied as-is.

Resources/DesktopServicesHelper had initially only x86_64 slice. Asepsis does not change that.

[mralexgray]

Lots of things/packages/etc seem to bundle their own / customized versions of codesign. Can we just compile codesign so that a guaranteed functional version ships with the installer and commit the binary in working form to the tree? Obviously, relying on random/unverified/user-mucked-with versions of codesign has proven unreliable. Including it might just be the simplest solution.

Sent from my iPhone

[darwin]

I have decided to add more checks and to dry run codesign in a temp folder to test its function.

This probably does not solve the root cause of losing i386 slice, but asepsis refuses to install if it detects this situation. Also it will report panic errors if it gets itself into this state (for whatever reason).

[debo]

@darwin regarding this issue. Is it safe to delete all the A_* folders and just keep A and the current link?

[darwin]

No, it is not safe to delete "A_", the library in "A" links to it.

It is safe to delete all backup folders though.

[debo]

So I assume I should remove those links first. I'm asking because I'm trying to solve an odd problem with a Cisco application and it might be that the cause is related to this.

[darwin]

Just use asepsisctl to uninstall asepsis. Or GUI uninstaller from Asepsis.dmg.

[debo]

Will that remove those folders? Because the problem is the application not knowing which library to load due to the duplications hence why I wanted to remove them

[darwin]

First uninstall asepsis, then (after restart) remove any remaining folders/files except "A" by hand.

[debo]

Okie dokie, I'll give that a try. Will I then be able to safely reinstall asepsis or that will cause the duplication again? Thanks a lot.

[darwin]

It will behave the same and will create duplication. It copies A as a backup for case of uninstallation.

Assuming you have clean system and installing Asepsis, it will:

1. backup A (multiple times)
2. move A to A_
3. create new A which is just a library wrapper pointing to A_

Details: https://github.com/binaryage/asepsis/blob/master/ctl/cmd/install_wrapper.rb

[debo]

Cheers, thanks a lot again.

[darwin]

btw. we have to start learning living without Asepsis anyways. It won't work in El Capitan anymore.

[debo]

Oh right. Well I think I will have to be more careful with my .gitignore then ;)

[darwin]

Git is easy. Put .DS_Store exclude to your global ~/.gitignore

[debo]

Yes I know, I was just kidding. The real problem are zip files shared with windows users and such. They will survive I'm sure :)