On Thu, Apr 19, 2018 at 05:29:22PM +0100, Daniel P. Berrangé wrote:
On Thu, Apr 19, 2018 at 06:11:20PM +0200, Martin Kletzander wrote:
> On Thu, Apr 19, 2018 at 10:06:45AM +0100, Daniel P. Berrangé wrote:
> > On Thu, Apr 19, 2018 at 10:55:01AM +0200, Peter Krempa wrote:
> > > On Wed, Apr 18, 2018 at 18:35:18 +0100, Daniel Berrange wrote:
> > > > The "git-publish" tool is a useful git extension for sending
patch
> > > > series for code review. It automatically creates versioned tags
> > > > each time code on a branch is sent, so that there is a record of
> > > > each version. It also remembers the cover letter so it does not
> > > > need re-entering each time the series is reposted.
> > > >
> > > > With this config file present it is now sufficient[1] to run
> > > >
> > > > $ git publish
> > > >
> > > > to send all patches in a branch to the list for review
> > > >
> > > > [1] Assuming your $HOME/.gitconfig has an SMTP server listed
> > > > at least e.g.
> > > >
> > > > [sendemail]
> > > > smtpserver =
smtp.example.com
> > > >
> > > > Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
> > > > ---
> > > > .gitpublish | 3 +++
> > > > 1 file changed, 3 insertions(+)
> > > > create mode 100644 .gitpublish
> > > >
> > > > diff --git a/.gitpublish b/.gitpublish
> > > > new file mode 100644
> > > > index 0000000000..857f0d552c
> > > > --- /dev/null
> > > > +++ b/.gitpublish
> > > > @@ -0,0 +1,3 @@
> > > > +[gitpublishprofile "default"]
> > > > +base = master
> > > > +to = libvir-list(a)redhat.com
> > >
> > > ACK
> > >
> > > As a side-question. Does git-publish have the option to send GPG-signed
> > > mails? I always wanted that, but not enough to hack it into
> > > git-send-email.
> >
> > Not that I'm aware of. The only common use of GPG is for signing tags
> > associated with pull requests. eg when you do git publish --pull,
> > it will create a signed tag for that pull request. We don't use the
> > submaintainer model though so that's not really relevant to us.
> >
> > Stefan takes features requests / patches on github/stefanha/git-publish
> > though :-)
> >
>
> Yeah, I always wondered how to do it nicely. I have signed commits turned on,
> but if I take a commit that is even verified by github, (and looks great with
> `git show --show-signature`), I have no way how to send them using send-email so
> that the signing is preserved. Would be nice to know if there's a way.
Based on what I've read, I don't think signatures can work with an email
based patch workflow, nor with a fast-forward based process.
If someone signs a patch, IIUC that covers the body, the comit message, and
all the metadata including committer and author fields and parent commit
hash. When you send a patch and then a reviewer applies the patch, the
committer field gets changed to name of the person applying it. The parent
commit hash also gets changed to whatever is HEAD when you apply it. Both
these changes neccessarily invalidate any signature that could be attached
to the mail.
The only way I can see signatures working is if you exchange patches using
"git bundle" so you're sending the full git object, not just a patch file.
This will neccessitate you using merge commits in the repository, not
fast-forward.
So commit signatures look unusable for a development model based around
exchange of patches on the list as libvirt does.
They could be used to some extent with a sub-maintainer model, but only
the sub-maintainers would be able to sign commits, for those going into
the pull request. Individual contributors still wouldn't be able to sign
in general since sub-maintainers just pull patches off the mailing list
and git am them - only the final pull requests as done with merge commits.
Sure, I never meant the commits should stay signed. It doesn't really
make much sense in most scenarios to have individual commits signed.
Signed tag is an inherent sign for all parent commits, which is more
than enough. What I wanted to have established was a way for the people
receiving the commit to be able to see that it really came from me and
it was not tampered with. For that case I only care about the medium
(through which the commit is sent) to be covered. That's the only part
of the chain where I'm missing some effort to enhance integrity and
accountability.
Martin