[libvirt] [PATCH hooks 1/1] Add check for Signed-off-by in commit messages

Daniel P. Berrangé berrange at redhat.com
Thu Jan 25 16:33:13 UTC 2018


On Thu, Jan 25, 2018 at 11:13:40AM +0100, Peter Krempa wrote:
> On Mon, Jan 22, 2018 at 13:57:07 +0000, Daniel Berrange wrote:
> > On Mon, Jan 22, 2018 at 02:20:52PM +0100, Peter Krempa wrote:
> > > On Mon, Jan 22, 2018 at 13:06:28 +0000, Daniel Berrange wrote:
> > > > On Mon, Jan 22, 2018 at 01:20:12PM +0100, Peter Krempa wrote:
> > > > > On Mon, Jan 22, 2018 at 12:05:19 +0000, Daniel Berrange wrote:
> > > > > > This extends the update hook so that it enforces a requirement to have a
> > > > > > Signed-off-by line in every commit message. This can be optionally
> > > > > > turned off in individual repos by setting the "hooks.allowmissingsob"
> > > > > > git config variable.
> > > > > > 
> > > > > > Signed-off-by: Daniel P. Berrange <berrange at redhat.com>
> > > > > > ---
> > > > > >  update | 16 +++++++++++++++-
> > > > > >  1 file changed, 15 insertions(+), 1 deletion(-)
> 
> [..]
> 
> > > The sign-off by itself (whithout cryptographic signature) is just
> > > pointless. Validity with a cryptographic signature from drive-by
> > > contributors can still be unproven, but at least you don't get
> > > impersonation.
> > 
> > I think these are two different axis. The sob isn't trying to address the
> > question of impersonation. It obviously has as a starting point that you
> > accept the identity of the submitter to some degree. I accept that if you
> > have cryptographically signed patches, that would give a stronger
> > validation of identity, but there's never any absolutes. So not having
> > a crypto signature doesn't make the sob invalid.
> 
> In that case basically nothing changes, since if we are going to use
> this to be safe from licensing disputes, the reviewer/commiter still
> needs to make sure that the code complies with our licensing. Asserting
> the signoff changes nothing in that regard
> 
> > 
> > > If everything is signed off, nothing really is.
> > 
> > I don't really see that.
> > 
> > > NACK still stands.
> > 
> > You are nacking something that you've accepted above will have no negative
> > impact on your work, but has potentially significant upside to the project.
> > That is very disappointing.
> 
> I think that by doing this we'll put too much false hope into the
> "potentially significant upside". I just hope it will not bite us.
> 
> Anyone can assert, or sign-off anything [1].
> 
> Given the overwhelmingly positive approach to this retract my NACK, the
> only thing that will change in general is that my commits will grow one
> line.

Thanks, I appreciate that.

FYI, i'm not going to push the hook right now, since I'm on holiday for
3 days and its always bad to do changes to dev workflow before going
away :-)  I'll do it next week when i return....

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|




More information about the libvir-list mailing list