Ludovic Courtès writes: > Hi! > > Marius Bakke 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 .) 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.