Re: Dealing with corporate email recycling

[Sean Allred <allred.sean@gmail.com>]

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

--
Sean Allred