Junio C Hamano wrote: > 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? OK, got it. For certain type of commits there may be opportunities in time where it is possible to reintroduce these old signed commits cleanly with an unsigned merge, and this is a type of attack this validation strategy would not protect against. Thanks!
