Re: 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: 2776 bytes --]

On 2024-09-07, Leo Famulari wrote:
> On Fri, Sep 06, 2024 at 01:29:11PM -0700, Vagrant Cascadian wrote:
>> > 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.
>
> We used the signed-off-by tag for years before we started signing
> commits, so in Guix it has also indicated the person who performed the
> primary review of the patch / commit.

Well, guix documentation mentions both Signed-off-by and Reviewed-by,
even if historically there was different practice in use...

Given that "pushing a commit on behalf of someone else" also necessarily
requires for all practical purposes "signing" the commit with a valid
key, I read that as the two going together. Although there might be a
Signed-off-by by someone other than the signer.

Not a huge deal, really, in any case.


>> 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.
>
> I see. That's a misconception. The commit signature can only be used as
> a code-signing authorization tool, to control access to the
> authoritative copy of the codebase and, transitively, to control access
> to users' computers.
>
> The project leadership does aim to only authorize people they believe
> will make the efforts you describe above.
>
> But in Guix, the requirement to make those efforts is only enforced
> socially.
>
> There are no mechanisms to ensure that the build is not broken on the
> master branch, etc.

I do not see the distinction between social and tehnical mechanisms here
as... meaningful?

The code-signing authorization tool (e.g. technical) is useful way to
track that social agreements of the project are being respected
(e.g. social) or not, and a mechanism to maintain those agreements. That
it also tracks the authoritative codebase seems a desireable
side-effect... which has both social and technical elements.


I have no illusions that someone could push a broken commit or otherwise
imperfect commit; I have even done so myself at least once or twice! The
question is more what to do when that happens, or repeatedly happens,
which has various technical measures to enforce the social norms.


live well,
  vagrant

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