Code Signing and Notarizing Open-Source unsigned binaries

Code Signing Notarization
berd-lp OP
Created 7h
Replies 2
Boosts 1
Views 37
Participants 2

Hi,

I am trying to build an installer package of an usual(?) format:

  • it contains a binary that I am developing

    • code signing and notarization is straightforward here.

  • it contains a 3rd-party binary that is open source, code signed and notarized by this third party

    • code signing and notarization is also straightforward here as it's already been done.

  • it also contains a 3rd-party binary that is also open source, however, it is not code signed or notarized

This last one is the subject of my question.

It is a well-established project with thousands of stars on GitHub, however their own "installation method" is a shell script that downloads the binary, checks its checksum and just places it in the right location.

When building an installer package (it's an installer package of these three binaries packaged - productbuild with --distribution flag) this binary needs to be code signed and notarized for Developer ID distribution.

I trust this binary, however the chance of supply chain attacks is never zero.

My questions are:

  1. How can I shield myself best against accidentally submitting a malicious version of this third binary via notarytool to Apple?
  2. Should I separately submit versions of this binary for notarization from submitting new versions of my app? This binary is bound to change way less frequently than the app I'm actually developing.

I really don't want to risk termination of my Apple Developer account because it has many high-value applications available.

I am doing some basics - matching the intended checksum before packaging, signing with the hardened runtime entitlement - but I would love to hear if there's other steps I can do to protect this pipeline and my company from accidents like these that may unintentionally damage our reputation.

Thanks in advance!

Replies  2
Boosts  1
Views  37
Participants  2
Etresoft OP
2h

How can I shield myself best against accidentally submitting a malicious version of this third binary via notarytool to Apple?

Is this a trick question?

Only submit code that you have written yourself and that you're 100% sure isn't malware. Note that this also includes code written by an AI.

Should I separately submit versions of this binary for notarization from submitting new versions of my app? This binary is bound to change way less frequently than the app I'm actually developing.

I don't understand this question.

But it's a moot point. While Apple doesn't publish the internal mechanism behind notarization, it should be easy enough to guess. It does a basic malware check against known signatures. It also records the submission for malware that might not be discovered until later.

Anything you submit, regardless of provenance, goes against your account.

I really don't want to risk termination of my Apple Developer account because it has many high-value applications available.

So what's the value of these open-source packages to you then?

You haven't specified what these packages actually do, which is a really important point. In many cases, the risk of supply-chain malware from an open source project is very low. If you're a heavy AI user, the risk from 3rd party code might even be less than the risk from your own, AI-generated code.

But in certain domains, the risk of malware is very, very high.

Which domain are you working in? I don't know.

I would love to hear if there's other steps I can do to protect this pipeline and my company from accidents like these that may unintentionally damage our reputation.

Nothing new here. It's always a risk/value trade off, eh? It's a little bit different in software development just because standard industry practices are typically the most risky ones imaginable. If everyone else is doing it, it must be correct, amiright?
berd-lp OP
1h

Only submit code that you have written yourself

I won't expose the exact binary I am talking about, but would you say ffmpeg is something people write themselves?

It's also an unsigned, unnotarized binary download from their official website. Or you can build from source code. Exactly the same case with my binary.

So we can use ffmpeg as an example. How do I defend against embedding ffmpeg in my installer, getting supply chain attacked, and afterwards signing and notarizing some malware under my name?

Code Signing and Notarizing Open-Source unsigned binaries
First post date Last post date
 
 
Q