audacity: sign app on darwin>=22

[i0ntempest]

Description

Type(s)

• bugfix
• enhancement
• security fix

Tested on

macOS x.y
Xcode x.y / Command Line Tools x.y.z

Verification

Have you

• followed our Commit Message Guidelines?
• squashed and minimized your commits?
• checked that there aren't other open pull requests for the same change?
• referenced existing tickets on Trac with full URL in commit message?
• checked your Portfile with port lint --nitpick?
• tried existing tests with sudo port test?
• tried a full install with sudo port -vst install?
• tested basic functionality of all binary files?
• checked that the Portfile's most important variants haven't been broken?

[macportsbot]

Notifying maintainers:
@mohd-akram for port audacity.

[mohd-akram]

Why is this needed?

[i0ntempest]

New macOS versions want all apps signed unless you disable SIP, if an app isn't signed it can have a number of problems, from firewall and privacy popup on every launch (like my qBittorrent port) to crashing on start (had this problem with some other ports before but can't remember).
Not sure starting from which version but I sign all my ports that install an app bundle on darwin>=22.

[mohd-akram]

I think only Apple Silicon always requires signatures (and it gets signed automatically when compiling). On Intel I haven't seen an issue. I'm not sure if an ad-hoc signature is worth much in macOS.

[i0ntempest]

Yes, because macOS on ASi signs all the codes some of the problems are mitigated. It's on Intel where the problems I mentioned (popups) really are an issue.
It's your choice, but I don't think signing the app hurts in any way.

[markemer]

New macOS versions want all apps signed unless you disable SIP, if an app isn't signed it can have a number of problems, from firewall and privacy popup on every launch (like my qBittorrent port) to crashing on start (had this problem with some other ports before but can't remember). Not sure starting from which version but I sign all my ports that install an app bundle on darwin>=22.

I had this issue with chezmoi for a while during the beta where it was killed because the signing was bad, and I had to resign it to fix it - thankfully that seems to have cleared up as it was a compiler bug, but yeah - I can't seen the harm here.

[ryandesign]

Are you saying we should add code to each port individually to sign its files? That seems like a lot of work. Is there no way to do it centrally in MacPorts base?

CI failed on Intel machines:

DEBUG: system -W /opt/local/var/macports/build/_Users_runner_work_macports-ports_macports-ports_ports_audio_audacity/audacity/work/destroot/Applications/MacPorts: /usr/bin/codesign --sign - Audacity.app
Audacity.app: code object is not signed at all
In subcomponent: /opt/local/var/macports/build/_Users_runner_work_macports-ports_macports-ports_ports_audio_audacity/audacity/work/destroot/Applications/MacPorts/Audacity.app/Contents/MacOS/Audacity
Command failed: /usr/bin/codesign --sign - Audacity.app
Exit code: 1
Error: Failed to destroot audacity: command execution failed

[i0ntempest]

Are you saying we should add code to each port individually to sign its files? That seems like a lot of work. Is there no way to do it centrally in MacPorts base?

CI failed on Intel machines:

DEBUG: system -W /opt/local/var/macports/build/_Users_runner_work_macports-ports_macports-ports_ports_audio_audacity/audacity/work/destroot/Applications/MacPorts: /usr/bin/codesign --sign - Audacity.app
Audacity.app: code object is not signed at all
In subcomponent: /opt/local/var/macports/build/_Users_runner_work_macports-ports_macports-ports_ports_audio_audacity/audacity/work/destroot/Applications/MacPorts/Audacity.app/Contents/MacOS/Audacity
Command failed: /usr/bin/codesign --sign - Audacity.app
Exit code: 1
Error: Failed to destroot audacity: command execution failed

CI failed because I didn't add --deep, will fix later.
Someone is reportedly working on a xcode-1.1 pg and code signing can be handled there, for ports that use Xcode. For port that does not but still install apps like this one, I'm not sure.

[ryandesign]

Someone is reportedly working on a xcode-1.1 pg and code signing can be handled there, for ports that use Xcode. For port that does not but still install apps like this one, I'm not sure.

I encountered the problem with Python. It sounds like really all code needs to be signed. I've opened https://trac.macports.org/ticket/70945.

[markemer]

