Consider having and enforcing a commit signing policy

[nwalfield]

Description

Looking at the SecureDrop code, I see that many commits are signed. That's great! But, I couldn't find a signing policy. This makes the signatures less useful. Anyone could create a certificate with any user ID they like, and publish a commit. It would be good if SecureDrop would adopt a signing policy, and enforce the signing policy when adding changes to a main branch. This way third-parties could more easily check if some change or version is authorized by the project maintainers.

I've written a tool to do this, called sequoia git. Sequoia git specifies a set of semantics, defines a policy language, and provides a set of tools to manage a policy file, and authenticate commits. There is also a GitHub Action, sequoia-pgp/authenticate-commits to check that a pull request is authorized.

My request is that the SecureDrop maintainers consider adopting Sequoia git. I'd be grateful for constructive feedback, even if you decide not to use it.

How will this impact SecureDrop users?

This change is not visible to most users. But, it may increase deployments' security, as described below.

How would this affect SecureDrop's threat model?

Sequoia git is designed to improve software supply chain security by removing some third-parties, in particular, forges and registries, from a user's trusted computing base. We envision two main usage models. A user of Sequoia audits (directly or indirectly) a particular version of a project including the project's maintainers. They then use this version (commit) as a trust root in order to authenticate new versions (commits) by checking that there is an authorized path from the trust root to the new version. If there isn't then it may mean that they are using a version with unauthorized, potentially dangerous changes (commits). Alternatively, they download a version (git clone), and later use the old version to authenticate a new version thereby asserting continuity. This is basically TOFU. At a later time, we hope to add support to package manages like cargo to authenticate dependencies. This is still a way off.

In short, using sequoia git makes it easier to authenticate that changes to a repository are authorized. This can prevent users from using unauthorized versions. Note: sequoia git cannot prevent a project maintainer from authorizing a change from a rogue actor.

[rocodes]

Hey @nwalfield, thanks for taking the time to file this, and thanks also for your work on Sequoia-PGP, which we're in the process of migrating to. :) Haven't had a chance yet to chat about this as a team, but we will do so and get back to you.

