From owner-freebsd-current@freebsd.org Wed Dec 23 16:24:21 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8E60F4C3BF6 for ; Wed, 23 Dec 2020 16:24:21 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D1JSN5MBNz3NWf; Wed, 23 Dec 2020 16:24:20 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: by sdaoden.eu (Postfix, from userid 1000) id 1774016057; Wed, 23 Dec 2020 17:24:18 +0100 (CET) Date: Wed, 23 Dec 2020 17:24:17 +0100 From: Steffen Nurpmeso To: Brooks Davis , Thomas Mueller , freebsd-current@freebsd.org Cc: Theodore Ts'o Subject: Re: HEADS UP: FreeBSD src repo transitioning to git this weekend Message-ID: <20201223162417.v7Ce6%steffen@sdaoden.eu> In-Reply-To: <20201223023242.GG31099@funkthat.com> References: <31ab8015-a0c4-af77-0ead-a17da0f88f1d@freebsd.org> <5fdc0b90.1c69fb81.866eb.8c29SMTPIN_ADDED_MISSING@mx.google.com> <20201218175241.GA72552@spindle.one-eyed-alien.net> <20201218182820.1P0tK%steffen@sdaoden.eu> <20201223023242.GG31099@funkthat.com> Mail-Followup-To: Brooks Davis , Thomas Mueller , freebsd-current@freebsd.org, Theodore Ts'o User-Agent: s-nail v14.9.20-84-g7268a84d OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. X-Rspamd-Queue-Id: 4D1JSN5MBNz3NWf X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.30 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[217.144.132.164:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sdaoden.eu]; NEURAL_HAM_LONG(-1.00)[-1.000]; SPAMHAUS_ZRD(0.00)[217.144.132.164:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MID_CONTAINS_FROM(1.00)[]; FREEMAIL_TO(0.00)[freebsd.org,twc.com]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15987, ipnet:217.144.128.0/20, country:DE]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2020 16:24:21 -0000 John-Mark Gurney wrote in <20201223023242.GG31099@funkthat.com>: |Steffen Nurpmeso wrote this message on Fri, Dec 18, 2020 at 19:28 +0100: |> Brooks Davis wrote in |> <20201218175241.GA72552@spindle.one-eyed-alien.net>: |>|On Thu, Dec 17, 2020 at 05:53:20PM -0800, Thomas Mueller wrote: ... |>|Signed commits have no practicl effect on users of a repo. |> |> Well you can verify integrity of a repository regardless of how it |> was distributed, this is why it is done, right. ... |TL;DR I don't see any reason for devs to sign commits. | |I could see use for RE (or another entity) to occasionally (weekly?) |sign the repo (say COPYRIGHT or UPDATING), and it would be nice for |them to sign all the tags used for releases, but having every dev |would both make the dev's life difficult... Sure. Signing at least releases makes a lot of sense. Your idea of periodically sealing the tree is interesting, because it can even be automatized (dependent on the key). stable/ patch pumpkins could sign at least the last commit they cherry pick back to stable, aren't ehy in distress already :) |It's also hard to collect ALL the keys of the devs at any point in |time to decide if that key is authorized to sign a commit in the |repo... Like if a dev starts in 2021, any commits made by that |dev prior to 2021 should not be "valid".. Then there's also the |issue that people's keys change over time, and now you need to know |what time period each key was valid for, otherwise a compromised key |could be used to insert malicious changes into your/the tree... | |Then there's also the point that the repo is (looks like it) using |SHA-1 hashes, which are effectively broken, so depending upon them |to validate the tree is questionable anyways. git uses the hardened SHA-1 for sure, which is, as far as i know, at least safe against the known attack. I .. have not tracked this, but i think upgrading to SHA-256 is possible, once this will become standard. Just even more metadata, then. I have not looked into this, still in progress. Imho: devs should show "muchos cojones". I am sure you appreciate a daunting post, i think it is ok to quote this post from openssl-dev@openssl.org ("Re: Attribution of pull requests in git"): Theodore Ts'o wrote in <20140426145907.GA1278@thunk.org>: |On Sat, Apr 26, 2014 at 11:29:39AM +0100, Ben Laurie wrote: |> I just noticed that if I merge a pull request, then both author and |> committer are set to whoever made the pull request. | |Are you using github, or git using its standard pull request workflow? | |In the standard git workflow, the author and committer is set to the |person who merged the pull. The person who requested the pull request |is recorded in the signed git tag. For example, I recently signed a |git tag: | |% git tag -s ext4_for_linus_stable | | Wonderful. |% git push ssh://gitolite@ra.kernel.org/pub/scm/linux/kernel/git/tytso/e\ |xt4.git tags/ext4_for_linus_stable | | Ah yes. Correct enough for German public law television at its best! |% git request-pull origin git://git.kernel.org/pub/scm/linux/kernel/git/\ |tytso/ext4.git tags/ext4_for_linus_stable > /tmp/pull | |(I have aliases and shell scripts for most of this, but I've expanded |all of this out for clarity.) | |Then I e-mailed the following to Linus, and then after he merged the |pull request, when I pulled down his tree, tou can see the following: | |% git show --pretty=fuller --show-signature origin |commit 9ac03675010a69507c0a9d832d6a722e07d35cc6 |merged tag 'ext4_for_linus_stable' |gpg: Signature made Sun 20 Apr 2014 10:23:16 PM EDT using RSA key ID \ |C11804F0 |gpg: Good signature from "Theodore Ts'o " |gpg: aka "Theodore Ts'o " |gpg: aka "Theodore Ts'o " |Merge: a798c10 0a04b24 |Author: Linus Torvalds |AuthorDate: Sun Apr 20 20:43:47 2014 -0700 |Commit: Linus Torvalds |CommitDate: Sun Apr 20 20:43:47 2014 -0700 ... |The advantage of doing this way is that git will detach the signature |from the tag, and save it in the merge conflict, so years later, the |cryptographic accountability chain is preserved in the git tree. | |Cheers, Hope that helps. I personally sign releases and (at least the head of a bunch of) commits to [master] and [stable] (it is a git alias which does it). Looser that i am i have a setup-privacy script on an encrypted partition that loads keys, unfortunately not even root can kill -SOMESIG to cause all ssh-agents etc to unload and clear the loaded keys, therefore i hook acpi and do something like if command -v ssh-add >/dev/null 2>&1; then for a in /tmp/ssh-*/agent.*; do [ -e "$a" ] || continue act '( SSH_AUTH_SOCK="$a" ssh-add -D ) /dev/null 2>&1 &' done fi Luckily i do not yet use per-user private temporary directories. All in all it is terrible mess. A good afternoon from Germany i wish. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)