From: "Randall S. Becker" <rsbecker@nexbridge.com>
To: "'brian m. carlson'" <sandals@crustytoothpaste.net>,
"'Soni L.'" <fakedme+git@gmail.com>
Cc: <git@vger.kernel.org>
Subject: RE: Cross-signing commits
Date: Fri, 5 Mar 2021 18:45:26 -0500 [thread overview]
Message-ID: <022c01d71219$a18eed60$e4acc820$@nexbridge.com> (raw)
In-Reply-To: <YEKpoiy//SR5Nt3q@camp.crustytoothpaste.net>
On March 5, 2021 4:59 PM, brian m. carlson wrote:
> On 2021-03-05 at 21:53:14, Soni L. wrote:
> > On 2021-03-05 6:44 p.m., brian m. carlson wrote:
> > > Can you explain what you mean by "cross-signing"? Are you proposing
> > > a situation where two parties sign the same commit?
> >
> > Yep. See, the repos enforce signing, but they can also be forks. If
> > someone wants to track upstream in one of their branches they just
> > can't. Would be cool if they could just say they trust the commits by
> > signing the relevant commits with their own key instead - on the
> > assumption that they actually reviewed said commits.
>
> Git doesn't natively support having multiple signatures in a commit, although
> it is of course possible to do, since OpenPGP supports it.
> However, as you noted, changing the signature changes the object ID, so if
> you re-sign a commit for any reason, that changes the commit ID.
> There isn't any way around this at all; that's just how it works.
>
> So you can either re-sign or have an unchanged commit ID, but not both at
> the same time.
>
> You can use additional empty signed commits or signed tags, or you can use
> some sort of external system that keeps track of additional signatures or
> approvals if you want.
If your workflow requires multiple signatures on the same commit, you have options:
1. Use signed tags. So you can put multiple OpenPGP signed tags on a commit, representing each person's individual sign-off. Tags would be my preference as they show up explicitly in the git log --decorate output. Of course you will need a naming standard for this class of tags.
2. Create empty child commits with the desired commit as parent, and each person can sign their own commit - not really a great idea as history gets messy and potentially confusing.
Regards,
Randall
-- Brief whoami:
NonStop developer since approximately 211288444200000000
UNIX developer since approximately 421664400
-- In my real life, I talk too much.
prev parent reply other threads:[~2021-03-05 23:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-05 16:47 Cross-signing commits Soni L.
2021-03-05 21:44 ` brian m. carlson
2021-03-05 21:53 ` Soni L.
2021-03-05 21:58 ` brian m. carlson
2021-03-05 23:45 ` Randall S. Becker [this message]
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='022c01d71219$a18eed60$e4acc820$@nexbridge.com' \
--to=rsbecker@nexbridge.com \
--cc=fakedme+git@gmail.com \
--cc=git@vger.kernel.org \
--cc=sandals@crustytoothpaste.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.