Re: Dealing with corporate email recycling

From: Sean Allred <allred.sean@gmail.com>
Date: Mar 13, 2022, 14:01 UTC
Message-ID: <87zglu9c82.fsf@gmail.com>
In-Reply-To: <01cc01d83671$0acd4a20$2067de60$@nexbridge.com>

<rsbecker@nexbridge.com> writes:

Show 7 quoted lines

> 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.)

-- Sean Allred