I looked briefly through the sequoia-git documentation and I have a couple follow-up questions--do you have any recommended workflows for handling community contributions? (E.g. if it is someone who doesn't contribute regularly or is part of a short-term contribution effort like a hackathon, would you suggest goodlisting their individual commits)?

Also (and apologies if this is obvious but I missed it), how does the validation handle historical commits from an individual who was authorized at the time of committing, but then leaves the project - is the expectation that they would remain in the sq-git policy, or could they be offboarded but their historically validated commits would remain valid?

(Other sd maintainers, a note worth calling out from the sq-git docs below)

Note: GitHub's interface for merging pull requests offers three merge strategies, but unfortunately none of them are appropriate for use with Sequoia git, because they all modify the commits. With Sequoia git, it is necessary to either rebase and fast forward the change, or to add a signed merge commit. It is possible to use the sequoia-pgp/fast-forward
action to fast forward pull requests. When enabled for a repository, an authorized user can add a comment containing /fast-forward to the pull request, and the action will fast forward the merge base.

[nwalfield]

Hi @rocodes, thanks for the good questions! Sequoia git is a relatively new project (I only made the first release yesterday), and the user documentation is still not very good. My experience is that these types of questions are helpful to identify where the documentation needs improvement. So, thanks a lot for taking the time to engage, and don't hesitate to follow up with more questions.

how does the validation handle historical commits from an individual who was authorized at the time of committing, but then leaves the project - is the expectation that they would remain in the sq-git policy, or could they be offboarded but their historically validated commits would remain valid?

Sequoia git has a simple authorization rule. A commit is consider authorized if it is the trust root, or it is authorized by one of its parents' signing policies, and that parent is also authorized.

Consider the commits a -> b -> c, where a is our trust root, and we want to authenticate c. Sequoia git starts with commit c, and checks if the signing policy embedded in b authenticates c. If so, it then checks if the signing policy embedded in a authenticates b. If that is also the case, and since a is our trust root, we're done, and c is considered authorized by a.

So, to your question: how does Alice, a project maintainer, offboard Bob, a contributor. Let's imagine that Bob signed commit b, which is authorized by a's signing policy, and that Alice removed Bob from the signing policy in commit c, which is authorized by b's signing policy.

First, the fact that c's signing policy rescinds Bob's authorizations does not change the status of commits that he signed in the past. This is due to the authorization rule, which takes a local view: only information from the parent commits flow into the authorization function. (Note: this not completely true: Sequoia git handles hard revocations, which requires non-local reasoning.)

Second, if Bob effectively forks the project at b, then people who use a trust root of a will indeed consider Bob's fork to be authenticated. This is slightly mitigated by the fact that if Bob was only authorized to sign commits, then he'll never be able to create an authorized release.

In order to work around this, downsteam users should regularly update their trust root. One approach for projects that are audited regularly, would be for the auditors to publish the hash of the commit they audited, and users change their trust root to the new commit. Other strategies are possible, and it may make sense to extend Sequoia git to facilitate them. That is still future work, though.

do you have any recommended workflows for handling community contributions? (E.g. if it is someone who doesn't contribute regularly or is part of a short-term contribution effort like a hackathon, would you suggest goodlisting their individual commits)?

goodlisting is only for reauthorizing commits that were signed with a certificate that was hard revoked. Imagine that Bob realizes his key was compromised. He publishes a revocation certificate, and Alice adds that revocation certificate to c's signing policy, and simultaneously audits Bob's prior commits (b) and goodlists them. When examining c, Sequoia git will recognize that Bob's certificate was hard revoked. (In the future Sequoia git may also check for revocations on public key servers, or in the user's local certificate store.) When checking b, it will see that the signature is valid, but that the signer's certificate was hard revoked. It will then check if a subsequent commit on an authorized path to c goodlists b. This mechanism was carefully designed to prevent the attacker who got access to Bob's private key material from authorizing their own commits. In short, goodlisting is not a way to handle community contributions.

There are two main development models: a linear history, and feature branches that are explicitly merged using merge commits.

For projects that use a linear history, a pull request often has to be rebased before it is merged. In that case, any signatures are rewritten. For projects that want a linear history and use Sequoia git, one of the project's committers would need to rebase commits before merging thereby replacing the contributor's signatures with their own.

Projects that use merge commits just need to make sure the merge commit is signed by an authorized committer. This is due to the authorization rule, which says that only one parent commit has to authorize a commit, not all parents.

[rocodes]

Hi @nwalfield, thanks for the detailed walkthough and hope it wasn't too time-consuming to write up.

We've chatted briefly as a team, and we're in favour of this as a concept, but our current team capacity means this isn't something we can act on right now. We do use github web UI and automation tooling a fair bit esp for day-to-day development, so we'd want to look at the changes we'd need to make in our existing workflows, and we'd probably also try the policy out on a component repo before deploying on the SecureDrop repo, perhaps once sq-git has a had little more longevity, and we have a little more room on our plates.

Thank you for bringing it to our attention though and following up in so much detail; it's the exact kind of project we want to be aware of, and we'll keep up with it as it develops.

[legoktm]

and we'd probably also try the policy out on a component repo before deploying on the SecureDrop repo

Yeah, I think the securedrop-builder repository is probably what would get the most out of this. We're already PGP-signing checksums of files in that repo as a way of authentication, so if we could just rely on commit signatures instead that would be much simpler. And it gets very few-to-no non-maintainer contributions so we can impose more/different contributing requirements without too much trouble.

[nwalfield]

but our current team capacity means this isn't something we can act on right now.

That's understandable.

We do use github web UI and automation tooling a fair bit esp for day-to-day development, so we'd want to look at the changes we'd need to make in our existing workflows,

It's exactly this type of feedback that I'm looking for :)

and we'd probably also try the policy out on a component repo before deploying on the SecureDrop repo

That makes sense. Please keep me posted about your experience. I'm interested in both what works well, and what needs improvement.