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

[Ludovic Courtès]

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>.)

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.

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!

Ludo’.