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

El Capitan compatibility #30

Open
andrew-hill opened this Issue Jul 23, 2015 · 50 comments

Comments

Projects
None yet
@andrew-hill

andrew-hill commented Jul 23, 2015

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?

@darwin

This comment has been minimized.

Member

darwin commented Jul 26, 2015

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.

@andrew-hill

This comment has been minimized.

andrew-hill commented Jul 27, 2015

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.

@Joshfindit

This comment has been minimized.

Joshfindit commented Aug 4, 2015

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.

@Noctem

This comment has been minimized.

Contributor

Noctem commented Aug 10, 2015

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.

@DanielSmedegaardBuus

This comment has been minimized.

DanielSmedegaardBuus commented Aug 11, 2015

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?

@D-an-W

This comment has been minimized.

D-an-W commented Aug 11, 2015

I just tried...

"This version of Asepsis is only supported under OS X 10.8, 10.9 or 10.10.'

@darwin

This comment has been minimized.

Member

darwin commented Aug 11, 2015

@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.

@D-an-W

This comment has been minimized.

D-an-W commented Aug 11, 2015

Please do!

@darwin

This comment has been minimized.

Member

darwin commented Aug 12, 2015

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.

@D-an-W

This comment has been minimized.

D-an-W commented Aug 12, 2015

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?

@darwin

This comment has been minimized.

Member

darwin commented Aug 12, 2015

You have two options:

  1. This will just suppress update errors, but updater will run:
touch ~/.asepsis-suppress-update-errors
  1. This should uninstall updater component:
asepsisctl uninstall_updater
@DanielSmedegaardBuus

This comment has been minimized.

DanielSmedegaardBuus commented Aug 13, 2015

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 :) 👍

@Joshfindit

This comment has been minimized.

Joshfindit commented Aug 13, 2015

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?

@MichaelZaporozhets

This comment has been minimized.

MichaelZaporozhets commented Aug 29, 2015

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?

@darwin

This comment has been minimized.

Member

darwin commented Aug 29, 2015

@MichaelZaporozhets I'm sorry, I have no idea

@LuChenTar

This comment has been minimized.

LuChenTar commented Sep 2, 2015

@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

@dinamic

This comment has been minimized.

dinamic commented Oct 1, 2015

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?

@darwin

This comment has been minimized.

Member

darwin commented Oct 1, 2015

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?

@ckreon

This comment has been minimized.

ckreon commented Oct 3, 2015

Did the installer get broken? When I try to run the installer it says:
"Asepsis.pkg" can't be found.

@mikegreiling

This comment has been minimized.

mikegreiling commented Oct 15, 2015

@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?

@ckreon

This comment has been minimized.

ckreon commented Oct 15, 2015

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
#30 (comment).

@m-urban

This comment has been minimized.

m-urban commented Feb 2, 2016

@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…

@darwin

This comment has been minimized.

Member

darwin commented Feb 2, 2016

@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. ...

@danielbayley

This comment has been minimized.

danielbayley commented Feb 2, 2016

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?

@darwin

This comment has been minimized.

Member

darwin commented Feb 2, 2016

@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 :)

@m-urban

This comment has been minimized.

m-urban commented Feb 2, 2016

@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.

@darwin

This comment has been minimized.

Member

darwin commented Feb 2, 2016

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.

@mikegreiling

This comment has been minimized.

mikegreiling commented Feb 2, 2016

@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.

@m-urban

This comment has been minimized.

m-urban commented Feb 2, 2016

@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.

@darwin

This comment has been minimized.

Member

darwin commented Feb 2, 2016

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).

@m-urban

This comment has been minimized.

m-urban commented Feb 27, 2016

Just wanted to confirm that @darwin's suggestion actually works:

  1. Disable SIP in recovery mode
  2. Reboot
  3. asepsisctl install
  4. Re-enable SIP in recovery mode (optionally with --without debug in order to continue using TotalFinder and TotalTerminal in non-OSAX mode)
  5. Reboot
$ 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.

@mikegreiling

This comment has been minimized.

mikegreiling commented Feb 27, 2016

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/

@darwin

This comment has been minimized.

Member

darwin commented Feb 28, 2016

Great! Thanks for confirmation and the blog post.

@sookoll

This comment has been minimized.

sookoll commented Mar 22, 2016

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?

@darwin

This comment has been minimized.

Member

darwin commented Mar 22, 2016

@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)?

@sookoll

This comment has been minimized.

sookoll commented Mar 22, 2016

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.

@s3131212

This comment has been minimized.

s3131212 commented Feb 11, 2017

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

image

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 :)

@darwin

This comment has been minimized.

Member

darwin commented Feb 11, 2017

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?

@redxef

This comment has been minimized.

redxef commented Jul 1, 2017

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.

@frogworth

This comment has been minimized.

frogworth commented Jun 14, 2018

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)

@darwin

This comment has been minimized.

Member

darwin commented Jun 14, 2018

You might try to comment out that check, I don't think it is necessary. But I have not tested it myself.

unless is_library_fat_with_both_slices? DS_WRAPPER_SOURCE_PATH then
die("the wrapper library is expected to be a fat binary. (#{DS_WRAPPER_SOURCE_PATH} should contain both slices x86_64 and i386)")
end

@frogworth

This comment has been minimized.

frogworth commented Jun 15, 2018

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.

@JK3Y

This comment has been minimized.

JK3Y commented Aug 26, 2018

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

@frogworth

This comment has been minimized.

frogworth commented Aug 26, 2018

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!

@JK3Y

This comment has been minimized.

JK3Y commented Aug 26, 2018

@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.

@darwin

This comment has been minimized.

Member

darwin commented Aug 26, 2018

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

@JK3Y

This comment has been minimized.

JK3Y commented Aug 26, 2018

@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!
screen shot 2018-08-26 at 6 17 20 pm

@frogworth

This comment has been minimized.

frogworth commented Aug 26, 2018

@JK3Y if you could share that fork I'd be grateful!

@JK3Y

This comment has been minimized.

JK3Y commented Aug 26, 2018

@frogworth Here ya go! https://github.com/JK3Y/asepsis. Just follow the build instructions and it should work :)

@dinamic

This comment has been minimized.

dinamic commented Aug 27, 2018

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment