Hi! Marius Bakke <mar...@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’.
