Sign node exporter darwin binary with rcodesign

[gitperr]

Alright, since I seem to have butchered my previous PR (see #2916) beyond recovery with force pushes, I decided to open a new one that looks more sane.

Prevents SIGKILL issues on macs.

Fixes: #2539, #2217

I previously tested the darwin build that came out, and it ran well on my M1 mac, so this should be good to go.

[gitperr]

@SuperQ this is the code signing saga we had started a while back, now that promu is updated, the builds can be code signed properly. Is there anything else that needs doing?

[SuperQ]

Do we need a secret key to do the signing?

[gitperr]

I doubt it adds much because it would be a key + self signed certificate we generate.

Normally developers pay Apple a subscription fee of $99/year to get "Apple trust" so they can do more than ad-hoc signing (so, no key). But, other projects like Homebrew have been able to get away without doing this. They have been using ad-hoc signing for a long time (see https://github.com/Homebrew/brew/blob/e479f4bc35c3be468172e10b7428f37e322bdeb1/Library/Homebrew/extend/os/mac/keg.rb#L33) and it just works, and they do not seem to maintain a key.

One difference is that their build machine is macOS, so they are able to access the real codesign utility Apple provides, whereas we use rcodesign as we are building on Linux.

[gitperr]

Okay, so the amd64 signed binary should be testable by following these steps:
1- Download the darwin amd64 binary from pipeline artifacts on a linux machine https://app.circleci.com/pipelines/github/prometheus/node_exporter/4161/workflows/0f5c1a75-cb1f-43db-9509-4736fdaaeb26/jobs/21623/artifacts
2- Tar it with something like tar cf node_exporter.tar node_exporter and host it on your linux machine with something like python3 -m http.server 9999
3- Pull it on your mac node curl --output <ip_of_your_linux_node>:9999/node_exporter.tar > node_exporter.tar
4- Untar it, give executable permissions and run

The reason I test it like this is because safari direct click downloads won't work - it will give a security warning. And normally we distribute in tarballs directly from github. So, this is one way to get close to that.

[vladyslav-androshchuk]

We need this as hell :) Can I help somehow?

[SuperQ]

Let's give this a try.

[conradwt]

@gitperr I tend to use MacPorts where most of the packages if not all of the ports are compiled and installed on the user's local machine. Thus, codesigning isn't required for software that is downloaded, compiled, and installed.

Codesigning is free to all Apple developers' accounts (i.e. paid and non-paid) but one needs to have an Apple ID associated with their Apple Developer account. If you're releasing binaries that need to be submitted to Apple to get notarized, then one must have a $99 paid Apple Developer subscription.

Next, I know that GitHub Actions does support runners for macOS 12 - macOS 14 for both Intel and Apple Silicon. Also, it looks like the Homebrew team is currently using it.

Finally, Apple probably will refine how apps are signed and notarized at the next WWDC 2024.

[gitperr]

As far as I know, if you compile locally, your code will be linker signed so you indeed do not need additional signing. With this, you can run that compiled software on your mac. But, you will have problems when running in other macs.

I did not know code signing was free, that's nice. I'd very much prefer to get rid of rcodesign here and use an actual mac machine to use its native codesign binary for this purpose. At the moment, CircleCI is in use in node exporter project, and last I checked there were no mac nodes in use - even though it is offered by CircleCI.

My original proposal for code signing was this:
1- We add an Apple ID for Prometheus project
2- We get a mac node (on CircleCI), and sign it there
3- Add pipeline steps for the code signing

I can do step 3, but steps 1 and 2 are to be done by a maintainer with more access, I think.

According to my tests, rcodesign signed binary should work as intended for a while, which should buy some time to do these things more properly.

[conradwt]

@gitperr Yes, when you compile software locally on macOS, the linker can sign the code if one has specified code signing during the compilation process. For example, here's Julia's codesign information when I installed it via MacPorts:

➜ codesign -d -vv /opt/local/bin/julia
Executable=/opt/local/bin/julia
Identifier=julia
Format=Mach-O thin (arm64)
CodeDirectory v=20400 size=510 flags=0x20002(adhoc,linker-signed) hashes=13+0 location=embedded
Signature=adhoc
Info.plist=not bound
TeamIdentifier=not set
Sealed Resources=none
Internal requirements=none

In Xcode, there's a tab, 'Signing & Capabilities', a checkbox called 'Automatically manage signing' that's checked by default when you create a new application.

Finally, I like your proposal and you're closer to the maintainer as a contributor to bring this to their attention. I have my fingers crossed that Apple will announce free notarization for open-source apps at WWDC 2024. I know Apple uses Prometheus and associated tools within its infrastructure.

[vladyslav-androshchuk]

The MacPorts, Homebrew and Code Build are good, but sometimes raw binaries are easier to work with. For example, we use Puppet to manage some parts of our nodes, and mixing Homebrew to the "node_exporter" module or depending on the GO compiler is not the easiest and most cleaned solution.

[conradwt]

@vladyslav-androshchuk I totally agree with you here because I mostly use package managers on my local dev machines.