The sync-git-verify-commit-signature option currently defaults to false. This means that a user can easily fall into the trap of configuring a git-based sync of ::gentoo that does not verify the commit. Simply by not explicitly specifying "sync-git-verify-commit-signature = true". I think it would be sensible to add a third configuration value for the sync-git-verify-commit-signature option named 'if-signed', and have the option default to 'if-signed'. This way, a user configuring a git-based sync for a repository with signed commits will become immediately aware if the commit could not be verified. The user has then the option to either configure appropriate trusted keys for the repository or to disable commit verification. But the user will not, probably unintentionally, sync from a remote without commit verification. Which is the threat of the current behavior.
A malicious remote could just strip the signatures though? It's the same issue with relying on opportunistic HTTPS. >This way, a user configuring a git-based sync for a repository with signed commits will become immediately aware if the commit could not be verified. I don't see how this follows, given the above. What am I missing?
I guess you mean it'd try and fail to verify for a non-malicious repo and then they'd be forced to set keys and switch to yes or disable explicitly.
I just realized that a 'if-signed' option requires a "pinning behavior". That is, if 'if-signed' is enabled, then, on the initial clone the head commit should be checked for a commit signature. And if there is one, this should be remembered and signed commits should be required for all subsequent clones/updates. But this still leaves a short window for an attacker open. Maybe this bug is really about defaulting sync-git-verify-commit-signature to true, or to hardcode a list of git repo URLs where we expect that the HEADs of the sync branch are always pointing to signed commits (an option I personally do not really like). In any case, defaulting sync-git-verify-commit-signature to 'false' is insecure and probably the worst of the available options.
(In reply to Sam James from comment #2) > I guess you mean it'd try and fail to verify for a non-malicious repo and > then they'd be forced to set keys and switch to yes or disable explicitly. Correct. And what you pointed out is also right. Something like 'is-signed' only makes sense if you only inspect the commit after the initial clone, and then require that all subsequent commits will have signed commits if the initial clone's commit had one. Another option, that occurred to me, would potentially be to set the value of sync-git-verify-commit-signature depending on the name of the repository: if it is 'gentoo' then default to 'true'.
How is this supposed to interact with overlays? If it's on by default for those then a bunch of them will immediately break due to using signed commits and Gentoo not providing a good way to distribute those keys.
(In reply to Enne Eziarc from comment #5) > How is this supposed to interact with overlays? If it's on by default for > those then a bunch of them will immediately break due to using signed > commits and Gentoo not providing a good way to distribute those keys. That question is covered above, the opportunistic aspect. There's no plan for distributing those keys but there's also obviously no plan to then break overlays by requiring it. (I think we discussed it more on IRC at the time too, you need some HSTS style pinning really and maybe an initial list.)
