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 EE7303858CD1 for ; Fri, 14 Jul 2023 14:00:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EE7303858CD1 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-Transfer-Encoding:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: 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=K1t2GkBoToJ+oHoT+TfkJ53Hoggfay/v4q6OJgLEMZo=; b=Yblg3a0+J5mk2L2WmTQ+PJEa5o 9TCX5wWjMsVjzaXVGqE58BbQMOgHNoCc7Nrq4iDtY7G5TwT0VccN+cys7kvQQXomeneruxV18EOuT R7iOMTf89p7JMdkdxSgbibpfTvNVgwmxtauvWX/13XE41WIujlNyI2cHkZGBebr+OLRUhfoAuMXtI 9vqk5ezOTg+YsZIydzduljtEltaXVvVPvazP1OIybptt+iDcnUMpr1M0ohml5aVX3m1Q+V3d83zdV EwWYVBJsaj85RQE88v8r2R7gGAB8kCS5qjcXm5Z6OtxzB5Sf98v35clxUo0n4OFY0QFC04c8sk3xL sTrmtkxQ==; 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 1qKJLF-0002zX-2D; Fri, 14 Jul 2023 14:00:17 +0000 Received: from very.elastic.org ([192.168.1.1]) by elastic.org with esmtp (Exim 4.96) (envelope-from ) id 1qKJLF-0006Wo-0q; Fri, 14 Jul 2023 10:00:17 -0400 Received: from fche by very.elastic.org with local (Exim 4.96) (envelope-from ) id 1qKJLF-008Ikd-0e; Fri, 14 Jul 2023 10:00:17 -0400 Date: Fri, 14 Jul 2023 10:00:17 -0400 From: "Frank Ch. Eigler" To: Ludovic =?iso-8859-1?Q?Court=E8s?= Cc: Overseers mailing list , Mark Wielaard Subject: Re: gitsigur for protecting git repo integrity Message-ID: References: <20230704083245.GB11693@gnu.wildebeest.org> <20230705182544.GF11693@gnu.wildebeest.org> <20230705200131.GI25859@redhat.com> <87ilar78lv.fsf@gnu.org> <874jm6y6kv.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <874jm6y6kv.fsf@gnu.org> X-Sender-Verification: "" X-Spam-Status: No, score=-101.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,USER_IN_WELCOMELIST,USER_IN_WHITELIST 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 - > > You're talking about retrospectively verifying old commit signatures, > > rather than verifying eligilibity at the time of a push. > > Both. OK but you're talking exclusively about the former: > Assume a contributor has a genuine checkout; how do you ensure > that when they eventually run ‘git pull’ they can authenticate their > updated checkout? You need to somehow convey the updated set of > authorized committers to everyone who pulls from the repo. One can pull the git repo containing the authorized pubkeys. (At this point, this would be manual; gitsigur should learn to do a git clone if given remote URL.) > This is what ‘guix git authenticate’ addresses. OK. > > gitsigur at uses the "current" contents of the keymaster repo/branch > > for the list of public keys. It could also look back in time, relying > > on that repo's commit timeline, to inspect the time-varying mapping. > > There is enough information there, so it's a SMOP. > > “SMOP”? ("small matter of programming") > I think info about the set of authorized keys should be stored > in-band, in the repo. If you maintain it out-of-band, then you can > try to match timelines as you write, but it’s just an approximation, > it’s unreliable (you cannot rely on timestamps in Git commits, for > instance), If the pubkeys are in the same repo but in another branch, the timestamp unreliability problem still exists, such as it is. (gitsigur can be configured for this layout already.) If the pubkeys are stored within the same branch as the payload source files, then this requires a change to the project source management. Even this configuration would work with gitsigur, just a bit ugly. > and it doesn’t work once you have multiple branches. I don't understand this concern. > I think you should take a look at Sections 4 and 5 of > . [...] Will read, thanks. - FChE