auto-selfcontrol will break with upcoming SelfControl release

[cstigler]

Hey @andreasgrill, I’m the author of the SelfControl app itself. I’m about to release an update with a giant refactor that will hopefully make SelfControl less buggy, more tamper-proof, and way easier to update in the future. BUT, it will break auto-selfcontrol unless your tool is adjusted to match. I know many users love the auto-selfcontrol tool, so I wanted to give you a heads-up and see if we can coordinate on a fix.

Two big things that are changing:

1. We’re moving from a BlockStartedDate and BlockDuration to just a BlockEndDate that determines when the block will be over. This is cleaner and makes it possible to cleanly extend a block without any hacks.
2. We’re no longer storing all settings in the user defaults. As an anti-tampering measure, some of the settings are "secured" with a hash and stored in a file with a pseudo-randomized name.

My proposed resolution is that I just make y’all a set of org.eyebeam.SelfControl command-line methods that do what you need, and you move auto-selfcontrol to use those instead of directly reading/writing from defaults. I think we could do that with these methods:

1. org.eyebeam.SelfControl {userId} —version
   1. outputs the version string for the installed SelfControl command-line tool (note this may not be the same as the version of the installed SC app, since the command-line tool only gets copied over when a block is started)
   2. You'd use this method to decide whether to use the new behavior or fall back to the legacy behavior.
2. org.eyebeam.SelfControl {userId} —is-running
   1. outputs YES if a SelfControl block is currently running, or NO otherwise
3. org.eyebeam.SelfControl {userId} —install /path/to/saved/blocklist.selfcontrol
   1. blocklist.selfcontrol would have to be a saved blocklist in the SelfControl format (File —> Save Blacklist). That is very simple: Just a plist with two entries, HostBlacklist and BlockAsWhitelist. See this code to see exactly how we output those files: selfcontrol/AppController.m at b85462070b3f8e43a3d2831186f120b0ef079760 · SelfControlApp/selfcontrol · GitHub

The --version and --is-running methods are already implemented in the SC master branch; will work on the --install method taking blocklist files soon. Let me know if those work for you!. Thank you!

[andreasgrill]

Hi! Thanks for reaching out to me! This is great news, it will simplify the settings handling a lot. I will update auto-selfcontrol to keep it working with the new version. The --version and --is-running methods are clear to me, but I have a question about the --install method. Would it be possible to provide the BlockEndDate too, or do you prefer a different way to specify the length of the block?

[cstigler]

Great point - I totally missed that. What if we just added BlockEndDate as a fourth parameter after the blocklist, in ISO 8601 format? Then I'll just use NSISO8601DateFormatter to parse those string representations (and I'm sure Python has an equivalent since ISO 8601 is so common)

So a call might look like: org.eyebeam.SelfControl 501 —install /path/to/saved/blocklist.selfcontrol 2020-04-28T08:49:58.157+0000

[andreasgrill]

That works fine! Providing the ISO 8601 string should be no issue.

[cstigler]

OK, the change to -install is in! Works as described above, see commit here: https://github.com/SelfControlApp/selfcontrol/commit/120e0ab76d8861402dbed41ae7c9b684239edb64

Please take a look and make sure it's working the way you expect...

[andreasgrill]

I was able to build SelfControl locally (from Commit and try out the new CLI. I've tried --version and --is-running and I think they will work for me. I'll just parse the output on the last printed line.

I've also tried --install and it worked perfectly. I'll try to add support for the new CLI in Auto-SelfControl over the coming weekend. Do you already know what version number you'll be using for the new SelfControl release?

[cstigler]

Awesome, glad it's working! I'm planning to release it as 3.0, since it seems more major and breaking than any changes I've made in the last 5+ years... and will hopefully be doing that release soon (maybe this weekend, otherwise next weekend).

[andreasgrill]

That's great, I think I'll also be finished before the end of next weekend.

[cstigler]

SelfControl 3.0 is out! http://selfcontrolapp.com/

[andreasgrill]

Awesome! I’ll release Auto-SelfControl in the next few days.

[slambert]

Y'all are the best.

[slambert]

Ooops. 😆

[andreasgrill]

SelfControl 3 is now supported! Thanks again for helping me to keep Auto-SelfControl compatible. There is one issue, though. When SelfControl is started a security warning appears, at least on my mac. It warns me that SelfControl was downloaded from the Internet.

[cstigler]

Yay for the update! Re the security warning, does it only show up the first time or on every launch?

If only on first time, I'm not sure it's avoidable. It's properly signed and notarized for Gatekeeper, but macOS still shows that prompt on first launch. That's the "good" version of the warning since it has an Open button ;) The only way I know to disable it is by removing the com.apple.quarantine attribute on the file, which I suppose you could do from auto-selfcontrol just before launching SC if you wanted to avoid the warning: xattr -d -r com.apple.quarantine org.eyebeam.SelfControl. But my security side wonders if it'd be better to leave the warning if it's only once?

If it happens every time, that would be broken!

[andreasgrill]

Yeah, it appears to be showing always unfortunately :/ So, I guess I'd have to remove the warning manually 🤷. Thanks for the help!

[cstigler]

Hmmm, that is unfortunate and now I'm confused. My best guess is maybe the Gatekeeper system glitches when called via command-line? Does removing the quarantine attribute manually work for you?

[andreasgrill]

Yes, if I remove the attribute the warning is not shown anymore. I have to test it further, but do you think it would be a viable option to automatically remove the attribute?

[cstigler]

Yeah, that's the workaround I'd go for though I'm certainly no expert. It seems like a macOS bug to me that it's not cleared after the first launch anyway...

[gcohara]

Huge thanks for sorting this out! I'd noticed that the sbibauw fork had stopped working and thought I was going to have to roll my sleeves up myself until I saw this!

[cstigler]

forgot this never got closed :)