Re: gpg verify git sub modules useful?

From: Patrick Schleizer <patrick-mailinglists@whonix.org>
Date: Mar 1, 2017, 18:28 UTC
Message-ID: <8cdd9f2d-415c-1b60-0017-bf973e8cf914@riseup.net>
In-Reply-To: <xmqqmvd6kykc.fsf@gitster.mtv.corp.google.com>

Good questions, thank you for trying to figure out what I am asking. :)

Junio C Hamano:

Show 8 quoted lines

> Patrick Schleizer <patrick-mailinglists@whonix.org> writes:
> 
>> When using git submodules, is there value in iterating about the git
>> submodules running "git verfiy-commit HEAD" or would that be already
>> covered by the git submodule verification?
> 
> That depends on what you are referring to with the "git submodule
> verification"

cd submodule
if ! git verfiy-commit HEAD ; then
   error
fi

> and more importantly what threat you are guarding
> against.

All main (non-submodule) (merge) commits and submodule (merge) commits are signed by me.

1) git --recursive clone main (non-submodule) git repository
2) cd git main repository
3) git verify-commit HEAD or git verify-tag tag-name
4) git submodule update

What if the main (non-submodule) git repository gpg signature was okay but then after git fetched the submodules these compromised (MITM'ed) ones?

Does the having gpg verified the root (main git repository) ensure that submodule commits are also quasi verified?

> "git -C <submodule-dir> verify-commit HEAD" may make sure
> that the contents of that commit object is GPG signed by whoever you
> trust--is that what you want to make sure?

> Or do you want all
> commits in the submodule history to be similarly signed because the
> tree of the superproject can switch to some other commit there?

I guess so.