> 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?