Re: Soundness of signature verification excluding unsigned empty merges

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Lundkvist Per <per.lundkvist@xxxxxxxxxxxxx> writes:

> But it seems like if we allow unsigned empty merge commits, i.e. those that
> themselves do not introduce any any other change than what its parents
> introduce, and require all other commits to be properly validated, then we can
> safely validate the whole repository?

Depends on what you are trying to protect against, I would think.

Two tl;dr of it are

 * a merge that does "not introduce any other change than what its
   parents introduce" can still cause harm to the codebase.

 * a merge that introduces other changes may very well be necessary
   to merge two histories.

Each commit signed by known/authorized people is simple.  But what
does it mean for them to sign an individual commit in the first
place?  "I wrote it" is too naive an answer ;-)

A commit that is perfectly good in one context may cause the
codebase to do a totally wrong thing in a different context, so your
sign on the commit itself may assure others that you as the area
expert vouches for the change in its original context, but will that
signature be good enough to hold you responsible for the catastrophe
it may cause by merging the history leading to the commit to a
history that has forked from the original one long ago?



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux