mumble-voip / mumble

Mumble is an open-source, low-latency, high quality voice chat software.
https://www.mumble.info
Other
6.45k stars 1.12k forks source link

Notarizing the mac build #4263

Closed TerryGeng closed 2 years ago

TerryGeng commented 4 years ago

After macOS 10.15, Apple requires all software to be notarized before distributing. Otherwise, the user will be prompted with a scaring warning:

image

The process of notarizing an app can be found here: https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution

In addition, useful information about notarizing apps automatically in a CI setup can be found at https://blog.zeplin.io/dev-journal-automate-notarizing-macos-apps-94b0b144ba9d

This process takes two steps:

First, we need to properly sign our app with a valid Apple Developer ID. We need to apply for one if we haven't done this before. https://developer.apple.com/programs/enroll/. A fee of $99 is charged :( for membership.

Then with that ID, we execute

export CODESIGN_ALLOCATE="/Applications/Xcode.app/Contents/Developer/usr/bin/codesign_allocate"
codesign --force --sign "Developer ID Application: <my name>" /path/to/my.app

https://stackoverflow.com/questions/13204407/how-to-codesign-an-existing-mac-os-x-app-file-for-gatekeeper

After signing the app, we can start to get it notarized. In short, we need to

  1. zip our Mumble.app container, then
  2. uploading the zip file to Apple's public notarizing service. That is, passing it to xcrun altool --notarize-app -t osx -f Example.app.zip --primary-bundle-id <Bundle identifier> -u <Apple ID username> -p <Apple ID password> --output-format xml where the Bundle identifier is something located in Info.plist.
  3. Then the notarizing request would be queued. We can run xcrun altool --notarization-info <Request identifier> -u <Apple ID username> -p <Apple ID password> --output-format xml to retrieve the status of this task.
  4. After the notarizing is done, we need to attach Apple's certificate to the app with xcrun stapler staple Example.app

These steps are certainly not hard. But the $99 is more like blackmail. If you don't pay, your users will be scared with a warning box. This is certainly not fun, even disgusting. People are complaining about this (see https://buckleyisms.com/blog/apple-should-provide-notarization-for-open-source-apps/) as well.

There are certainly many open source apps that don't give it a damn. I think it is up the the mumble team's choice whether to pay this $99 and deliver the users a warning box-free experience.

streaps commented 4 years ago

Fuck Apple and especially macOS Catalina. It only will get worse (https://www.osnews.com/story/131830/macos-10-15-slow-by-design/).

Krzmbrzl commented 4 years ago

Thank you for layout out this possibility @TerryGeng :)

Imo this is just ridiculous. I'm already very hostile towards MacOS due to me not liking the way it functions (though that of course is personal preference) plus them not allowing to use MacOS in a VM (which would allow us to test and develop Mumble on MacOS as well). If on top of that they come around and wanting to make us pay in order to get rid of that silly warning message, I tend more towards dropping mac-support completely than paying this fee.

However as this would only affect the Mumble users on MacOS instead of Apple as a whole, I am of course not promoting to drop MacOS support here though. However if we ever reach the point at which the payment is required in order for the application to run at all (or something that goes strongly in that direction), I'd be the first in line that votes to drop the OS entirely. Let's just hope that this won't happen though :point_up:

TL;DR: I'm very strongly against paying Apple for this bullshit. Even if someone else was to pay the bill (We shouldn't support this kind of strategy).

TerryGeng commented 4 years ago

@Krzmbrzl Yeah. That's true. I feel very uncomfortable to see this situation because I really like the products of Apple in general. And for the reason that I need to run some software on macOS (or Windows, which I don't like as well), it would be very hard for me to switch to other open source platforms. I believe this is the case for a lot of Mac users.

However if we ever reach the point at which the payment is required in order for the application to run at all

I think Apple is not too silly to understand that it is absolutely unbeneficial to piss off the open source community. So I don't really think they will be too ruthless to seal the way of running an App whose author doesn't pay the protection money.

Based on the discussion on #mumble, I suggest we make a highly visible message on the download page on mumble.info, stating that this warning box is expected. Users should not rely on Apple's Gatekeeper to verify the app. Instead they should download the signature file from mumble.info and verify by themselves. In order to run the app, they should click the System Preference -> Security -> Open Anyway button.

We can also make this a background image of the distributed DMG file.

Krzmbrzl commented 4 years ago

We can also make this a background image of the distributed DMG file.

Would that even be big enough to be readable? :thinking:

Based on the discussion on #mumble, I suggest we make a highly visible message on the download page on mumble.info, stating that this warning box is expected.

@Kissaki could you do that? :)

davidebeatrici commented 4 years ago

Right now we sign releases using @mkrautz's personal developer account.

Ideally we should create a dedicated account for the project, but I firmly believe giving money to Apple is morally wrong and harms the IT world.

I'm aware that unfortunately many people need macOS, either due to exclusive programs and/or because the company they work in forces it due to "security". I'm also pretty sure hardware that only works with macOS exists.

From my point of view the decision is up to the community, especially because we receive enough donations to pay Apple's pizzo. That is, unless they decide to add a magical 9 to the price tag.

Avatat commented 4 years ago

In my opinion, we shouldn't pay anything to Apple. If a user wants to use Mumble, their friends/colleagues will instruct them about Mac OS restrictions, and how to install and do the first-run of Mumble app.

Krzmbrzl commented 4 years ago

Right now we sign releases using @mkrautz's personal developer account.

But if we do sign releases... Where does the warning come from? :thinking:

If we can continue to use his account for that though, I'm all in to keep using that and providing signed / notarized builds.

davidebeatrici commented 4 years ago

The warning appears when running the builds produced by CI, we don't sign them.

toby63 commented 4 years ago

As much as I agree with what has been said before. Maybe you could contact Apple on this and ask about two topics:

  1. Exceptions regarding fees for open source projects like yours.
  2. Using virtual machines for testing.

It is possible that Apple does not care at all, but sometimes there are positive surprises.

Nonetheless the problem of indirectly supporting such manners remains.

Kissaki commented 4 years ago

I understand and can related to the general, prevalent frustration here. But I can also see why this was implemented with good reason.

For tech-savy persons this may not be necessary, but most users, even of Mumble I am sure, can not be trusted or asked to verify binary checksums, signatures, or even expected to download from the correct website.

Windows SmartScreen and Apple name-here are for those users. It attempts to solve this through building trust, and/or certification. And a not minimal entry fee so mass-scams are not worth it, and are associated to specific owners.

Windows SmartScreen requires code signing with certificates which are not cheap either, although distributed and created through third parties. Valve Steam added a game listing fee as well to prevent low quality product and scam spam.

For companies with a software product 100 USD is a drop in the bucket. For individuals, non-commercial projects and people who already spent a ton of their free time it is.

I am hesitant to just pay though. (Popular) FOSS projects should definitely get free or price reduced certificates either directly or indirectly.

I am certainly not against a dedicated funding where people could donate for this specific cause if they want to support this, for themselves, the platform or the project in general. If there were a FOSS solution available that would be even better. Either directly or some other forms of donations (certifying companies).

For now I agree we can and should document the current state and that it is what it is. Whether I would be in favor of paying or not would also depend on the userbase; how big the platform is for our project. It’s not necessarily necessary for a niche. I guess generally I think we should aim for doing so though if we can find a reasonable solution. Idealism is a good thing but should not ignore pragmatism. If we want to support the platform, and do so for novice users, then there is no way around it.

Kissaki commented 4 years ago

Yes, I can add something notice to the downloads page. I’m working on that one right now anyway. I will create a separate mumble-www ticket for that.

Kissaki commented 4 years ago

mumble user wsky reports the 1.3.1 dmg shows the error.

Does our existing cert (that we use for the 1.3 stable builds) not meet the new criteria by apple?

davidebeatrici commented 4 years ago

It probably appears because we don't notarize the releases, we only sign them.

felix91gr commented 4 years ago

It probably appears because we don't notarize the releases, we only sign them.

@davidebeatrici :o what is the difference?

And what is the process for notarizing?

davidebeatrici commented 4 years ago

It's explained by @TerryGeng in the first message.

felix91gr commented 4 years ago

Ah, my bad. :bow:

billfehring commented 4 years ago

Have you considered applying to get a free Apple Developer account?

https://developer.apple.com/support/membership-fee-waiver/

Not sure if they give this to open source organizations or just not-profits. It's hard to claim that it is 'immoral' or there isn't a legitimate reason for Apple to verify that a real organization is behind this software versus Bob's Non-Profit (for you anyway) Malware LLC.

streaps commented 4 years ago

The problem is that Apple is forcing developers and users to use the App Store. It's only a matter of time until they lock out every app that is not downloaded from the App Store (IMHO). It would be morally less wrong, if they didn't put a 30% commission rate on everything. There is a reason the EU opened up an antitrust investigations into App Store practices.

"Nonprofit organizations, accredited educational institutions, and government entities" sounds like it would need a real organization in one of the eligible countries. Just because developers work on an open source project doesn't make it a non-profit organization. The need to create a non-profit organization or pay a $99 fee discriminates against the many open-source projects where a non-profit organization is more effort to create and run than it is worth.

