From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) by sourceware.org (Postfix) with ESMTPS id 206153858D37 for ; Wed, 14 Sep 2022 11:31:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 206153858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ed1-x536.google.com with SMTP id f20so17282403edf.6 for ; Wed, 14 Sep 2022 04:31:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=8Ef0a1YdWXB5FYOHh5J1dlJbOTNWKYy0L/Y62hBzUcg=; b=ITH3+q5NQH1zpXZkeQbLE1ZXrS5akUrLrprPdLKHBDLAEYoiZ2Jjgt8HxD/iRveAjz c9fvW7q+HcPmqGSJlwwz2+bFu4Vp5Ud5+UPxRXCAqMrxOtWY9UQyZmENDAt/o7LRpLx+ R6vpK3orHG6SiSh+2jwWMva/f4KLu2+V50OhDCrFzgmDCIvw5T01u6sLq3+GBgMxySjJ VsQSxnx+/eImvOD9sklLEVX2QpYdyyXjfiIfpvSMzK1y90bnBNU9kxFbsovwhg37YVms m1I57N5riceu3CD6Hpq+4SSEQTK+gJzE+zILhXZD0F/jwHA+U/6qnMB9n7i+DWTmkjRF a3mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=8Ef0a1YdWXB5FYOHh5J1dlJbOTNWKYy0L/Y62hBzUcg=; b=oZD6JLLwxN2D9XubBgpnX3lv7xBp+HILL/EX8GLeHUrfUQ10mbUtEgm0CpokkYVOGr rsSicMVyUu1wdJ6N7DfnpgYGh9x8rq2tpWqMcvK3c0N4NRY/gzuVRZruPrVDdStdivX2 DtHdoCdvo5IPlk/oqv16k6mrN8oD/58V1NooRdGu4xmRK+qVjxEd0A24DdqDGrmt9znq jMD2GJjcwOqIaFZ5OPjrmSpDc1W/hP4LOGNQvS58wt91/zGh4EZMGc67XEWajlaNKnc4 yfnRA03zcNoBzCBHEOHaPN9J9NXNqgQAqWKFKU/YlcCVXBkV2f2OgDqa39Z3fuDC8xnA vwjA== X-Gm-Message-State: ACgBeo2ATuGrYvdzeRGgbq54kogA2rF40EUQphFTS6jU5ssZM5dTtNfE SDzNL8PxvpdJBSC6W5H+33LOBb3qA8h/sfRsfyE= X-Google-Smtp-Source: AA6agR4y5ea220ARgdJNOLQBWW69M2qza51tOJH4AaWebZGHaPkBgtiYOtGd1+HdEDfdtf663V9LVYX1ODxFzE2CjFo= X-Received: by 2002:a05:6402:550c:b0:443:7d15:d57f with SMTP id fi12-20020a056402550c00b004437d15d57fmr30232654edb.147.1663155078732; Wed, 14 Sep 2022 04:31:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Wed, 14 Sep 2022 13:31:06 +0200 Message-ID: Subject: Re: commit signing To: Ulrich Drepper Cc: Ulrich Drepper via Gcc Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,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: On Wed, Sep 14, 2022 at 11:12 AM Ulrich Drepper via Gcc wrote: > > 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. How does this improve supply chain security if the signing happens automagically rather than manually at points somebody actually did extra verification? That is, what's the attack vector this helps with? What's the extra space requirement if every commit is signed? I suspect the signatures themselves do not compress well. Richard. > > Opinions?