From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 7770A3858D1E for ; Mon, 19 Jun 2023 20:20:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7770A3858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1687206007; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=P2kksPnyqK2IG/wlMTs/pTDrsHO3LOO3EkGF5gVqFPA=; b=Xteouy9NOfbtQtd1OpAJBACrDGYOj+0YvVOUMMYIQ8/pBrVf2almL1fr5OXAxCv5pw517c tVJ2M3KybIqJh7Dfsm/NNMYzW/LMz1fKVJVlZ0mG70h1Ze6qp9RZNqxBT/fb6NHjaW5DRw 4m2eVeE7MRvVlZ//h1NSYwPMj8e1Yj0= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-68--3zFtaTSPZ6PgHWq9DTcXw-1; Mon, 19 Jun 2023 16:20:03 -0400 X-MC-Unique: -3zFtaTSPZ6PgHWq9DTcXw-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 51DB2101A531; Mon, 19 Jun 2023 20:20:03 +0000 (UTC) Received: from redhat.com (unknown [10.22.32.43]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1139040CF8E7; Mon, 19 Jun 2023 20:20:03 +0000 (UTC) Received: from fche by redhat.com with local (Exim 4.94.2) (envelope-from ) id 1qBLM1-00060l-IY; Mon, 19 Jun 2023 16:20:01 -0400 Date: Mon, 19 Jun 2023 16:20:01 -0400 From: "Frank Ch. Eigler" To: Overseers mailing list Cc: Mark Wielaard , "Frank Ch. Eigler" , Morten Linderud , Sam James Subject: Re: gitsigur for protecting git repo integrity Message-ID: <20230619202001.GD5772@redhat.com> References: <20230618230319.GI24233@gnu.wildebeest.org> MIME-Version: 1.0 In-Reply-To: <20230618230319.GI24233@gnu.wildebeest.org> User-Agent: Mutt/1.12.0 (2019-05-25) X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham 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 like the general idea of (optionally) signing commits. And having an > associated store of known keys. Righto. > As long as there are also unsigned or unknown signed commits it makes > sense to also introduce some kind of transparancy log so people can > check commits came in through a (ssh authenticated) receive-pack (and > were not to result of direct manipulation of a repo on the server). Manipulation on the server could not result in creation or editing of signed commits, since the server (by design) does not hold any crypto credentials. That's one of the benefits of habitually signing git content. > I don't think enforcing mode will be very popular on normal > development branches. But I can see it being something you might want > for release branches. [...] Who knows, maybe. Given that releases come from development branches, and given that signing your commits is rather lightweight, eventually enough people could get used to it and to the assurances to just toggle the switch for important branches. But the script is configurable. Any project can: - direct their sigur hook to a key repo of their choice, or a shared one - have multiple active sigur hooks, configured differently, so as to enforce distinct policies for different branches > [...] > Does it make sense for there to be a mode that requires (just) tags to > be signed? I suspect that wouldn't need to be a mode, just another configuration sigur --checkref='ref/tags/*' --mode=enforcing [...] - FChE