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 6E6763858CDA for ; Mon, 10 Jul 2023 22:05:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6E6763858CDA 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=qLZAp+C08R8kNO++FzXEEwriHM5dsPHTzeGSTXJfP/Y=; b=OK0RQxP7Uhsv5/Yj8+FteOeg08 AaiTPg3QxpdLLEQhufV/bJldYML5d1/v/tZCs0JZQUEXnikEgUMKutuzbvrQMgQExhUu67tAtoF8a FkcsrWz9LP6H2CoMIYuyGC9U4bG9CMXoU1H3mz+9o22/LGoRHA2w2A//ZpE1fv+LFoyE37agOZKB3 R/a+cC8p5/DVdEwVe86ZzxtFGvvmBmky1qd/7GPv1kmsjM+rTOc1ykWYACUsrXDVWdPhcx6DcYjfx bAjnmtX/ARm9pQke/bln/aqMan8ivlevL2jvOJ2e+cyAD1k3ldYVQr02dVl63qC0oDitgonk60++/ Cd9vhCRg==; 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 1qIz0y-000213-1v; Mon, 10 Jul 2023 22:05:52 +0000 Received: from very.elastic.org ([192.168.1.1]) by elastic.org with esmtp (Exim 4.96) (envelope-from ) id 1qIz0y-0001d2-0h; Mon, 10 Jul 2023 18:05:52 -0400 Received: from fche by very.elastic.org with local (Exim 4.96) (envelope-from ) id 1qIz0y-00C3CI-0V; Mon, 10 Jul 2023 18:05:52 -0400 Date: Mon, 10 Jul 2023 18:05:52 -0400 From: "Frank Ch. Eigler" To: Ludovic =?iso-8859-1?Q?Court=E8s?= Cc: "Frank Ch. Eigler" , 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87ilar78lv.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 - > >> My understanding is that gitsigur checks signatures against an > >> out-of-band list of authorized keys, which isn’t very useful because > >> the set of authorized committers changes over time. > > > > The list of authorized keys is stored in a selected branch > > If it’s in another branch than the code it’s about, how can you tell > whether a key was authorized at a given point in the commit history? You're talking about retrospectively verifying old commit signatures, rather than verifying eligilibity at the time of a push. 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. - FChE