RE: Dealing with corporate email recycling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On March 13, 2022 10:01 AM, Sean Allred wrote:
><rsbecker@xxxxxxxxxxxxx> 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.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux