Re: gpg verify git sub modules useful?

[Stefan Beller <sbeller@google.com>]

On Wed, Mar 1, 2017 at 10:28 AM, Patrick Schleizer
<patrick-mailinglists@whonix.org> wrote:
> Good questions, thank you for trying to figure out what I am asking. :)
>
> Junio C Hamano:
>> 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?

The signing in Git is just signing the commit hash essentially.

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

That is my understanding. There is no difference between the security of
a file or a submodule, just the way of obtaining and its reporting is different.
Both a file and a submodule are referred to via a hash (currently sha1).
Obtaining a file is implicit whereas obtaining the submodule is explicit.
The reporting (in e.g. git-status) ... depends on a lot of options to be set.

When signing the superproject, you acknowledge the submodules
being in the state as recorded. (Same with s/submodules/files/)

So I am not sure what kind of additional signing you're looking
for in the submodules.

Thanks,
Stefan