Someone is reportedly working on a xcode-1.1 pg and code signing can be handled there, for ports that use Xcode. For port that does not but still install apps like this one, I'm not sure.

I encountered the problem with Python. It sounds like really all code needs to be signed. I've opened https://trac.macports.org/ticket/70945.

That someone is me, although I wasn't in a huge rush. Signing was kind of an afterthought from my iTerm2 problems, but I'm dealing with things that build xcworkspaces and use spm as well. But with a problem like this, it probably should be in base.

But, I didn't think we'd have to sign everything, though but it's starting to look more and more like the case, for a lot of weird situations like using the network. This is pretty annoying. I think I may have missed a lot of the issues because I don't have any Intel machines on 15 yet (or ever at this rate).

[mohd-akram]

CI failed because I didn't add --deep, will fix later.

Per the codesign man page, --deep is deprecated and can even block the program from running according to an Apple engineer.

[i0ntempest]

This PR is now ready - sorry for taking to long I completely forgot about this.
If we don't use --deep we would have to maintain a list of executables to sign. This list should not change frequently but if it does change, when some signed code calls unsigned codes, bad things will happen.

[mohd-akram]

@i0ntempest No worries, but I still want to understand what problem specifically this is solving. What is the error you get without signing?

[i0ntempest]

@mohd-akram This is mainly for Intel users, because codes on arm are automatically signed.
Calling unsigned code from signed code will result in something like this
Completely unsigned apps will have the following issues:

1. (Might) crash on start. (I have run my system with SIP off (specifically signing enforcement) for years now and I don't really know what modern macOS on Intel will do to unsigned code if SIP is active)
2. If the app connects to the internet and the user has enabled firewall, firewall prompt will appear on every start of the app (happened with Transmission).
3. The app cannot be added into privacy settings (Accessibility and microphone access etc.), or can be added but ineffective.
4. As Ryan mentioned in his new ticket above, the app will be prohibited to connect to local network devices, which is now controlled by privacy settings.

Loads of code signature related issues can be found of trac, like this.

Also side note: Homebrew Cask now requires all apps to be signed and notarized to be accepted into the Cask repo.

[mohd-akram]

@i0ntempest The fix for Transmission was to disable signing though, since it was signed and was built with a hardened runtime but its libraries weren't. Like @jmroot mentioned in the ticket, you either sign everything properly, or don't sign at all. We don't sign everything on macOS on Intel, so I don't think it makes sense to do it per-port. I'm open to the PR if there's something specifically wrong with Audacity currently that can be fixed by this, but otherwise IMO we should park it until then.

Also side note: Homebrew Cask now requires all apps to be signed and notarized to be accepted into the Cask repo.

That makes sense for them since Casks are just republished assets. Personally, even though I maintain this port, I don't really install macOS .app applications with MacPorts - it just doesn't align well with how macOS wants things. Just download from the App Store or the developer's website, they all have auto-update built-in now too so it's not an issue.

[i0ntempest]

@mohd-akram That commit message is incorrect - signing wasn't disabled for Transmission, hardened runtime was disabled because it forbids loading unsigned external code, that's all. The app is still signed.
But I'm okay with waiting a bit for this one.

[reneeotten]

there hasn't been any activity here for several months. What's the status - the PR queue isn't intended for keeping unfinished/undecided stuff forever. Please decide what needs to be done here, or I will close the PR after the weekend.

[i0ntempest]

This is ready for merge since ages ago and has no side effects.

[reneeotten]

This is ready for merge since ages ago and has no side effects.

well, from a cursory look through the discussion there doesn't seem to be consensus that this is actually needed and/or if it should be done specifically on a per-port basis or somewhere in macports-base.
Regardless, somewhere you say this is only needed for Intel machines; in that case the whole block of added code should likely be conditional.

[i0ntempest]

somewhere you say this is only needed for Intel machines

Linker on Apple Silicon does automatically sign binaries but it's still different from properly signing, even for adhoc. We should be signing app bundles on newer macOS, regardless of the platform.

[mohd-akram]

I'm open to the PR if there's something specifically wrong with Audacity currently that can be fixed by this, but otherwise IMO we should park it until then.

Since my comment, there haven't been any tickets raised regarding this, so IMO we can close this PR for now.

[i0ntempest]

If you want. But any unsigned code involving GUI is a tickling time bomb now.