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