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 EF9883858C2D for ; Wed, 14 Sep 2022 09:11:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EF9883858C2D 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=1663146701; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=gadMXrRiD2r7MZ9FGotn0SnSp63mUWS/TYKPF6e6hmw=; b=Bo34oWGgwPLNmtS7pzIfr4wR5+QXixVMwgRNv60QVzW/XVLlGEYT5hfggRBYPr8jEyku6D tWlt+TcHsRjD/ARIa9oM+1CgQwBjWIdAAtT7ghtkA6T568Ftt5VjA2L1XUn8WxEWXIQU8X N7b/1Bs6+3TMyXySjZFP1bSqGw0Qdac= Received: from mail-ot1-f72.google.com (mail-ot1-f72.google.com [209.85.210.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-630-dls56DFePRSp0Ex0fBJ7EA-1; Wed, 14 Sep 2022 05:11:40 -0400 X-MC-Unique: dls56DFePRSp0Ex0fBJ7EA-1 Received: by mail-ot1-f72.google.com with SMTP id f13-20020a056830056d00b006549b545aa6so8158676otc.0 for ; Wed, 14 Sep 2022 02:11:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date; bh=gadMXrRiD2r7MZ9FGotn0SnSp63mUWS/TYKPF6e6hmw=; b=z2OGP0vo90tgrB9lTu3frg4yIBa6fp4GE96+OHfs/4YIRGdBo3PysUDaA00r27w2mE nrCFYNdZh3ARCYjqwPjwmGRh0k5F6c77mMvPqYbpT3Qi8qHHIttP3thqWeeiY9IQPAVo smV7W6pyM7/Nn/bkhroEsqK1d78vlsbwR8aFtoOEYXmVNyMFSrEOyOqr9wPCKhUScfDm /h2mooojc+AKbW5Ug6xDgnRiKz72nUy8ksg2YqDAgFQj366gja96tvk2AqyA1GFK60Ls QeZb/uPNZFJK73UuRoQWKnRQP6rGaykhFaSPLauG39bJK0LjYUIMrqOkwECJ2EiWsw3R N4sA== X-Gm-Message-State: ACgBeo05DqKEnmBomCJgbInLC2LebWvxdB0Ufg17HBTT2oCkuhA1pTjc dh2b8oJK1Yw0ZIekUYUgAkw8ns1y8bxjH2k3NAvMV6kbJ75RgiIeVfuFhQmZ8KoH44rWiw3ktei 9PycOkSLGfXTZRs39F2+FhWk= X-Received: by 2002:aca:190e:0:b0:34f:6cfb:b152 with SMTP id l14-20020aca190e000000b0034f6cfbb152mr1391465oii.270.1663146699699; Wed, 14 Sep 2022 02:11:39 -0700 (PDT) X-Google-Smtp-Source: AA6agR6ZEpK0Sr7fveB+2cMaILbQ6JfYXLp1OvUeu0x6NiifMydkn6aa+5VvOPsTZqdrb8pTLeawnVGeTHaEhzy6i+U= X-Received: by 2002:aca:190e:0:b0:34f:6cfb:b152 with SMTP id l14-20020aca190e000000b0034f6cfbb152mr1391457oii.270.1663146699394; Wed, 14 Sep 2022 02:11:39 -0700 (PDT) MIME-Version: 1.0 From: Ulrich Drepper Date: Wed, 14 Sep 2022 11:11:28 +0200 Message-ID: Subject: commit signing To: Ulrich Drepper via Gcc X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="0000000000003a2af105e89f847f" X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,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: --0000000000003a2af105e89f847f Content-Type: text/plain; charset="UTF-8" For my own projects I started /automatically/ signing all the git commits. This is so far not that important for my private projects but it is actually important for projects like gcc. It adds another layer of security to the supply chain security. My shell prompt (as many other people's as well) shows the current git branch but in addition also shows the validity of the signature if it exists. For this a file with the authorized keys needs to be provided. I found it easiest to use SSH keys for signing. One can create a new key for each project. If the desktop environment uses GPG daemon or something like that one doesn't even realize the signing request, it's handled automatically. git allows to set up signature handling on a per-project basis. I.e., no decision made for one project will have any impact on other projects. For painless operation all that is needed is that the authorized keys are published but that's not a problem, they are public keys after all. They can be distributed in the source code repository itself. My question is: could/should this be done for gcc? It's really easy to set up: - create new key: $ ssh-keygen -f ~/.ssh/id_ed25519_gcc -t ed25519 (of course you can use other key types) - configure your git repository. This has to be done for each git tree, the information is stored in the respective tree's .git/config file $ git config gpg.format ssh $ git config user.signingKey ~/.ssh/id_ed25519_gcc.pub $ git config commit.gpgsign true $ git config tag.gpgsign true If ssh-agent is not used then the user.signingKey must point to the private key but this is hopefully not the case for anyone. It's also possible to add the entire key to the configuration, which doesn't compromise security. It is possible to define global git configurations (by adding --global to the command lines) but this means the settings are shared with all the projects you work on. This can work but doesn't have to. - collect all maintainer's keys in a public place. There could be in the gcc tree a file 'maintainer-keys'. The file contains one line per key, the public key preceded by the respective email address. If this is the case use $ git config gpg.ssh.allowedSignersFile maintainer-keys At least the original git seems to be happy with relative paths (i.e., if the file is not at the toplevel an appropriate path can be added) Every maintainer then just has to remember to submit any newly created key as a patch to the 'maintainer-keys' file. That's it. The key creation ideally is a one-time effort. The git configuration is for everyone using the gcc git tree a once-per-local-repository effort (and can be scripted, the gcc repo could even contain a script for that). After this setup everything should be automated. Someone not interested in the signature will see no change whatsoever. Those who care can check it. Note, that github also has support for this in their web UI. CLI users can use $ git config log.showSignature true to have git display the signature state in appropriate places by default. If and when signatures are universally used one could think about further steps like restricting merges based on trust levels, add revocation lists, Or even refusing pushes without a valid signature. This would indeed mean a higher level of security. Opinions? --0000000000003a2af105e89f847f--