flameshot-org
Notarize macOS binaries and installers
Feature Description
I propose signing Mac binaries and installers, so users don't have to deal with security overrides.
Current unsigned installation workflow looks a bit rough:
In this issue, I'm not suggesting publishing Flameshot in the Apple Store. This could be a separate goal. I'm sure a community of that size could help through donations https://github.com/sponsors . Could you configure it?
Here, I'm suggesting obtaining a signing certificate to sign assets distributed via the homebrew and directly from github.
I'll preface this with the fact that I am not at all an expert on MacOS. However I researched this earlier in the year because our v12.1 release flat out refused to run on apple silicon and traced it to a code signing issue.
In this PR I fixed code signing. Without this fix a dmg built on my PC will not run on your PC at all. Note it uses an ad-hoc signature, not a paid signature tied to my apple ID.
In order to remove the security warning on MacOS the application needs to be both signed with a paid developer ID and notarized. In order to get a developer ID certificate I would need a paid Apple Developer account. I am unaware of any way to remove that security warning without paying.
Reference: https://armaan.cc/blog/signing-and-notarizing-macos
We have discussed github sponsors before and the team decided we don't want to accept monetary donations (outside the scope of this discussion, but it's not an option).
On windows SignPath generously sponsors signed windows builds with their CI pipeline. If we can find someone to do that on MacOS that would be the best option.
Current Situation
In general accepting donations has lots of complications especially with tax authorities. So far all the costs of Flameshot are either paid out of our own pockets (e.g., domain), or paid by sponsors (e.g., SignPath).
My personal philosophical dillema
Considering that the project is free (in any conceivable definition of the word) for the users, and so far throughout the years the devs have bared all the costs apart from the volunteer work, I'd say this is something that macOS users can help provide for the project that ultimately benefits themselves. I personally cannot comprehend why a FLOSS project should pay money out of their devs pocket annually to a FAANG company to get a virtual Monopoly tag just to satisfy the conditions of preferred non-FLOSS OS of hundreds (if not thousands) of users. Some devs in FLOSS realm might happily pay the Apple Tax, but I'm not in that camp.
Potential solution
I have also searched and have only seen that people talk about Paid Developer ID. If that's the situation, then we would need a sponsor for Apple-signing sponsor.
Considering that NameCheap is our sponsor (because as far as I remember they use Flameshot in their operations and they initially helped getting the Flameshot working on Mac, perhaps we can ask them if they want to help us through this as well. I'm not sure if @panpuchkov still works in that position and if he can give us some insights.
@mmahmoudian
Namecheap has its version of Flameshot, as the community didn't want to accept everything that Namecheap needed, which is the only reason.
Technically, I can build a signed version of the community's version of Flameshot for macOS. However, I am unable to share these keys and integrate them into the community's CI/CD pipelines. I can routinely build a macOS version for new releases of the community edition, but not for all intermediate builds.
I don't see strong arguments for the management on why Namecheap need to sponsor an Apple account for the community when the releases are not often.
Is there a way to consolidate versions and streamline the release process? If you're using a software HSM module, perhaps you could share the API key with core team, so they can sign oss artifacts as part of the release process?
@panpuchkov thanks for the response. I didn't remember that NameCheap has its own fork. Thanks for reminding me and the explanation.
Of course Flameshot is a fully voluntary project and consequently it will have releases when we have enough change and enough reason to have a new releases, which so far have been infrequent. And it make sense that as a sponsor, paying Apple tax for infrequent releases doesn't make much sense.
I don't know if Homebrew policy accepts downloading.dmg from release rather than git commit, but I like offer of signing releases.
@borgmanJeremy what do you think? Would you rather have a sponsor to integrate everything in CI or would this ad-hoc signing suffice?
The package is signed now. Its just not signed with a paid developer account. The old version was NOT signed which is why the deprecation was added. This is no different than many other MacOS applications installed via brew (notably joplin).
Okay, shall I drop a PR in to remove the deprecation note in Homebrew in that case?
@tomtastic please read this:
https://github.com/Homebrew/homebrew-cask/issues/222922
@mmahmoudian, I believe @tomtastic is suggesting the removal of deprecation line from the formula. I'm concerned that the issue you've referenced won't resolve deprecation without a PR.
Is there a way to consolidate versions and streamline the release process? If you're using a software HSM module, perhaps you could share the API key with core team, so they can sign oss artifacts as part of the release process?
The security department will never allow me to share any keys, even if it looks safe now, as it increases the potential attack vector. It's hard to predict what legal abuse could happen if someone signs with these keys a malware.
@a-b
@mmahmoudian, I believe @tomtastic is suggesting the removal of deprecation line from the formula. I'm concerned that the issue you've referenced won't resolve deprecation without a PR.
As far as I understand, that deprecation line will not go away unless and until we have a notarized app. That's why I linked to that issue that I opened in Homebrew, because it contains the responses from Homebrew devs.
@panpuchkov, you might consider creating a separate repository managed by your company that uses a workflow to track a specific tag or label in the https://github.com/flameshot-org/flameshot/ repo, then downloads and signs Mac artifacts. The flameshot release process would wait for these signed artifacts to be published before downloading and adding them to the release. This approach would ensure transparency and safety.
The idea is good in theory, but I don't see any sense in spending time on it now. Our releases are not frequent, and I can manually trigger builds when required. What I see right now is that there is no Notarization in the community edition, and the workflow has been changed. I need to update everything and make it work first. Then we can check how it works and probably think about the automation.
If someone else stumble into this issue after updating the app to the latest version, you might have a similar issue to mine on macOS.
If you are able to open the app but your screen appear to be empty when taking a screenshot (meaning, all windows are transparent and only the desktop background is visible), try this:
- Go to System Settings > Privacy & Security > Screen & System Audio Recording
- Select Flameshot (the row itself, not the toggle) and click the "-" (minus) button under the table
- Quit and relaunch Flameshot to trigger the security dialog boxes (you should have two prompts back to back)
- Once you have accepted both prompts and relaunched Flameshot, taking screenshots should work as expected
@a-b what @pgrenaud mentioned is already in our documentation:
https://flameshot.org/docs/guide/troubleshooting/#all-opened-applications-go-away-and-only-the-blank-desktop-is-visible-for-selection
Is there any part that is missing from the link above? If so, let me know and I'll update it (or you can send a PR if you feel like it :) )
@a-b what @pgrenaud mentioned is already in our documentation:
https://flameshot.org/docs/guide/troubleshooting/#all-opened-applications-go-away-and-only-the-blank-desktop-is-visible-for-selection
Is there any part that is missing from the link above? If so, let me know and I'll update it (or you can send a PR if you feel like it :) )
That is my bad. I only checked the README thinking it was an install issue at first.
Only thing that I see different in the doc is that I never had to reboot to make it work. Besides that, the steps are pretty much the same.
The package is signed now. Its just not signed with a paid developer account. The old version was NOT signed which is why the deprecation was added. This is no different than many other MacOS applications installed via brew (notably joplin).
As per my understanding, Joplin app is notarized on Macos. The problem is that in the future MacOs will require all apps to be notarized and will remove the option to skip the gatekeeper.
2. Select Flameshot (the row itself, not the toggle) and click the "-" (minus) button under the table
Thank you so much @pgrenaud - this was driving me nuts and this is the crucial step! (I didn't notice that you can remove the app from that list before and I was granting/removing permissions ad nauseum)
