Open andrew-hill opened 9 years ago
AFAIK Asepsis under El Capitan with System Integrity Protection enabled is not possible.
I'm going to stop developing Asepsis and supporting it under El Capitan.
Interesting, I wasn't aware of this change, so good to know...
A bit of light reading for anyone else who comes across this and doesn't know about System Integrity Protection: Wikipedia and Apple El Capitan changes.
Apparently you can disable System Integrity Protection, but its not a simple setting in System Preferences, so presents a pretty big barrier for Asepsis and a lot of other utilities like it that inject/override/etc.
It'll be interesting to see if Apple allow specific exceptions to it, without entirely disabling System Integrity Protection... I'll certainly be submitting some feedback about this, and would encourage others to do so as well. My guess is they'd go for something like 'signed extensions' for this, rather than arbitrarily disabling specific aspects of SIP.
I've filed a 'bug' through the Feedback Assistant, and suggest others do the same. And yes, I'm aware of the bias against telling Apple what we actually want; imho the vote should be counted regardless.
I was (naïvely) hoping that Apple would finally at least provide an option in vanilla El Capitan to cease .DS_Store pollution. I guess I'll just keep waiting.
You say that "Asepsis under El Capitan with System Integrity Protection enabled is not possible". This feature can be disabled in Recovery Mode, though. Which I already did to make XtraFinder work :D Would it be possible to do the same with Asepsis? Is it safe to just try to install the latest version with SIP turned off?
I just tried...
"This version of Asepsis is only supported under OS X 10.8, 10.9 or 10.10.'
@DanielSmedegaardBuus I guess Asepsis works with SIP disabled under El Capitan. But I haven't tested it myself. I can prepare a new build with OS requirement check disabled.
Please do!
http://downloads.binaryage.com/Asepsis-1.5.2.dmg
before installing please run this command in Terminal.app:
touch ~/.no-asepsis-os-restriction
I have just briefly tested it here on my El Capitan B6 system and Asepsis seems to work. The only problem is that some apps that link against DesktopServicesPriv.framework will be treated as newly downloaded from the internet. I had to click through all the warning dialogs again.
Everything other than the update checker seems to work here, assuming there isn't going to be another update can this be disabled to prevent the errors?
You have two options:
1) This will just suppress update errors, but updater will run:
touch ~/.asepsis-suppress-update-errors
2) This should uninstall updater component:
asepsisctl uninstall_updater
Awesome! Works :D Thank you so much :) OS X had already started cluttering my project directories, was so sad to not have Asepsis around anymore to prevent that :) :+1:
I had to click through all the warning dialogs again.
There is some talk around this that's not related to Asepsis: http://forums.macrumors.com/threads/getting-lots-of-the-first-time-warning-at-system-startup-after-upgraded-to-dp6.1905498/ - Some people there are having success with enabling auto-login. Maybe related?
Even after running the commands:
touch ~/.no-asepsis-os-restriction
& touch ~/.asepsis-suppress-update-errors
the installer is still returning an install error ( using your 1.5.2 installer )
Anything else I can do?
@MichaelZaporozhets I'm sorry, I have no idea
@MichaelZaporozhets Try to disable https://forums.developer.apple.com/thread/3981 and touch ~/.no-asepsis-os-restriction use 1.5.2.installer , works for me
I saw the page got updated saying Asepsis is no longer maintained and will be made to work on El Capitan, which is sad.
Has been one month since this thread was active. Is there any update on this?
I have published the 1.5.2 version on the site and wrote this: http://asepsis.binaryage.com/#sip
It there anything I should add or explain better?
Did the installer get broken? When I try to run the installer it says: "Asepsis.pkg" can't be found.
@darwin Question: could Asepsis be altered in such a way that it could be installed by first disabling SIP, then installing the utility, then re-enabling SIP? Or is the way Asepsis works incompatible with that approach?
Also does disabling SIP make the OS any less secure than it was under Yosemite? It is strictly a new enhancement, right?
As far as I am aware, SIP needs to remain disabled for Asepsis to function normally (along with other Binary Age products, including TotalFinder and TotalTerminal).
Regarding security, again, as far as I'm aware, you aren't any less secure than under Yosemite - but there can be an issue with certain things, an example being the new Disk Utility app. It assumes permissions can't be modified, and thus doesn't include a permission repair tool (not even one we can access via terminal).
There may be other assumptions like this throughout the operating system that could cause vulnerabilities with SIP off. Personally, I think as long as you use common sense and follow the same precautions you always have, it shouldn't be an issue. But technically speaking, it does make the system less secure than it could be, and the OS was built assuming it would remain on for normal use. Take from that what you will.
I actually downgraded back to Yosemite as the Capitan upgrade killed all of my permissions, and without a repair tool, it wasn't really feasible to try and sort through all the directories manually. I assume this was caused because I upgraded while having software like HomeBrew, Asepsis, and TotalTerminal - which intertwine with the OS in somewhat complicated ways. I will try again pretty soon, maybe once the first patch goes public. Hopefully a clean install will prevent the permissions nightmare I faced the first time.
On Wed, Oct 14, 2015 at 11:24 PM Mike Greiling notifications@github.com wrote:
@darwin https://github.com/darwin Question: could Asepsis be altered in such a way that it could be installed by first disabling SIP, then installing the utility, then re-enabling SIP? Or is the way Asepsis works incompatible with that approach?
Also does disabling SIP make the OS any less secure than it was under Yosemite? It is strictly a new enhancement, right?
— Reply to this email directly or view it on GitHub https://github.com/binaryage/asepsis/issues/30#issuecomment-148293487.
@darwin First of all, I would like to thank you very much for the hard work that has gone into developing some of my most valuable tools, namely TotalFinder, TotalTerminal and Asepsis. Updating to 10.11 has unfortunately impacted my work flows in a considerable way, because I cannot, more or less, rely on these great utilities anymore.
On the binaryage forum user aaaron_king mentioned that another developer evidently managed to circumvent SIP by having their code injection handled by a kernel extension.
@darwin I apologize in advance as I don't fully understand all the technical requirements involved here, but I was reading about code injection and I came across a mod called "DockMod" that figured out a way to do code injection in El Capitan without disabling SIP. Portions of their FAQ page says:
Dockmod 4 for El Capitan does not modify any system files. Apple introduced a new security policy on OS X El Capitan [SIP] that prevents modification of system files, even by privileged processes... To get around these measures and still achieve code injection, Docked 4 utilizes a signed kernel extension (KEXT) to handle the injection…
Docked 4 does not require you to disable System Integrity Protection (Rootless). See FAQ section on: https://www.spyresoft.com/dockmod/25
This option may not even be possible for TF, but I thought I'd bring it up in case no one else had.
Did you ever get a chance to look into this? It may or may not be the solution for TotalFinder, TotalTerminal and Asepsis. It almost sounds as if you could simply launch the injection process from the kext which has the necessary rights to do so. Unfortunately I wasn't personally able to test anything the like, as I currently don't have a paid Apple Developer membership which is required to codesign the kext these days…
@m-urban Thanks, I'm glad you find my apps useful. Dockmod approach was promising, we tried it recently, but KEXT signing must be approved by a live person in Apple and they declined our request.
... Kext signing is not intended for products that bypass OS X security features such as System Integrity Protection. ...
They should fix the damn underlying reasons people turn to things like Asepsis/Total/XtraFinder in the first place instead of just locking everything down without any consideration. I mean… would they prefer people disabling these security features altogether?
@danielbayley: people usually don't disable security features, the majority simply stops using our apps. I'm glad there is at least a way for technical people to disable SIP if they really have to. Could have been worse :)
@darwin Thanks for the explanation. That is too bad, really. I wonder how the Dockmod folks got to their certificate…
It seems that these Hackintosh Guys are struggling with the same kind of problems. From their forum posts I get that kexts are cached. If this happens while SIP is disabled, an unsigned kext will remain working even after SIP has been turned on again. Evidently one would have to repeat the same spiel every time the system is updated, though. Bummer.
Unfortunately I need some easy to follow / robust way how to let people use TotalFinder. I don't have bandwidth to support people who get stuck messing with their systems.
Actually there is a way how to run TotalFinder with full SIP enabled: http://totalfinder.binaryage.com/system-osax
But I don't advertise it much, because I cannot really support people when it stops working or something goes wrong.
@m-urban if that is the case, and this technique could be used for Asepsis, I could live with re-doing the procedure with each update. We pretty much had to re-install Asepsis with each update before this, albeit in a less complicated manner.
@darwin I wasn't aware of the OSAX approach, thanks for the link! I take it that this might also work for TotalTerminal, as the installer's pkg contains an osax file, too?
It looks like Asepsis is architected differently, though (no OSAX, right?). But I have to agree with @mikegreiling — if that is what it takes, I would gladly walk this route upon every system update. I have to agree with your statement regarding support for the average user, though — it isn't scalable.
Right, Asepsis does not use OSAX. Asepsis just patches some files in restricted areas. So I believe if you install Asepsis with SIP disabled and then reboot to fully enable it again, it should work (not tested).
Just wanted to confirm that @darwin's suggestion actually works:
asepsisctl install
--without debug
in order to continue using TotalFinder and TotalTerminal in non-OSAX mode)$ asepsisctl diagnose
Your Asepsis installation seems to be OK
A consequent asepsisctl migratein
eventually relieved me from all those pesky .DS_Store
files again that I have acquired since upgrading to 10.11. Thank god.
Awesome, I've just verified this as well. Thanks @m-urban & @darwin.
I've thrown together a blog post with step-by-step instructions for anyone who might not want to dig through this lengthy GitHub issues thread.
http://pixelcog.com/blog/2016/disable-ds_store-in-el-capitan/
Great! Thanks for confirmation and the blog post.
OSX updated to 10.11.4 today and I'm not able to get Asepsis run again:
$ asepsisctl diagnose
DesktopServicesPriv (/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv) is not properly installed.
=> Have you installed a system update recently? It might revert it back to the original version.
$ asepsisctl install
...
---- END DRY RUN ----
wrapper framework seems to be installed (/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A_ exists), to reinstall please run: "asepsisctl uninstall_wrapper" first
> "/Library/Application Support/Asepsis/ctl/asepsisctl" install_updater
> sudo cp "/Library/Application Support/Asepsis/com.binaryage.asepsis.updater.plist" "/Library/LaunchAgents/com.binaryage.asepsis.updater.plist"
Asepsis installation encountered some failures, please inspect the command output.
$ asepsisctl uninstall_wrapper
DesktopServicesPriv wrapper was replaced by system version since last Asepsis installation.
Usually this is the case when you install a system update which updates DesktopServicesPriv related files.
=> continuing in wrapper uninstallation, but skipping backup restoration.
> sudo "/usr/bin/codesign" --timestamp=none --force --sign - "/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv"
/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv: replacing existing signature
/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv: Operation not permitted
failed with code pid 1109 exit 1
Anybody who has able to got it working again after op.sys update?
@sookoll looks like you don't have permissions to modify /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv
Aren't you running it with SIP enabled (protected filesystem)?
Ah crap, yes You are right. I ran crsutil disable; reboot in a row so I didn't notice a typo, so SIP didn't disabled. Thanks. It work now again.
Though I know this software isn't under development, I need some help with that. I could make asepsis work properly on El Capitan by the approach mentioned above. However, it seems like disabling SIP no longer works on macOS Sierra. I'm sure I disabled SIP correctly and reboot after installation, however, the diagnosis output:
asepsisd is not installed in /Library/Application Support/Asepsis/asepsisd ?
stat: /Library/Application Support/Asepsis/asepsisd: stat: No such file or directory
asepsisd has unexpected attributes:
asepsisd is not running! it should be launched by launchd during system launch or right after Asepsis installation
Here's the log when I ran asepsisctl install
:
AlleniMac:~ allen$ asepsisctl install
> "/Library/Application Support/Asepsis/ctl/asepsisctl" create_symlink
> mkdir -p /usr/local/bin
> sudo rm "/usr/local/bin/asepsisctl"
> sudo ln -Fs "/Library/Application Support/Asepsis/ctl/asepsisctl" "/usr/local/bin/asepsisctl"
> "/Library/Application Support/Asepsis/ctl/asepsisctl" make_dscage
> mkdir -p "/usr/local/.dscage"
> chmod 777 "/usr/local/.dscage"
> "/Library/Application Support/Asepsis/ctl/asepsisctl" install_daemon
> sudo cp "/Library/Application Support/Asepsis/com.binaryage.asepsis.daemon.plist" "/Library/LaunchDaemons/com.binaryage.asepsis.daemon.plist"
> sudo launchctl load "/Library/LaunchDaemons/com.binaryage.asepsis.daemon.plist"
/Library/LaunchDaemons/com.binaryage.asepsis.daemon.plist: service already loaded
> "/Library/Application Support/Asepsis/ctl/asepsisctl" launch_daemon
> sudo launchctl start "com.binaryage.asepsis.daemon"
> "/Library/Application Support/Asepsis/ctl/asepsisctl" install_wrapper
---- START DRY RUN ----
> sudo rm -rf "/tmp/asepsis-codesign-dry-run"
> sudo mkdir -p "/tmp/asepsis-codesign-dry-run"
> sudo cp -a "/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A" "/tmp/asepsis-codesign-dry-run"
> sudo "/Library/Application Support/Asepsis/install_name_tool" -id "/tmp/asepsis-codesign-dry-run/A/DesktopServicesPriv" "/tmp/asepsis-codesign-dry-run/A/DesktopServicesPriv"
> sudo "/usr/bin/codesign" --file-list - --timestamp=none --force --sign - "/tmp/asepsis-codesign-dry-run/A/DesktopServicesPriv"
/tmp/asepsis-codesign-dry-run/A/DesktopServicesPriv: replacing existing signature
/private/tmp/asepsis-codesign-dry-run/A/DesktopServicesPriv
/private/tmp/asepsis-codesign-dry-run/A/_CodeSignature/CodeResources
> codesign --verify "/tmp/asepsis-codesign-dry-run/A/DesktopServicesPriv"
> codesign --verify "/tmp/asepsis-codesign-dry-run/A"
> sudo rm -rf "/tmp/asepsis-codesign-dry-run"
> sudo mkdir -p "/tmp/asepsis-codesign-dry-run"
> sudo cp -a "/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A" "/tmp/asepsis-codesign-dry-run"
> sudo cp "/Library/Application Support/Asepsis/DesktopServicesPrivWrapper" "/tmp/asepsis-codesign-dry-run/A/DesktopServicesPriv"
> sudo "/usr/bin/codesign" --file-list - --timestamp=none --force --sign - "/tmp/asepsis-codesign-dry-run/A"
/tmp/asepsis-codesign-dry-run/A: replacing existing signature
/private/tmp/asepsis-codesign-dry-run/A/DesktopServicesPriv
/private/tmp/asepsis-codesign-dry-run/A/_CodeSignature/CodeResources
> codesign --verify "/tmp/asepsis-codesign-dry-run/A/DesktopServicesPriv"
> codesign --verify "/tmp/asepsis-codesign-dry-run/A"
> sudo rm -rf "/tmp/asepsis-codesign-dry-run"
---- END DRY RUN ----
> sudo cp -a "/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A" "/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A_Backup_Panic_10_12_3_16D32_20170211113551"
> sudo rm -rf "/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A_Backup"
> sudo cp -a "/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A" "/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A_Backup"
> sudo touch "/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/asepsis-1.4"
> sudo cp -a "/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A" "/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A_"
> sudo "/Library/Application Support/Asepsis/install_name_tool" -id "/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A_/DesktopServicesPriv" "/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A_/DesktopServicesPriv"
> sudo "/usr/bin/codesign" --file-list - --timestamp=none --force --sign - "/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A_/DesktopServicesPriv"
/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A_/DesktopServicesPriv: replacing existing signature
/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A_/DesktopServicesPriv
/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A_/_CodeSignature/CodeResources
> codesign --verify "/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A_/DesktopServicesPriv"
> codesign --verify "/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A_"
> sudo cp "/Library/Application Support/Asepsis/DesktopServicesPrivWrapper" "/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv"
> sudo "/usr/bin/codesign" --file-list - --timestamp=none --force --sign - "/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A"
/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A: replacing existing signature
/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv
/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/_CodeSignature/CodeResources
> codesign --verify "/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv"
> codesign --verify "/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A"
> "/Library/Application Support/Asepsis/ctl/asepsisctl" install_updater
> sudo cp "/Library/Application Support/Asepsis/com.binaryage.asepsis.updater.plist" "/Library/LaunchAgents/com.binaryage.asepsis.updater.plist"
Asepsis installation done, it is effective for newly launched processes, you should reboot your computer.
Any help is appreciated :)
To me it looks like Asepsis is not installed here /Library/Application Support/Asepsis
. This should be normally done by the installer (or alternatively it can be done by hand).
Did you run the installer?
I have been encountering a case of "Higher usage of CPU for Helper Services, which make use of the DesktopServicesPriv.framework". This resulted in a DropboxHelper using up one full thread of the CPU. I eventually tracked it down to asepsis and uninstalled it, which solved my problem.
One thing to note, after installing asepsis I updated my OS, maybe from 10.11.4 to 10.11.6 but had SIP disabled. I did not check if asepsis was running correctly but uninstalled directly.
Old thread but I just tried reinstalling Asepsis on 10.13.5 and I'm told:
the original library is expected to be a fat binary. (/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv should contain both slices x86_64 and i386)
So is that it? RIP my folders, .DS_Store apocalypse here we come? 😭 (For reference, I am willing to leave SIP off, and I use Windows in Parallels constantly, so .DS_Store bugs the hell out of me)
You might try to comment out that check, I don't think it is necessary. But I have not tested it myself.
Thanks @darwin I meant to come back but lost track of which thread I'd posted to like an idiot. I resolved it by reinstalling from scratch from the last installer. But I'm happy to try recompiling with that check commented out if need be next time.
Hello @darwin, I know that this is unsupported currently, but when trying to install this on Mojave I'm getting this strange error that I never received on High Sierra and was wondering if you could shed some light on it:
▶ csrutil status System Integrity Protection status: disabled.
~ ▶ asepsisctl install_wrapper
---- START DRY RUN ----
sudo rm -rf "/tmp/asepsis-codesign-dry-run" Password: sudo mkdir -p "/tmp/asepsis-codesign-dry-run" sudo cp -a "/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A" "/tmp/asepsis-codesign-dry-run" sudo "/Library/Application Support/Asepsis/install_name_tool" -id "/tmp/asepsis-codesign-dry-run/A/DesktopServicesPriv" "/tmp/asepsis-codesign-dry-run/A/DesktopServicesPriv" /Library/Application Support/Asepsis/install_name_tool: for architecture x86_64 object: /tmp/asepsis-codesign-dry-run/A/DesktopServicesPriv malformed object (unknown load command 8) failed with code pid 2844 exit 1
Hey @JK3Y, I'm still on High Sierra, but FWIW something very similar to that happened to me, and I resolved it by running the actual installer .pkg file in the 1.5.2 dmg again - not just the install_wrapper command. uninstall_wrapper wouldn't work properly either, but after trying that and rebooting (I think), the installer itself worked.
I'm hoping you can get it going on Mojave because I want it working too!
@frogworth That didn't work. :( I read that Mojave has beefed up SIP, which is most likely the reason that it isn't working. Asepsis is easily one of the most important apps that I use as a developer and I've yet to find any alternative anywhere online. TotalFinder isn't working for me either, even with SIP completely disabled it won't start up.
I'm sorry. I don't use Asepsis anymore and cannot spend time trying it under Mojave.
@JK3Y TotalFinder had issues sending Apple Events in previous beta releases of Mojave. But those have been resolved by Apple. See https://discuss.binaryage.com/t/totalfinder-support-in-macos-10-14-mojave/6506/86
@darwin I was able to get Asepsis to install on Mojave by: Using macOS's install_name_tool Removing all support for i386 Removing the "is_library_fat_with_both_slices" checks Changing the deployment targets to 10.13 Updating any depreciated functions to newer versions (like Gestalt)
I'll be committing my changes to my fork here in a bit but so far it's working. I haven't reenabled SIP yet, but asepsis continues to work following reboots. :D
Edit: I have reenabled SIP. TotalFinder told me to either reenable SIP or uninstall it; Asepsis on the other hand is working just fine!
@JK3Y if you could share that fork I'd be grateful!
@frogworth Here ya go! https://github.com/JK3Y/asepsis. Just follow the build instructions and it should work :)
@JK3Y, thanks for your time in fixing the issue with High Sierra and El Capitan <3
Sadly, I am unable to make it clone properly. Here's the error message that I stumbled upon.
~/Projects/Internal$ git clone https://github.com/JK3Y/asepsis.git
Cloning into 'asepsis'...
remote: Counting objects: 1303, done.
remote: Total 1303 (delta 0), reused 0 (delta 0), pack-reused 1303
Receiving objects: 100% (1303/1303), 2.01 MiB | 459.00 KiB/s, done.
Resolving deltas: 100% (621/621), done.
~/Projects/Internal$ cd asepsis/
~/Projects/Internal/asepsis$ git submodule update --init
Submodule 'sparkle' (https://github.com/sparkle-project/Sparkle.git) registered for path 'sparkle'
Submodule 'uninstaller' (git@github.com:binaryage/uninstaller.git) registered for path 'uninstaller'
Cloning into '/Users/nikola/Projects/Internal/asepsis/sparkle'...
Cloning into '/Users/nikola/Projects/Internal/asepsis/uninstaller'...
error: Server does not allow request for unadvertised object 9016c3e45ab247cee81dbd78f253925c43c8704e
Fetched in submodule path 'sparkle', but it did not contain 9016c3e45ab247cee81dbd78f253925c43c8704e. Direct fetching of that commit failed.
Please, consider opening the issues
tab in your fork, so not to spam this thread.
As I'm sure you're aware, public & developer betas are out for OS X 10.11 El Capitan.
During installation (pubic beta), Asepsis was explicitly noted as being incompatible and disabled by OS X.
Are you planning on releasing a version compatible with El Capitan, and if so is there a (rough) timeline?