git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: <rsbecker@nexbridge.com>
To: "'Sean Allred'" <allred.sean@gmail.com>
Cc: "'Junio C Hamano'" <gitster@pobox.com>, <git@vger.kernel.org>,
	<sallred@epic.com>, <grmason@epic.com>, <sconrad@epic.com>
Subject: RE: Dealing with corporate email recycling
Date: Sun, 13 Mar 2022 10:20:42 -0400	[thread overview]
Message-ID: <01f201d836e5$89247c30$9b6d7490$@nexbridge.com> (raw)
In-Reply-To: <87zglu9c82.fsf@gmail.com>

On March 13, 2022 10:01 AM, Sean Allred wrote:
><rsbecker@nexbridge.com> writes:
>> Is there anything we could do around the new signature infrastructure
>> relating to this? I am NOT a fan of SSH keys without passphrases, but
>> what if we could use the coaxing above and map to SSH expiring keys
>> then stitch in signatures (a.k.a. sign the commits) to correspond to
>> the users in the given timeframe - then destroy the private keys to
prevent
>further signing.
>> After that the Name/email becomes somewhat irrelevant from an
>> integrity standpoint.
>
>Is this really possible?  Is it really as straightforward as splicing in
some text into the
>commit message to the effect of 'this commit is signed' along with some
signature
>artifact calculated pre-signing?
>
>Though I'll note I *think* this would only solve the problem for the
committer field
>-- it's my current understanding that a commit can only be signed by one
>signature.  (I have heard of systems that generate a new key that is then
signed by
>multiple signatures, then signing with that new key -- but even if this is
possible, it
>seems pretty involved for such a common workflow.  This level of
coordination
>might not be possible for us -- especially given the merge workflows we've
>needed to create to accommodate our current release process.)

(I am a little nervous about this advice, hoping others will chime in and
correct anything wrong here)

While this will change the commit hashes, AFAIK, the other metadata is
preserved, including date, author, and committer. Set up the specific
keys/settings in ssh-agent and the user.signingKey value, then:

git filter-branch --commit-filter 'git commit-tree -S "$@";'
<FROM-COMMIT>..<TO-COMMIT>

Others might have a better way of doing this or may tell me this will not
work. Test this before you do it. I have not done this operation before. You
do need to start from the oldest commit going forward otherwise I think that
filter-branch will (should!) invalidate child commits. I suspect this is
going to be a rather lengthy script to build and run.


  reply	other threads:[~2022-03-13 14:20 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-12 22:38 Dealing with corporate email recycling Sean Allred
2022-03-13  0:03 ` Junio C Hamano
2022-03-13  0:26   ` rsbecker
2022-03-13 14:01     ` Sean Allred
2022-03-13 14:20       ` rsbecker [this message]
2022-03-13 14:41         ` Sean Allred
2022-03-13 15:02           ` rsbecker
2022-03-13 15:21             ` Sean Allred
2022-03-13 19:57               ` Philip Oakley
2022-03-13 22:40                 ` Sean Allred
2022-03-13 23:16                   ` Junio C Hamano
2022-03-13 23:23                     ` rsbecker
2022-03-14  0:19                       ` Junio C Hamano
2022-03-14 11:56                     ` Philip Oakley
2022-03-14 21:24                       ` Junio C Hamano
2022-03-14 22:25                         ` Philip Oakley
2022-03-15  1:23                       ` Sean Allred
2022-03-15 11:15                         ` Philip Oakley
2022-03-13 12:20 ` Philip Oakley
2022-03-13 13:35   ` Sean Allred
2022-03-14 11:59     ` Philip Oakley
2022-03-13 15:51 ` Ævar Arnfjörð Bjarmason
2022-03-13 17:22 ` brian m. carlson
2022-03-13 17:52   ` rsbecker
2022-03-13 19:47     ` rsbecker
2022-03-13 22:23       ` Sean Allred
2022-03-15  1:27 ` Sean Allred
2022-03-18 21:22 ` Peter Krefting

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='01f201d836e5$89247c30$9b6d7490$@nexbridge.com' \
    --to=rsbecker@nexbridge.com \
    --cc=allred.sean@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=grmason@epic.com \
    --cc=sallred@epic.com \
    --cc=sconrad@epic.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).