Notarizing the mac build

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

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

zip our Mumble.app container, then
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.
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.
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.

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

@TerryGeng

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 ☝️

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

@Krzmbrzl

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

@Kissaki

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

Would that even be big enough to be readable? 🤔

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

@mkrautz

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.

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.

@mkrautz

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

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

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

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

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

Exceptions regarding fees for open source projects like yours.
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.

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.

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.

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

@dardevelin

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

Ok thanks I officially will stop using mumble had enough with the years. So long and thanks for all the fish

@dardevelin

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

Ok thanks I officially will stop using mumble had enough with the years. So long and thanks for all the fish

Thats really childish, not the Mumble Team is to blame here, it is Apple.
If you are not clever enough to see why Apple does this, here is the theory: They want to push their own stuff, so Open Source Applications of all kinds are in the way.

@toby63

@toby63 I don't believe it's childish to acknowledge that there is no interest in notarising the APP and that I shouldn't be waisting your time in continuously attempting to see it done.

I have seen more "text" written about how "evil of apple, how bad of apple" than "search of solutions".

I recall when this community had a collaborative spirt, this would back then be a challenge to be solved as team.
Someone would post the flag, communicate the barriers, others would come and join to find solutions together as team.
Nowadays, the attitude is "Your use case is hard" screw it, go unserved.

This is in no way an isolated matter either, the "fights over automatic gain control" that it was pure insistence, despite a large part of the community wanting "local volume adjustment" as an option not even as a replacement. That discussion "forget the implementation" took years.

In this thread, first it was "oh the Tax" people are like I am happy to give the money if that's the obstacle.
It moved into "we didn't have time" to make it to this release "when releases are essential "free" when you already build nightly anyways". And after 1 notarised year "let's throw away the learnings about notarisation" and screw the users that actually need it.

But you are right I am childish. Thanks

You do you.
But a few answers to what you said:

when releases are essential "free" when you already build nightly anyways"

They would be if you didn't have to mess with all this signing stuff that works completely different for every platform. That's actually quite time consuming, especially on macOS where the flags that you used last time don't work anymore, because now you have to agree to some new terms but where you can do this, you'll have to find out first, which again takes time. And this every time.

And after 1 notarised year "let's throw away the learnings about notarisation"

It was a test to see if we can make it work properly and the test showed: no we can't.

I recall when this community had a collaborative spirt, this would back then be a challenge to be solved as team.

Well then please go ahead and volunteer to take care of the macOS signing. We can provide you with the built binaries and you can can do all the signing related stuff. Then we can upload that as the official release to our website. If this process "is essentially free" anyway, it shouldn't be that much of a burden on you.

And then a few words in general: people often seem to forget that everyone working on Mumble generally does this in their free time and everything you do get from us developers is due to us spending our free time and offering the result for free. Therefore, this attitude of "you owe us xy" is completely ridiculous. If you really want something implemented in Mumble that badly, take some money in the hands and hire a developer to do it for you (if you can't do it yourself). Then, and only then, do you have the right to demand things from a developer. In every other situation you are more than welcome to voice suggestions or constructive criticism or contribute yourself. But that's it.

You do you.
But a few answers to what you said:

when releases are essential "free" when you already build nightly anyways"

They would be if you didn't have to mess with all this signing stuff that works completely different for every platform. That's actually quite time consuming, especially on macOS where the flags that you used last time don't work anymore, because now you have to agree to some new terms but where you can do this, you'll have to find out first, which again takes time. And this every time.

And after 1 notarised year "let's throw away the learnings about notarisation"

It was a test to see if we can make it work properly and the test showed: no we can't.

I recall when this community had a collaborative spirt, this would back then be a challenge to be solved as team.

Well then please go ahead and volunteer to take care of the macOS signing. We can provide you with the built binaries and you can can do all the signing related stuff. Then we can upload that as the official release to our website. If this process "is essentially free" anyway, it shouldn't be that much of a burden on you.

And then a few words in general: people often seem to forget that everyone working on Mumble generally do this in their free time and everything you do get from us developers is due to us spending our free time and offering the result for free. Therefore, this attitude of "you owe us xy" is completely ridiculous. If you really want something implemented in Mumble that badly, take some money in the hands and hire a developer to do it for you (if you can't do it yourself). Then, and only then, do you have the right to demand things from a developer. In every other situation you are more than welcome to voice suggestions or constructive criticism or contribute yourself. But that's it.

Precisely for understanding the latter I said I will not use it any longer. In respect of your unwillingness to do it and not having time to commit to do it myself.

I have spent time contributing to Foss, including gcc , Linux kernel, Qt, VLC, and so many other gnome apps.

In the past, also contributed to mumble by finding and propose fixes to security vulnerability along with friends.

Which required me to consult a lawyer to make sure I wouldn't be breaching contract. (That's quite expensive FYI).

Those are efforts I put in which I don't "need" a pat on the back for, just mentioning because I am not just another "whinny" user that demands something for free. I simply pointed out that with that decision I can no longer use mumble. I believe in feedback and "highlighting what are the reasons to stop using the project" are helpful to "grow understanding of what people value"

Yet what did I get being called "childish" ... if am "cleaver enough".

Attempt high ground Shame, but "open source" while using GitHub over Gitlab, azure over open suse service or canonical or even redhat. Supporting windows as first platform over and ahead of Linux.

Do you at least acknowledged that it's not a very good argument to make ?

I'm not criticising you for your original statement that you will quit using Mumble. That much is absolutely your choice and stating the reasons for it is also fine.

I don't agree with the statement of you being childish because of this.

My comment was targeted towards what has been said in your reply to toby.

Attempt high ground Shame, but "open source" while using GitHub over Gitlab, azure over open suse service or canonical or even redhat. Supporting windows as first platform over and ahead of Linux.

Do you at least acknowledged that it's not a very good argument to make ?

I do not. Because I don't see how what I said can be put into this context. I don't think I argued that the way we do things is the ultimate and only correct way of doing open source, so I don't see what you are getting at here.

In any case case, I think everything worth saying has been said now and continuing this discussion is probably pointless. 🤷

@Krzmbrzl

Yet what did I get being called "childish" ... if am "clever enough".

I feel the need to clarify that I am not a part of the Mumble team, so as @Krzmbrzl pointed out, no one from the Mumble team said that to you, but I did 😉.
I think its your own fault using an OS thats a golden cage, yet you blame others.
Write to Apple and complain to them.

Mm. Supporting windows first is what makes sense here.

Largest use case is gamers, and games are still a windows-first endeavor
C++ makes it hard to equally support different platforms. Remembering that this is a community effort is very important here – every extra effort is provided through pure volunteer's care. I'm thankful for linux support being as good as it is. I have no complaints :)