Let's not forget that 3rd party apps on the iPhone 1 were web apps and Apple used a fork of KHTML to make that possible: https://www.apple.com/newsroom/2007/06/11iPhone-to-Support-Third-Party-Web-2-0-Applications/

Apple doesn't have any problems to benefit from open source projects and make a shitload of money, but they are to lazy, greedy or morally stupid to care about the developers and users of community-driven open source projects. Apple would have the resources to proactively look for solutions to these problems, but I guess they don't give a shit.

billfehring commented 4 years ago

The problem is that Apple is forcing developers and users to use the App Store. It's only a matter of time until they lock out every app that is not downloaded from the App Store (IMHO).

But they haven't yet -- and it seems kind of limiting to live in a world of what-ifs like that. You could always remove the app in retaliation as many other developers might at such a juncture.

It would be morally less wrong, if they didn't put a 30% commission rate on everything. There is a reason the EU opened up an antitrust investigations into App Store practices.

Well, if Apple wants to collect a 30 percent commission on a piece of free software, hopefully, they will at least give the other 70 percent to the project =P (Sorry, I couldn't resist.)

"Nonprofit organizations, accredited educational institutions, and government entities" sounds like it would need a real organization in one of the eligible countries. Just because developers work on an open-source project doesn't make it a non-profit organization. The need to create a non-profit organization or pay a $99 fee discriminates against the many open-source projects where a non-profit organization is more effort to create and run than it is worth.

Having now done this a few times myself (becoming a non-profit, that is), it's really not that hard nor time-consuming. With a sufficiently large community, those are the sorts of things you can delegate. In fact, having some kind of formality/governance is a good thing when, for example, the owner of the mumble.info domain name/GitHub account could rage-quit the project tomorrow over something like this discussion and shut it all down. If they were to do so, hopefully, the community has the legal recourse to rescue the project. You'll notice that several very successful open-source projects have gone in exactly this direction: https://opensource.com/resources/organizations

.. Just a thought. I have almost no skin in this game other than being a user at this time.

toby63 commented 4 years ago

https://developer.apple.com/support/membership-fee-waiver/

Interesting.

Creating an organisation:

it's really not that hard nor time-consuming. With a sufficiently large community, those are the sorts of things you can delegate.

That probably depends on the country. While I like this idea, it involves some work and money. You would need to decide what form of organisation you want to be and then decide and work on multiple things:

  1. Basic Agreements/Contracts (or similar)
  2. Verification (costs money)
  3. Board of Directors (or similar) and Votings
  4. Financial reports/Cash auditors (necessary in many countries, does not need to be an external professional, but someone has to do it and is liable for it (of course))
  5. Maybe necessary to communicate with state agencies for tax topics etc.

Also you would need to decide about the country where the organisation should be located, because as of now, there is for example no real european organisation besides the https://en.wikipedia.org/wiki/Societas_Europaea which is a form of company.

streaps commented 4 years ago

But they haven't yet -- and it seems kind of limiting to live in a world of what-ifs like that. You could always remove the app in retaliation as many other developers might at such a juncture.

If people accept any BS (pun intended) from Apple without any resistance, it's just a matter of when, not if.

Having now done this a few times myself (becoming a non-profit, that is), it's really not that hard nor time-consuming. With a sufficiently large community, those are the sorts of things you can delegate.

Mumble is open source software. If some wants to delegate it to themself, just do it.

fnordpig commented 4 years ago

I'm willing to donate $100 / year to see this notarized and in the app store. That seems like a small amount of money to greatly improve the distribution and security story for users of the mac. The notarization process and app store also lend a certain amount of security assurance to our users, and automatic updates, etc, which is all strictly value add stuff. If I amortize my $100 over all the users of Mumble and the new users of Mumble by making it easier to discover and manage, it feels like a better value than a meal for four at a restaurant.

Krzmbrzl commented 4 years ago

@fnordpig thank you very much for your generous offer. Could you please write a mail to contact[at]mumble.info so that we can talk about the details? :)

fnordpig commented 4 years ago

Hi, Update here myself and another donor gave $50 each to fund the app store certification costs.

davidebeatrici commented 4 years ago

Sorry, I should've posted an update here as soon as the Apple account was created (7th September).

I'm going to keep the issue open until Mumble 1.3.3 is released (signed with the new certificate and notarized as well).

Thank you very much for your donation!

Vaelatern commented 3 years ago

