macOS pex SCIE is not code signed, so macOS tries to convince me to not run it

[tdyas]

The macOS SCIE for Pex (for example, this one) is not digitally signed via Apple's codesign (or other applicable tool).

This is an issue because macOS 15.1.x really goes to great lengths to dissuade users from running such binaries. This will be a negative UX issue for Pants if Pants downloads a SCIE of Pex to use it. Users likely will not know why macOS is showing these modals in that case, which could erode user trust and moreover prevent Pants from using the Pex SCIE since the user may not go through three modals and/or even find the approval button in the security settings.

What macOS does:

1. First, it shows a modal where the only two choices are to close the modal or move the file to the trash. Notably, no mention is made in the modal of how to approve the binary in the Security pane of the System Settings.

2. Next, even after approving the binary, macOS shows a second modal:

3. And even when selecting "Open anyway", macOS shows a third modal to ask for the admin password:

[tdyas]

What is blocking us from code signing beyond paying the money to Apple for their developer program (and then doing the work to sign the binary with codesign)?

[jsirois]

How is Pants not hitting this already with scie-pants. Is macOs taking the unofficial keg / tap brew thing as some sort of shield? This is really laughable, because that sort of has to be it.

[tdyas]

Your observation is spot on. The brew recipe just blindly approves the binary (and just the fact that it even has the ability to do so seems like security theater ...): https://github.com/pantsbuild/homebrew-tap/blob/46d0ecbaebabdf52ae300e9f4719efe6e63ac8ab/Casks/pants.rb#L44-L46

[jsirois]

All that said, I'd probably try using https://gregoryszorc.com/docs/pyoxidizer/main/tugger.html if I must. I'll be damned if I bow to Apple and be forced into using their tools on an illegal to virtualize OS.

[tdyas]

Still requires paying the Apple tax for the developer program to obtain a code signing certificate even for a tool like Tugger. No escaping that for their walled "garden."

[jsirois]

Understood.

But also, are you partially inventing a problem here? For example, the science (a-scie/lift) tests download and run scie-jump binaries. The Mac shards pass with no signing and no brew middleman. It seems Apple allows non-interactive use of untrusted binaries?! Even more laughable security theatre it seems, but I am not a security expert.

[tdyas]

https://github.com/Homebrew/brew/blob/master/Library/Homebrew/cask/quarantine.rb is a fun read. The quarantine mechanism is keyed on the presence of an xattr, so removing the xattr essentially blesses the file.

[tdyas]

But also, are you partially inventing a problem here?

I might be. I am just going to try and switch Pants to use the SCIE Pex, and if I encounter no problems, then great. So this issue can be put on hold until I get blocked in actuality.

[jsirois]

Ok, but maybe simpler, can you just write a bash script that curls the Pex PEX scie and then tries to run it - say just printing its version? If you can run that script that seems to vet the approach or rule it out if pop-ups ensue.

[tdyas]

No need. It took me all of ~30 minutes to get Pex SCIE working (at least locally): pantsbuild/pants#21755

I'll need to see full CI fun pass, but ./pants fmt lint check works fine locally for me.

So we can close this. My concerns from trying to run the Pex SCIE manually evaporated after no pop-ups appeared in running it from within Pants.

[jsirois]

Ok, excellent. Be careful out there - mac is pretty shady!