Konstantin Ryabitsev <konstantin@xxxxxxxxxxxxxxxxxxx> writes: > If I know that a project uses tag signing, would "git clone" followed > by "git verify-tag" be meaningful without a "git fsck" in-between? > I.e. if an attacker has control over the remote server, can they sneak > in any badness into any of the resulting files and still have the > clone, checkout, and verify-tag return success unless the repository > is fsck'd before verify-tag? > > I assume that it would break during the checkout stage, but I wanted > to verify my assumptions. What you are trusting and what you are trying to protect? I am assuming that you are cloning and a commit that has a signed tag is at the tip of the default branch, which gets checked out and you want to make sure that what you see in the working tree after checkout is healthy. I also assume that you trust your local machine, its Git and GPG binary included, and also you trust that the underlying hash function Git uses has not been exploited for this particular repository. verify-tag would tell you that the tag you specify is signed by which GPG key you have in your keychain. Since tag records the commit object name, you can check it against the HEAD. As long as you trust the underlying hash function and your local Git, the trust flows from the HEAD's commit object name down to each and every file checked out to the working tree. As long as you did not get any error from checkout, no fsck is needed here. If your project is high-valued target like the Linux kernel, it is probably a good idea to enable fetch.fsckobjects so that the incoming objects are automatically checked while receiving over the wire.
