From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from elastic.org (elastic.org [96.126.110.187]) by sourceware.org (Postfix) with ESMTPS id D906E3858D35 for ; Thu, 29 Jun 2023 18:55:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D906E3858D35 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=elastic.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=elastic.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=elastic.org ; s=default2; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:To:From:Date:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=rYVr/mM6NlPraDqTocwxrKbBpew1s8+30ikbWxdwhtc=; b=NZMgkeYLXVr6HeM4iWyOkBeWLk ycITEJYNGDcX8nZ3+mBLy3Ejr0PdFjOyrAXrE/FjFQ59SlRliJDKTmiVOn5TzQwMshCN9UgT4NHWl FD7TEM5IeJJoTY5sjnE7te5haPWhVWrGx4KCeAvoOn5kBglP+rMqs4wris+/KvSu7Z3tpBc83sB2T o2gAA4xZ5pU29L3kAlusHFDUCpcR/hHIPyrR3yo2Zq3AG9wENcis3dxDc7LY6wXkE67aJxGuqzNdY MlCgIuApvWTb5GRWvmcBM3brRs12LU/gwuazd3A/SrrDbTVDVOpdSR6HiN5b4FAT7vcMQbkiOh+Wi Hh8yD7EQ==; Received: from vpn-home.elastic.org ([10.0.0.2] helo=elastic.org) by elastic.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1qEwnL-0002NG-1T for overseers@sourceware.org; Thu, 29 Jun 2023 18:55:07 +0000 Received: from very.elastic.org ([192.168.1.1]) by elastic.org with esmtp (Exim 4.96) (envelope-from ) id 1qEwnL-0008y4-1N for overseers@sourceware.org; Thu, 29 Jun 2023 14:55:07 -0400 Received: from fche by very.elastic.org with local (Exim 4.96) (envelope-from ) id 1qEwnK-0076DQ-3A for overseers@sourceware.org; Thu, 29 Jun 2023 14:55:07 -0400 Date: Thu, 29 Jun 2023 14:55:06 -0400 From: "Frank Ch. Eigler" To: overseers@sourceware.org Subject: Re: gitsigur for protecting git repo integrity Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Sender-Verification: "" X-Spam-Status: No, score=-100.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,LIKELY_SPAM_BODY,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,USER_IN_WELCOMELIST,USER_IN_WHITELIST autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi - > I'd like to share a little gadget I've been working on recently. > > It's a prototype git server hook for allowing participating projects > to check and/or enforce that commits to certain branches of > shared-access git repos such as those on sourceware are properly > gpg-signed. [...] Some questions have arisen offline about the relationship of this script to systems such as sigstore and b4. Here's a rough comparison of the three. This is pretty terse point-by-point analysis. I'd be happy to elaborate on any aspect of it. tl;dr: Overall, it turns out to be more of a composition situation rather than competition. Sources: [lines-of-source language] * gitsigur: https://sourceware.org/git/gitsigur.git [200 python] * sigstore: https://github.com/sigstore/gitsign, /rekor, /fulcio [73000 go] * b4: https://github.com/mricon/b4 [8500 python] Scope: * gitsigur: enforcement of gpg-signed git commits at git server; keyring storage in some git repo * sigstore: developer-side git signature tooling, via custom temporary x509 certificates bound to a web openid identity * b4: signed/secure git commit text transport over email Scope overlap: * gitsigur/b4: none, though the signed git commit message can include the public-inbox url for authenticating the chain of custody * sigstore/b4: ditto * gitsigur/sigstore: use of gpg vs custom signatures on git commits (nb: sigstore upstream development uses github's server-side gpg signatures, does not eat sigstore dog-food itself) * gitsigur/gitlab: signing same, verification analogous https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/index.html https://docs.gitlab.com/ee/user/project/repository/push_rules.html * gitsigur/github: signing same, verification analogous https://docs.github.com/en/authentication/managing-commit-signature-verification/telling-git-about-your-signing-key https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches Infrastructure required: * gitsigur: a git server * sigstore: an openid web server, a certificate generator web server, audit trail web server, timestamp server * b4: a public-inbox email server Developer workflow - pushing code: * gitsigur: create & share gpg key once, use builtin git gpg support to sign locally; normal git push to pass gitsigur enforcing/permissive gate hook * sigstore: install "gitsign" as replacement git signing/crypto engine; use openid web system to authenticate against some identity server; public certificate generator system creates temp certificate; custom git commit signature scheme includes entire temp certificate abeam the signature itself; git commit news may be broadcast to audit trail; normal git push, no server-side gating hook * b4: developer posts git patches with b4 wrapper to add gpg signature; maintainer uses b4 wrapper to check integrity of emailed patch series; normal git commit & push Developer workflow - verifying commits from git repo: * gitsigur: download keyring git repo; run gitsigur locally against range of commits * sigstore: run gitsign verify on local repo, with the certificate keyring stored right within the commits; also possibly connecting with public audit trail servers * b4: not applicable Hosting git server workflow: * gitsigur: one git update hook * sigstore: not applicable as server-side gating does not appear to be part of sigstore * b4: not applicable Composition possibilities: * gitsigur/b4: use b4 to send/receive patches by email, gpg-sign resulting commit and enforce at server side via gitsigur * gitsigur/sigstore: use sigstore to sign commits; teach gitsigur to detect sigstore flavoured signatures and delegate verification to sigstore gitsign, then enforce policy similarly * gitsigur/sigstore 2: teach gitsigur to announce receipt of verified commits to sigstore (rekor) public audit-trail * gitsigur/ssh/x509: extend gitsigur to support ssh and x509 standard git signature styles, let developers choose their favorite; store keys/certs in same keygitrepo - FChE