Remove unsigned apple silicon builds

[badonyx]

Important: Do not tick a checkbox if you haven’t performed its action. Honesty is indispensable for a smooth review process.

In the following questions <cask> is the token of the cask you're submitting.

After making any changes to a cask, existing or new, verify:

• The submission is for a stable version or documented exception.
• brew audit --cask --online <cask> is error-free.
• brew style --fix <cask> reports no offenses.

The Apple Silicon builds for these apps are not functional so only the Intel build should be used.

Context: https://github.com/orgs/Homebrew/discussions/3088#discussioncomment-7623916

[alexreg]

This seems like a far from ideal solution, given it renders ARM Mac users "second-class citizens"... though I appreciate why you want to do this nonetheless. Let's see how the maintainers reply to this comment about creating their own certificate authority? Alternatively, we could just add a note to the cask to instruct ARM users to self-sign the installed app?

[razvanazamfirei]

I think the more obvious solution is for upstream to sign their binaries.

[SMillerDev]

Yeah, I see two solutions here.

1. You instead contact upstream about signing all their binaries because it doesn't work well on arm otherwise.
2. We deprecate these calls with a message they don't work well on modern macs.

I'd say the first option should be done either way.

[krehel]

Signing would be the most appropriate to get working binaries for Apple Silicon, as others mentioned.

I can agree with removing currently broken builds that can have negative user experience impact. I don't know if it requires a special caveat beyond the normal requires_rosetta though.

[MikeMcQuaid]

Not gonna ✅ because I don't feel I have sufficient authority on this repo but: I think this is what should be done here. To not do so feels like we're implicitly encouraging the disabling of security features.

[p-linnane]

All new Mac devices are using Apple Silicon. We should prioritize the Homebrew experience for those devices. I'm fine requiring Rosetta here since upstream refuses to sign their binaries.

[alexreg]

All new Mac devices are using Apple Silicon. We should prioritize the Homebrew experience for those devices. I'm fine requiring Rosetta here since upstream refuses to sign their binaries.

There's a significant efficiency hit however.

[p-linnane]

There's a significant efficiency hit however.

There is, but that is because of choices made by the actual upstream. By not signing their binaries, they are giving their own users a poor expereince. Homebrew will not recommend circumventing Apple's native security mechanisms to accomodate developers who choose to not fully support macOS.

[MikeMcQuaid]

There is, but that is because of choices made by the actual upstream. By not signing their binaries, they are giving their own users a poor expereince. Homebrew will not recommend circumventing Apple's native security mechanisms to accomodate developers who choose to not fully support macOS.

Strongly agreed.

[alexreg]

Strongly agreed.

As stated, their reason is because they don't want to attach their identity to a signing certificate. That said, I've suggested they create their own certificate authority, which users can manually trust. Probably the next best thing. Let's see if they go that way.

[SMillerDev]

That said, I've suggested they create their own certificate authority, which users can manually trust. Probably the next best thing. Let's see if they go that way.

I'm pretty sure macOS won't

[alexreg]

I'm pretty sure macOS won't

MacOS won't trust it? It's worked for me before, when building my own apps. You just have to go into Keychain Access and select to manually trust it.

[MikeMcQuaid]

You just have to go into Keychain Access and select to manually trust it.

Unless this is securely integrated into the brew --cask install flow: this will cause more problems for us than it will solve.

[alexreg]

You just have to go into Keychain Access and select to manually trust it.

Unless this is securely integrated into the brew --cask install flow: this will cause more problems for us than it will solve.

I disagree, but I'll look into automating it with a script regardless, since that would be nice.

[badonyx]

I will point out that lidarr was already being distributed this way on homebrew, it just was not marked as such. To be consistent either lidarr should have the arm build added, or radarr and prowlarr should have the arm builds removed. (sonarr does not distribute an arm build so I only added the required rosetta caveat.)

If upstream starts signing their builds then the arm builds could be added back, no big deal.

The caveat text feels a little unnecessary, maybe a simple (ruby) comment linking to the discussion would suffice?

[alexreg]

@badonyx FYI Sonarr will start releasing ARM builds when v4 comes out (which is based on .NET Core). Not sure exactly that will be, but it is already in beta at least...

[MikeMcQuaid]

I will point out that lidarr was already being distributed this way on homebrew, it just was not marked as such.

@badonyx stupid question, sorry: what is "this way"?

If upstream starts signing their builds then the arm builds could be added back, no big deal.

Agreed 👍🏻

[bevanjkay]

✅ From me, my only question would be around the wording of the caveat. Should we be more explicit about the issue rather than just saying that the build is "not functional", mention that the app is not signed and ask the developer to sign it?
Also should the caveat go in an on_arm block?

[badonyx]

what is "this way"?

An unsigned arm build is available upstream but only the intel build is available from homebrew-cask.

[SMillerDev]

I find it much more likely that nobody added it yet than that it was intentionally done like this to avoid codesigning issues.

[MikeMcQuaid]

An unsigned arm build is available upstream but only the intel build is available from homebrew-cask.

Gotcha, thanks. To agree with @SMillerDev and @bevanjkay: we intentionally do not want to attempt to distribute unsigned ARM builds.

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.