Add code-signing for Homebrew proposal

[di]

This adds a proposal by myself and @woodruffw to add code-signing to the Homebrew ecosystem.

Edit: The goal here is to have a proposal from 'within' this WG that could be submitted to any potential funder. We plan to submit this to Alpha/Omega for funding first.

[jalseth]

This is great! One thing I would like to see added is a list of goals and non-goals focusing on what threats are addressed. For example: This prevents attackers who can forge TLS certs for GitHub from tampering with artifacts, but does not prevent an upstream repo from being compromised and Homebrew CI from automatically building/signing/distributing a malicious package. The latter is partially addressed in this proposal, but would not be 100% addressed until a requirement that all Homebrew upstream sources are signed is added to the CI builder's logic. A future proposal may add a config option to enable a TAP owner to mark their TAP as 100% signed so all packages within the TAP must have signatures before Homebrew CI should build/distribute.

[di]

The PR is missing some context, but from Slack I infer that this is a proposal for Alpha-Omega funding that is sponsored by the WG Securing Software Repos. Is that correct?

This is just a general proposal from this WG that could be submitted to any potential funder. Although we do plan to submit this to A/O for funding first, there isn't anything A/O-specific here.

[woodruffw]

Some feedback from the Homebrew maintainers on their Slack:

1. There's some interest in signing for pre-existing bottles without rebuilding, so that signatures could be required on all bottles in homebrew-core faster/without the time + challenges of a full rebuild.
   • My thinking here is that this is possible and compatible with the larger proposal: we could have two signing workflows with distinct identities (e.g. sign-fresh-bottle.yml and sign-existing-bottle.yml), and the "flag" day would then correspond to the day when all listed bottles are signed with sign-fresh-bottle.yml rather than a mixture of the two.
2. We should probably document and clarify that the signatures here do not interact with Apple's notarization or codesigning schemes. This means that the existing work that Homebrew does (local signing/notarization) will not be impacted/broken by these changes, nor would these changes block or prevent any future attempts to sign for individual binaries within each bottle using Apple's own codesigning scheme. Instead, it's purely complementary (ensuring authenticity at the bottle and thus object store/CDN layer.)

cc @mikemcquaid and @smillerdev, since I've summarized your feedback above; please correct me if I've missed or mistaken anything 🙂

[di]

Got it. The part I was missing from the PR description was that this is a "proposal from this WG that could be submitted to any potential funder".

I've updated the description!

[di]

Hi folks, thanks for all the reviews to date. Just an FYI that I'd like to merge this by EOD today, so we can submit it to A/O by the end of the week.

[haydentherapper]

@di @woodruffw What do you think about adding a threat model as mentioned in https://github.com/ossf/wg-securing-software-repos/pull/20#issuecomment-1638574892?

[woodruffw]

What do you think about adding a threat model as mentioned in #20 (comment)?

I'm happy to do that; I'll open a PR in a bit.

[di]

Thanks everyone for your feedback here!