You seem to imply that this may cause some kind of security or
availability problem
Can you guarantee that a silently installed submodule's repo won't get hacked and replaced with malicious code for example? We have seen that happening with other repos already (github, sourceforge and other webhosts too). The fewer dependency you have, the less are the chances for a vulnerability or sechole, simple as that.
We are not blindly taking code from github, sourceforge, etc. All submodules are hosted on coreboot.org and the main repo points at the SHA it's using, and have the same guarantees as code in the main coreboot repo.
This example might help illustrate it: libgfxinit submodule: https://review.coreboot.org/plugins/gitiles/libgfxinit When somebody wants to use point at a new version: https://review.coreboot.org/c/coreboot/+/43559
But the main problem here I think is, following the tutorial
https://doc.coreboot.org/tutorial/part1.html does not work, because it results in compilation errors (due to missing dependencies). This is clearly bad and must be resolved.
Can you be more specific? I ran thru the instructions and built for a qemu target and did not run into any problems - it cloned the various submodule repositories as expected and the build worked fine.
About the solution: I think the best would be to use ifdef guards in the C code (both for coreboot and cbfstools), that's what the precompiler is for, after all. There's already a CONFIG_VBOOT_LIB config option, so why isn't it used? I see no reasonable excuse for that. I also think that "default n" should be added to https://github.com/coreboot/coreboot/blob/master/src/security/vboot/Kconfig
However if Kconfig isn't wanted for any reason, it's pretty simple to add "ifneq ($(wildcard ../3rdparty/vboot/somefile*),)" to the Makefile. This way if the vboot submodule is cloned, then coreboot and cbfstool would be automatically compiled with support for it (without a Kconfig option). But for people who just clone the base repo, there would be no compilation errors. Everybody happy, problem solved.
Sort of, yes. As Julius mentioned this is possible but it's a fair bit of work with little benefit. The common code which uses vboot has to do with cbfs hashing. I personally think of it as a good feature, though I can see arguments for not wanting it as well.
The submodule should be downloaded automatically and does not have a restrictive license, unlike some other submodules that the user must opt-in to. Is there a desire to remove hashing functionality in cbfs, or is the problem here just the fact that the hashing library is part of a submodule?