Sign old commits prior to enforcing commit signature

[jeff-mccoy]

We should scrub the commit history for old commits and verify their authenticity cryptographically to ensure a clean/validated git history. One possible way to do it: https://superuser.com/a/1123928

[RothAndrew]

@jeff-mccoy is this still something we need to do? If so is it something you have to do or can one of us do it with a little guidance?

[RothAndrew]

Assigning @jeff-mccoy since I believe he is specifically the person that needs to do this.

[jeff-mccoy]

I think you do too 😂, but thanks I'll do mine.

[RothAndrew]

Oh? I'm not aware of me needing to do anything. AFAIK I've been doing signed commits since I started in August since we turned on the requirement right around that time. I think this is to go back and sign old commits prior to August, which would have just been you and Josh

[jeff-mccoy]

there are 4 commits at the beginning from Josh, initially we had two separate repos working similar problems, pushed everything to his repo so we could work together, but they ended up moving to another project instead. There's actually no code left from that initial work he pushed so not sure if we need to have him sign it or just squash it. I have most of the missing sigs early on, but you have some too: https://github.com/defenseunicorns/zarf/commits?after=acd5dc445c5131a7afd39ec7acbde8d308d27caa+34&author=RothAndrew

[RothAndrew]

Gotcha. I'll go take a look at those. https://superuser.com/a/1123928 is still the right way to do it? We'll have to turn off the branch protection on master to force push to it.

[jeff-mccoy]

I think so but let's wait post-merge of the big pr because I don't want to know what a force push will do to the rebasing on that branch.

[RothAndrew]

We could, like, not do it at all 😜 . Force pushing to change history always gives me the willies.

[jeff-mccoy]

Nice...but no we need proper attribution of code in the repo.

[jeff-mccoy]

Okay now that we had to do a force-push tonight to get #237 merged without breaking it's signatures, I think this is the right time to also fix this issues to avoid another force-push in the future. I’ve experimented with different ways to do this and think that using git rebase --signoff is the most logic choice. Basically every method causes some sort of rewrite, but this preserves the author, message, contents and timestamp for the commits, it's also a built-in feature of git. Some more notes on this can be found at https://stackoverflow.com/a/1962112/467373.

I used the command git rebase --signoff --root --committer-date-is-author-date -s recursive -X ours and then made a final commit to fix some small README.MD merge messiness (there were dozens of merge conflicts within that file for some reason on rebase).

You can see at the master-signature-test that this actually annotated every commit all the way back to the first one so now all have a verified signature.

I did see that some merge-ceptions that say partially verified, but I think we'd have to go and rewrite those old branches to fix that issue as the secondary PRs themselves have unverified commits somehow.

Before:

After:

Github:

[jeff-mccoy]

I should also mention even though this will rewrite history and all hashes, moving in-progress branches isn't super hard, just need to use reset soft + stash to move the affected files. The hardest part would be if you had a lot of commits ahead and you wanted to preserve them with messages, you'd have to do the same process but one reset/stash per commit.

[YrrepNoj]

I'm not worried about in-progress branches with this approach. git rebase -i is simple enough and we can use git rerere if there are early conflicts with the rebase.

I think I need a little more info to understand what you mean by rewriting the old branches to fix the partially verified commits.

Either way, I think this is the best approach and something we should get out of the way sooner than later.

[jeff-mccoy]

That's a speculation on partially verified. What I was trying to say is that partially verified issue exists already and this branch doesn't immediately fix that. It has to do with how GitHub is evaluating PRs associated with a commit. This is not a git thing, this branch fixes the git signature issue properly. But GitHub has some magic it does for PRs tagged in a commit, if you click on one you'll see that's what's breaking.

[RothAndrew]

LGTM

[jeff-mccoy]

Okay I think if @RothAndrew concurs we'll proceed.

[RothAndrew]

LGTM

[jeff-mccoy]

Confirmed with @RothAndrew @YrrepNoj and @mike-winberry, proceeding with the force-push

[mike-winberry]

LGTM too!

[jeff-mccoy]

Couple notes on updating master locally that I had to do (alternative could be just reclone or delete local master):

git config pull.rebase true
git pull --force  --allow-unrelated-histories

[RothAndrew]

Can we call this backlog item done?

[jeff-mccoy]

Yeah I guess GitHub didn't know how to auto-close the tagged issue on history rewrite 😂