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