Rebasing commits and re-signing before mergeing (Was: ‘core-updates’ is gone; long live ‘core-packages-team’!)

[Vagrant Cascadian <vagrant@debian.org>]

[-- Attachment #1: Type: text/plain, Size: 3402 bytes --]

On 2024-09-06, Leo Famulari wrote:
> On Fri, Sep 06, 2024 at 10:44:54AM -0700, Vagrant Cascadian wrote:
>> Is it just me, or is rebasing branches disconcerting, as it likely means
>> the person signing the commit is not necessarily the original person
>> pushing the commit? This is worst for the now deprecated core-updates
>> branch with many rebased commits... are people still updating the
>> signed-off-by tags or whatnot?
>
> In Guix, the "signed-off-by" tag gives credit to the reviewer of the
> patch, but doesn't indicate anything about authority to push to
> guix.git.

That sounds more like a Reviewed-by tag.

from doc/contributing.texi:

  When pushing a commit on behalf of somebody else, please add a
  @code{Signed-off-by} line at the end of the commit log message---e.g.,
  with @command{git am --signoff}.  This improves tracking of who did
  what.
...
  @cindex Reviewed-by, git trailer
  When you deem the proposed change adequate and ready for inclusion
  within Guix, the following well understood/codified
  @samp{Reviewed-by:@tie{}Your@tie{}Name@tie{}<your-email@@example.com>}
  @footnote{The @samp{Reviewed-by} Git trailer is used by other projects
  such as Linux, and is understood by third-party tools such as the
  @samp{b4 am} sub-command, which is able to retrieve the complete
  submission email thread from a public-inbox instance and add the Git
  trailers found in replies to the commit patches.} line should be used to
  sign off as a reviewer, meaning you have reviewed the change and that it
  looks good to you:
  

> In all cases, a commit that is pushed to guix.git will be signed by an
> authorized committer. The signature system ensures that.
>
> If we are concerned about long-running branches being rebased and
> commits losing their "original" signatures, I think it's not really
> something to worry about. That's because the signature *only* tells us
> that that the commit was signed by someone who is authorized, and it
> tells us *nothing* else. The code-signing authorization is extremely
> limited in scope. It doesn't tell us that the code works, is freely
> licensed, is not malicious, etc. So, it doesn't matter who signs a
> commit, as long as it is signed by an authorized person.

My understanding of what properly signed commits tell me, at least in
the context of Guix, is that the person who has signed a given commit
has made reasonable efforts to ensure the code works, is freely
licensed, and is not malicious, etc.

That they agree to do those sorts of things and have a history doing
those things is why some people are trusted (e.g. authorized) to push
commits.

Mistakes happen, and that is fine, but having the signatures allows some
way to review who did what when unfortunate things inevitably happen, to
try and come to understanding of what to do better in the future.


What concerns me, is with rebasing hundreds (thousands?) of commits
(e.g. recent core-updates rebase & merge), many of which were originally
reviewed by someone other than the person signing the commit, and
re-signing them reduces the confidence that the signature indicates
processes were appropriately followed...


guix pull does protect against moving to unrelated histories, so
probably the worst dangers of rebasing will at least trigger some
warning!


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]