This is an early build of RapidWeaver 8.3. Due to DevMate closing down later this year we’re having to do a fair amount of work in implement a new crash reporter and update system. We’re also going to be doing a lot of testing to make sure 8.3 runs just great under macOS 10.15
This is an early build of 8.3, so proceed with the usual amounts of caution.
- Added support for Emporter (cc @mikey)
- Now using Sparkle for Updates as DevMate is closing down (more work to be done on this, YMMV)
- Various other under the hood tweaks and fixes.
Download RapidWeaver 8.3 (20766b) Developer Alpha
If you find any issues or need anything please post on this thread.
I noticed a small issue with the current bundled version of Sparkle (1.20) which may cause problems for plugin authors if RW manages plugin updates. Does it?
If it does, then the version of Sparkle that’s bundled with RW uses a deprecated way to check code signatures (DSA) which can cause problems for new plugins. Since macOS 10.13, private DSA keys cannot be reliably generated for Sparkle, which means that verification will always fail (if Sparkle doesn’t cause its host application to crash). See issue 1155 and 1285 on GitHub for some context.
It’s a dense subject, but basically Apple’s frameworks don’t actually support the keys generated by newer versions of OpenSSL. As a result, old DSA keys still work, but new apps need to use a different signing algorithm which is only supported by Sparkle 1.21+.
So, the short version is: you might want to update to a newer version of Sparkle to support update validation for new plugins The good news is that the legacy signatures (pre-1.21) will continue to work.
@mikey That new profile pic to way to fancy for this forum!!! Looks like you are about to get onto the red carpet…
@tpbradley @dan can you comment on how the changes make might affect plugin updates? does the switch to sparkle affect plugin updates or is that change purely for app-updates? or vice versa?
@mikey Thanks for brining this to our attention! As RW is a sandboxed app we can’t use the default distribution of Sparkle. Instead there’s another branch that separates the UI and moves the update process into XPC services, making it sandbox compatible. It’s such a mess, this branch is technically Sparkle v2 and a lot of devs have requested that it becomes the default distribution. More info about v2: Secure architecture for updating in a sandboxed environment · Issue #363 · sparkle-project/Sparkle · GitHub
I’m not sure if / how this DSA issue affects us yet - the v2 branch doesn’t appear to contain the EdDSA (ed25519) improvements.
Now, I have some good news and some bad news. The good news is that the updated Sparkle in RW only applies to RW updates. RW doesn’t use Sparkle for updating plugins - it has a custom updater, based on and compatible with Sparkle. The bad news is this custom updater is rather old poses a security risk. A future version of RW will use Sparkle to update plugins.
I’ve attempted to use Sparkle to update plugins and the vast majority of them fail due to the following.
- Update is served over HTTP
- DSA key specified but file doesn’t exist
- DSA key not specified and bundle isn’t codesigned
This also leads me to another problem… macOS Catalina. In Catalina, GateKeeper has been tightened up and will chuck out anything that isn’t code-signed, including plugins. During the launch of RW, GateKeeper will show this alert and prevent the plugin from loading.
(strangely, and this could be a bug, Stacks is not rejected - I’m not sure why.)
Also, Apple say
Beginning in macOS 10.15, notarization is required by default for all software.
However, I’m not sure if this is currently enabled in the beta - I’ve tried a few apps that aren’t notarized and they launch without issue. More info: Notarizing macOS software before distribution | Apple Developer Documentation
@tpbradley I was actually curious about the fact that RW is sandboxed and you were bundling Sparkle. I thought there might have been something special beneath the surface but wasn’t sure
As per the notarization requirement, Gatekeeper on Catalina will not show an error if the app was compiled/signed before June 1st, 2019. Any future updates to those plugins will not load if they aren’t notarized. It’s surprising that unsigned plugins load at all, but perhaps that’s the intended behavior of the “allow arbitrary loads” security exception granted to RW.
This past weekend, I actually played with Catalina, new builds of my apps, and notarization. I can confirm that apps will show that dialogue if the app was built after their deadline and it was not notarized. I automated the packaging/notarization in this Makefile.
I wish we were a few months into the future, because I’m heavily considering creating a service to manage updates and simplify things for distributing apps for macOS. Now that apps must be codesigned and notariazed, application signatures can be verified rather than the DSA nonsense. I actually did this for the Emporter CLI, and wrote my own “updater”, and can verify that it works with the notarization / hardened runtime.
Yeah I knew they had some kind of cut off date - couldn’t remember what it was. Interestingly, all the plugins I’ve tried were compiled before this date - some even built back in 2016!
The “Allow arbitrary loads” entitlement just applies to network traffic and allows insecure (non https) connections. Pretty sure that won’t affect this.
It could just be an OS bug that’s causing GateKeeper to be over protective. Either way, Apple are tightening up this stuff all the time so all plugin devs should be looking at code signing / notarizing their builds.
@mikey - i’m curious how you are notarizing plugins. it’s been a few weeks since i gave it a go, but when i tried i was not able to find a way to notarize a code bundle. it recommended that i notarize the package instead. but zip can’t be notarized.
does this mean going back to dmg packages? or is there some other way?
@tpbradley - as for why pluskit would be rejected and stacks wouldn’t…
¯\_(ツ)_/¯ i dunno. all my plugins are built from a common build script, on a common build server. there’s hardly anything unique.
i tested the build at the beginning of this thread
Version 8.3 (20766b) – it was able to load, download, and update pluskit 3, stacks 3, and stacks 4 – is the error you see above in a new build? or is that on Catalina?
i haven’t yet attempted catalina – stacks 4 beta is going public today or tomorrow – it didn’t seem like the time.
@isaiah No worries, it’s just in Catalina that I see the alert. It might just be worth waiting for beta 2, stuff is always busted in the first beta. Don’t know why I bother downloading it LOL
@tpbradley - ah, that makes sense. and i’m not surprised. it’s surprising it has taken apple this long to do some sort of gatekeeper on code bundles.
Does this mean that I would need to notarize my stack bundles as well?
there’s nothing in a stack that’s executable. so i’m guessing the answer is no.
but if you ever ship a package installer then definitely you’ll need to notarize those.