Re: Heads-up: hard reset of the 'staging' branch

[Marius Bakke <marius@gnu.org>]

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

Ludovic Courtès <ludo@gnu.org> writes:

> Hi!
>
> Marius Bakke <marius@gnu.org> skribis:
>
>> I have good news and bad news.  The good news is that the new commit
>> verification infrastructure works great.  'make authenticate' will
>> verify that all commits were signed by a key that was authorized by
>> .guix-authorizations at that point in time.
>>
>> The bad news is that we need to ensure .guix-authorizations has been
>> updated on any branches that new committers/keys will be pushing to.
>> Currently the 'staging' branch has one commit
>> (8229ce3116c1f522c7157ab2dcd50dc2d765686a) signed by a
>> not-yet-authorized key (it had been authorized on 'master' by
>> d074f73aacc5a39aed0202d6e45721f53f34a8c0, but that was not yet merged to
>> 'staging' at the time).
>>
>> To fix it properly without leaving a gap where 'make authenticate' will
>> fail, we actually need to rewrite the history.  Luckily git supports
>> rebasing merges(!), and the merge we need was the next commit on that
>> branch.
>
> To be clear, it wouldn’t just “leave a gap”: all future commits would
> also be rejected.  The authentication code ensures that each commit is
> signed by one of the keys authorized in its parent commit(s).  (See the
> latest discussions at <https://issues.guix.gnu.org/22883>.)

Indeed, sorry for being unclear.  The gap I was referring to was based
on a hypothetical situation where we worked around this issue in
git-authenticate.scm, similar to %commits-with-known-bad-signature.

> This is a good opportunity to remind all fellow committers of the latest
> changes in that area, which are summarized here:
>
>   https://guix.gnu.org/manual/devel/en/html_node/Commit-Access.html
>
> Please take a look.
>
> SCARY WARNING:
>
>   When ‘guix pull’ runs that authentication code, which I hope will be
>   the case in a few weeks, any such mistakes means that users will not
>   be able to pull at all, so we all have to be very cautious.  If we do
>   make a mistake, we’ll have to reset the branch to a known-good state,
>   like you did.

I am really looking forward to strong authentication in 'guix pull'.
Sounds like a good excuse to make a new release!  :-)

> That said… thanks *a lot* for carrying out this rebase, Marius!  I’ve
> never done a rebase including merge commits before (sounds scary!), and
> I learned that ‘git rerere’ is not a typo.  Thumbs up!

Rebasing merges was a first for me too, and hopefully a last!  I only
learned about (and enabled) 'git rerere' recently and it has saved me a
lot of time already, mainly when a merge had to be aborted and redone.

But it's a double edged sword, no wonder it's not enabled by default.

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