For whatever it's worth, I tried 1.3.3 on Catalina and was not allowed to open the binary.

davidebeatrici commented 3 years ago

The release was signed with the new certificate, but the notarization process apparently failed due to "hardened runtime" not being enabled for the binary.

With CMake enabling it seems to be straightforward: https://stackoverflow.com/a/56026083

dardevelin commented 3 years ago

could anyone update what is the current progress status on this issue ? any blockers I can possibly help with ? thanks in advance

Krzmbrzl commented 3 years ago

The new binaries are signed but in order to get it notarized we have to assemble a list of (I think) capabilities or permission requirements that Mumble needs. @davidebeatrici wanted to work on that. Idk what the exact status on that is though.

dardevelin commented 3 years ago

@Krzmbrzl Thanks for the update. I see that we have no updates from @davidebeatrici and maybe I missed but did not see any open branch about this changes either. if anyone has gone through the process and knows what needs to be done I am more then willing to put in the work

Krzmbrzl commented 3 years ago

@dardevelin I have just checked with him and no progress has been made on that front yet. So if you are willing to help us out here, we'd very much appreciate that :+1:

rootbeerdan commented 3 years ago

Happy to help out with this, not really sure why people think it's a bad idea to pay for something like this. This has been standard practice for macOS/Windows for many years.

Not paying or getting it signed is only hurting this project, we aren't sticking it to anybody but ourselves and end users. Anyone who wants to dip their toes in open source or bring their friends/family will immediately be turned off by having to bypass these very large and scary warnings, and then they have to attempt to convince everyone that their perfectly good chat application that doesn't have these big scary warnings is worse in some way.

What's the point of having this great open source project if all we're doing is pushing people to use closed source solutions?

Krzmbrzl commented 3 years ago

his has been standard practice for macOS/Windows for many years.

This does not make it any better.

not really sure why people think it's a bad idea to pay for something like this.

Because essentially this is blackmailing. And if you do pay, you basically legitimate this and if enough people do so you make sure that Microsoft/Apple/... will never stop this and thus make sure that other projects that refuse to be blackmailed will always suffer from these ridiculous warning messages.

Happy to help out with this

We'd appreciate that. As far as I can tell @dardevelin did not get to work on this yet, so the situation seems to be unchanged for now (we still need that permission list) :point_up:

davidebeatrici commented 3 years ago

Just to clarify: we are not complaining about the signing concept itself, but rather about the way Apple is enforcing it.

On Windows you can run unsigned applications without any extra steps, you just get a message about the publisher being unknown or a SmartScreen warning. Also, you can get a certificate from a third-party authority; for example, we got the one we're currently using from Certum.

On macOS you get a quite scary warning message that makes you think the application is probably insecure. Also, you have to pay for a developer account in order to create a signing certificate.

dardevelin commented 3 years ago

So far from what I understood it is necessary to bundle a Info.plist file which consists of an xml file. I haven't been able to test this against mumble per say, but so far I got this working with a python app that I have, which I convert into a .app

Notice I had to rename that file to.txt to upload here

Info.plist.txt

Next steps should be somewhere around shipping it either with the dmg or adding directly to the binary, which I am still investigating... if @rootbeerdan has ideas or experience, please don't stop because of me, as this is green field for me

fnordpig commented 3 years ago

Hi! I donated $50 to this, I am hoping that someone actually finishes it? It's sort of disappointing to check back on this issue to see if someone is paying to notarize the build or not again, and if not I was going to offer to help again. But this is very sad - it's a bunch of belly aching about Apple ratcheting up the default security posture of their operating system for inexperienced users - note all I have to do to bypass this is hold option down when I open it the very first time - it's not hard to bypass their restrictions, you just need to know the keystroke. If you're knowledgable enough to know a key stroke presumably you're knowledgable enough to understand what holding the keystroke means as far as security goes. But with journalists being attacked by nation states using their products, and journalists are not necessarily developing on mumble and rebuilding from source or whatever - they stand to be very easily compromised if they used mumble without notarization. Or, how about gamers in China, or North Korea, etc, who stand a strong chance of MitM attacks by their own country? Why can't you just type in whatever needed to be typed in? Do you need me to type something in?

Krzmbrzl commented 3 years ago

Again: This is not about Apple showing a warning for unsigned binaries. It's about Apple only accepting certificates that they themselves sell at whatever price they want. They are self-creating a monopoly here and thereby blackmailing developers to give them their money. That's where the issue lies.

On the note of your donation: This has been used to create an Apple developer account that we now use to sign the Apple binaries. Notarization requires more work to be done for creating a list of required permissions or something like that. @davidebeatrici still has that on his ToDo list.

