Find a stable way to distribute binary in future

[FranklinYu]

We have temporarily fixed #1106 by manually removing the code signature. There are three potential long-term solutions:

1. Continue removing the signature with codesign. Not really sustainable since this is private API.
2. Create a second target, as mentioned in Error: MacDown is damaged and can’t be opened #1106 (comment).
3. Create a company to hold the Developer Program account. Obstacles are mentioned in Error: MacDown is damaged and can’t be opened #1106 (comment)

[fadookie]

I have an inactive apple developer account under my personal name. I'd be willing to let it be used for notarization if we can raise funds to cover the annual membership costs. I can chip in $20 or so this year. Could set up a PayPal link, or apply for a GitHub sponsorship button to make it even easier for people to donate.

However, I don't know what the long-term effects of tying it to my personal account would be. Presumably if someone else needed to take it over in the future it might cause problems since I don't know how Sparkle would handle the public key changing.

[FranklinYu]

Yes, that can be the 4^th way. @tempelmann offered similarly in #1106 (comment). I’m not sure what user would think; I guess a poll is necessary before we actually go through this path.

[tempelmann]

You should not have to worry about Sparkle, as long as the private key is passed to the next maintainer who makes the releases. If you have to make a new key, then Sparkle won't let users update older versions to the differently signed newer app. Even including the private key here in the repository, though generally not a good idea, would not compromise much: If an attacker would build a "bad" app and sign it with the Sparkle key, he'd still have to manage to upload the bad app here so that downloads via Sparkle would download his faked app. That's very difficult to accomplish. So, with this being an open source project, I think you could just include the Sparkle key here in the repo, or at least give it to a few trusted developers who can give it to the next maintainer if necessary.

The only think you really have to protect well is the login for this github account, because that's the one for uploading new releases. But you know that already :) Just make sure that more than one person knows it, in case something happens and the current maintainer can't be reached any more.

For the regular code signing and notarization it does not matter who does it. Every new version could be signed by a different Apple Account, as Sparkle does not check that (or, if it does, you can easily disable that extra check). What should not change is the bundle ID - if that changes, Sparkle will not update the app (but there is no reason to ever change the bundle ID, as it's not tied to signing, so this should not be an issue).

So, make sure the Sparkle signing key is kept secure (and private) and can be passed to the next maintainer, and let anyone sign the apps for release. You don't have to have your own Account for that.

The only catch is that person who signs it with their account will be the one getting in trouble if Apple decides that the app (i.e. MacDown) is doing bad (illegal) stuff and wants to punish the developer. But as long as the app is open source, this shouldn't be a big risk. I'd personally not have a problem with offering the apps with my Apple account.

[FranklinYu]

Sparkle isn’t a problem at all. The safest solution is

1. Someone notarize the build and pass it to me (or post it here, it doesn’t contain secret).
2. I sign it with the Sparkle private key. This produces the signature (some Base64 string) without modifying the build.
3. I post the build as usual.

This way no private key need to be shared. As someone with security background I would try to avoid sharing any private key on the air.

[tempelmann]

Cool.

I'm codesigning and notarizing it now. Had to manually fix the sparkle framework first, though (see #1130).

Does notarization require some special access permissions? Such as for Calendar, Address book, Apple Events, etc? Does it generate code or load executable plugins?

[tempelmann]

Here's the signed and notarized app:

http://files.tempel.org/tmp/MacDown.app.zip

Ideally, you should verify that the executables in that archive are the same that you have, to make sure I didn't build a "bad" version. Not sure how to compare that, though. Maybe you can remove the code signing again with the signing tools and then see if the files are identical to yours. Hopefully they are. Or, instead, codesign both the original and my version with an ad-hoc cert, so that both should have the same, and then compare them. I have posted an SO question about this, just in case: https://stackoverflow.com/q/59443251/43615

[fadookie]

I think if you extract the bundle and do a directory diff you could verify all the resources are the same - i think the signature is just a regular file inside the bundle. However, it's likely the darwin binary is different. I guess it's possible it's the same if it was built on the exact same Xcode version with the same optimization settings, etc. But I'm not sure if there is a 1:1 guarantee even then.

[FranklinYu]

Note that currently I’m not prioritizing this issue since Sparkle should be working. When a user update through Sparkle, another right-click isn’t required. (At least this is what I expect right now.) I created issue out of concern that Apple would further restrict unsigned application.

Note that even Microsoft was hit by this change: microsoft/vscode#74782

[FranklinYu]

By the way, I finally found out why this suddenly broke. It’s not anything we did, but Apple disabled unsigned build since Xcode 10. I’m trying this hack to turn it off forcefully (thank you @mayoff!) in 2265422. I’m not sure whether this is less hacky than current codesign one or not, but hopefully it solves #1144. Let’s see how it goes.