If I understood correctly, Apple users who wish to have a notarized version available just need to hire someone new to trust and to take care of the notarizing process for the rest of the Apple users community?

Yeah. We would gladly cooperate with anyone that wants to take up the signing process.

@Krzmbrzl

Mm. Supporting windows first is what makes sense here.

Largest use case is gamers, and games are still a windows-first endeavor

Right.

C++ makes it hard to equally support different platforms. Remembering that this is a community effort is very important here – every extra effort is provided through pure volunteer's care. I'm thankful for linux support being as good as it is. I have no complaints :)

C++ actually helps a lot, especially when it comes to abstraction. The Host{Linux,Windows} and Process{Linux,Windows} classes (used by positional audio plugins) are a great example of that.

The difficulty mostly consists in interfacing with whatever API the operating system provides.

And this is where the trouble begins on macOS, especially since Apple is firm on using Objective-C.

If I understood correctly, Apple users who wish to have a notarized version available just need to hire someone new to trust and to take care of the notarizing process for the rest of the Apple users community?

@Krzmbrzl and I poured plenty of hours into modifying our signing script(s) to make them work for notarization. We succeeded and released notarized binaries for a while, as promised (we received an explicit donation for an Apple Developer subscription).

The original idea was to proceed on that route, renewing the subscription ourselves every year, but the will to do so gradually decreased because every single time we wanted to produce the binaries we ran into at least one new issue and had to spend a substantial amount of time in order to troubleshoot it and find a solution or perhaps even a workaround.

@dardevelin I like challenges and I'm pretty sure @Krzmbrzl does too. We have always been trying to support at least the major operating systems while making the experience as flawless as possible for our users.

But when we realize a specific OS is being locked down on purpose by the company that owns it, we honestly just don't see the point in supporting their software (and in turn business) anymore.

In any case, the experience we gained is not wasted and the relevant signing script is in our repository: https://github.com/mumble-voip/mumble/blob/bf4ad2bc72b5a8a5d4e2c610dbae1fdfcb3a1bc3/scripts/sign_macOS.py

Yeah. We would gladly cooperate with anyone that wants to take up the signing process.

Important note to anyone willing to do so: from experience, as mentioned several times, it can be a time consuming task.

For that reason, it would be ideal if you're already familiar with the overall signing and notarization process.

we honestly just don't see the point in supporting their software (and in turn business) anymore.

Just to clarify: We are not dropping macOS support as a whole. This "support" Davide referred to was targeted towards following the best practices for releasing software on that OS.

Found a workaround, hat tip to this stack overflow poster

xattr -d com.apple.quarantine mumble-server-binary

The signing step is fine, but the notarization example is outdated.
xcrun altool is now deprecated. Apple’s current recommended workflow uses xcrun notarytool.

Instead of uploading with altool and polling manually, the modern flow is simply:
• Zip the signed app
• Submit it using xcrun notarytool submit --wait
• Attach the ticket with xcrun stapler staple

This can also be fully automated on a macOS CI runner (for example GitHub Actions), even if development is done on Windows.

Navigation Menu

Repository navigation

Notarizing the mac build #4263

44 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Notarizing the mac build #4263

Description

Activity

streaps commented on Jun 7, 2020

Krzmbrzl commented on Jun 7, 2020

TerryGeng commented on Jun 7, 2020

Krzmbrzl commented on Jun 7, 2020

davidebeatrici commented on Jun 7, 2020

Avatat commented on Jun 8, 2020

Krzmbrzl commented on Jun 8, 2020

davidebeatrici commented on Jun 8, 2020

toby63 commented on Jun 8, 2020

Kissaki commented on Jun 8, 2020

Kissaki commented on Jun 8, 2020

Kissaki commented on Jun 8, 2020

44 remaining items

dardevelin commented on Oct 29, 2022

toby63 commented on Oct 29, 2022

dardevelin commented on Oct 29, 2022

Krzmbrzl commented on Oct 29, 2022

dardevelin commented on Oct 29, 2022

Krzmbrzl commented on Oct 29, 2022

toby63 commented on Oct 29, 2022

felix91gr commented on Oct 29, 2022

InTheMorning commented on Oct 29, 2022

Krzmbrzl commented on Oct 30, 2022

davidebeatrici commented on Oct 30, 2022

Krzmbrzl commented on Oct 30, 2022

sysfu commented on Feb 21, 2024

nissaba commented on Jan 4, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions