[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Heads-up: hard reset of the 'staging' branch
From: |
Marius Bakke |
Subject: |
Re: Heads-up: hard reset of the 'staging' branch |
Date: |
Fri, 29 May 2020 20:18:27 +0200 |
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.
signature.asc
Description: PGP signature