Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

From: Steffen Nurpmeso <steffen_at_sdaoden.eu>
Date: Wed, 23 Dec 2020 17:24:17 +0100
John-Mark Gurney wrote in
 <20201223023242.GG31099_at_funkthat.com>:
 |Steffen Nurpmeso wrote this message on Fri, Dec 18, 2020 at 19:28 +0100:
 |> Brooks Davis wrote in
 |>  <20201218175241.GA72552_at_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_at_openssl.org ("Re: Attribution of
pull requests in git"):

  Theodore Ts'o wrote in
   <20140426145907.GA1278_at_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
   |
   | <Insert smart card, type the pin to create the GPG signed tag>

Wonderful.

   |% git push ssh://gitolite_at_ra.kernel.org/pub/scm/linux/kernel/git/tytso/e\
   |xt4.git tags/ext4_for_linus_stable
   |
   | <Type pin to unlock the ssh key, which is also on the smart card>  

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 <tytso_at_mit.edu>"
   |gpg:                 aka "Theodore Ts'o <tytso_at_debian.org>"
   |gpg:                 aka "Theodore Ts'o <tytso_at_google.com>"
   |Merge: a798c10 0a04b24
   |Author:     Linus Torvalds <torvalds_at_linux-foundation.org>
   |AuthorDate: Sun Apr 20 20:43:47 2014 -0700
   |Commit:     Linus Torvalds <torvalds_at_linux-foundation.org>
   |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 >/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)
Received on Wed Dec 23 2020 - 15:24:21 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:26 UTC