Technical Explanation

Scrutineer at its core signs git commits. A signature does not make sense without its verification. This is where Scrutineer comes into play.

The verification of signatures is an n-p hard problem. Whenever a person in your team joins or leaves, everyone needs to update their trust database. This is a tedious and error-prone process. With Scrutineer developers manage who they trust. That can be only themselves, their peers, their teams, and even their entire organization. User management is then done on a team or organization level by trusted personell.

Security of the signing process

Signing usually happens in the background if you configure git¹ to do so. Scrutineer actually never gets in your way. The content of your commit message² is sent to a Scrutineer server. You are authenticated under your user-handle, which is a 9 character long string that starts with "U". The source code is not sent to the Scrutineer servers.

The backend checks your authentication, signs the commit message and sends the signature back to you. Git then stores the signed commit in git.

How the signature is composed

To calculate the signature, the following byte representations are concatenated:

1. Message
2. User Id
3. RFC 3339 Timestamp in UTC

The resulting bytes are hashed with SHA256. The raw hash is then signed with elliptic curve cryptography. Scrutineer uses the curve NIST P-256 (FIPS 186-3, section D.2.3), also known as secp256r1 or prime256v1.

Security of the verification process

The content of the signature is not only the commit message, but also the authenticated account and the timestamp. Your realm³ is then compared to the signature in three steps:

1. Is the signature valid?
2. Is the signing user in your realm?
3. Was the signature made within the allowed time interval for this user in your realm?

If the user is not in your realm, maybe they are part of a team or organization you trust.