davidebeatrici commented 3 years ago

Notarization has nothing to do with security, it's just an excuse for Apple to analyze every single package that developers want to publish.

Our packages are signed and a valid signature is what determines that a file has not been tampered with.

In fact, our main reason for creating an Apple Developer ID was to get a signing certificate (we were using @mkrautz's before).

dardevelin commented 3 years ago

To be honest discussing signing versus notarization is kind of useless. I believe the primary goal was a Mac user is able to download run the app without concern with a better perceived user experience.

Who’s fault is that, does it matter if the goal is to support the users on the platform ?

Unless the goal here is to stop supporting Mac all together.

Linux approach is not that different , the steps required when the package comes from out the district are higher.

If the user experience does not matter, oh well …

On Wed 2. Jun 2021 at 21:27 Davide Beatrici @.***> wrote:

Notarization has nothing to do with security, it's just an excuse for Apple to analyze every single package that developers want to publish.

Our packages are signed and a valid signature is what determines that a file has not been tampered with.

In fact, our main reason for creating an Apple Developer ID was to get a signing certificate (we were using @mkrautz https://github.com/mkrautz's before).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mumble-voip/mumble/issues/4263#issuecomment-853325092, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAK32Y6EG6XZC2SMUAT6UM3TQ2AY3ANCNFSM4NXJBBHQ .

davidebeatrici commented 3 years ago

Basically the entire project revolves around user experience, but our OS priority currently goes like this:

  1. Windows
  2. Linux and true UNIX in general
  3. macOS

We are going to release 1.4.0 soon and thus wanted to make sure that there are no critical issues for the other platforms first.

Now that we pretty much did that, we can dedicate time to finally get notarization to work.

The Linux approach is very different, because basically all Linux distributions provide a package manager. macOS doesn't, which is why Homebrew is a must have for developers.

I actually just realized there's already a cask for Mumble: https://formulae.brew.sh/cask/mumble

davidebeatrici commented 3 years ago

With CMake enabling it seems to be straightforward: https://stackoverflow.com/a/56026083

Turns out that's only for generating an XCode project that passes the --options runtime option to codesign.

https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues

davidebeatrici commented 3 years ago

@fnordpig To be clear: it's my fault for not checking earlier (that is, before accepting the donations for creating the account) that additional steps are required in order to get the package notarized and you're right in complaining about that not being done yet, sorry about that.

When writing https://github.com/mumble-voip/mumble/issues/4263#issuecomment-853325092 I just focused on explaining that signing and notarization are two very different concepts and that the donations were not wasted: the account is actively being used to sign binaries.

With that being said, I'm working on getting notarization to work.

fnordpig commented 3 years ago

Doh! I'm sorry. Peace and love.

davidebeatrici commented 3 years ago

No worries, it's absolutely fine!

5093 adds the entitlement plist, which can be used as follows:

codesign --deep --sign <developer ID> --options runtime --entitlements src/mumble/mumble.entitlements.plist build/Mumble.app

Everything seems to be working.

fnordpig commented 3 years ago

Btw, I dropped a bounty source to cover next year in $5 chunks

davidebeatrici commented 3 years ago

Awesome, thank you very much!

Krzmbrzl commented 2 years ago

The latest build has now been notarized

GDur commented 2 years ago

This helped me:

  1. Open Finder.
  2. Locate the app you’re trying to open. (Mumble)
  3. Control+Click the app.
  4. Select Open.
  5. Click Open.
  6. The app should be saved as an exception in your security settings, allowing you to open it in the future.
dardevelin commented 2 years ago

This helped me:

  1. Open Finder.

  2. Locate the app you’re trying to open. (Mumble)

  3. Control+Click the app.

  4. Select Open.

  5. Click Open.

  6. The app should be saved as an exception in your security settings, allowing you to open it in the future.

I know you are trying to be helpful. But mumble releases have started being notarized for a while now. This problem is thus fixed.

On another note albeit you may feel that it's helpful to recommend marking the app as an exception to the security policy, it's bad practice. It teaches the behavior to break the protection in place and it's a bad user experience.

Krzmbrzl commented 2 years ago

@dardevelin what you are saying is incorrect.Mumble builds are no longer notarized. Apple has essentially screwed us over by always blocking the notarization process for one reason or another and therefore it was always really painful to draft releases that were supposed to get notarized. And as it was time to renew our certificate, we decided to not do that and as a consequence don't notarize any future Mumble builds.

Therefore, the steps mentioned are indeed necessary to get around Apple's ridiculous "security" feature.