Remove Commit Signing about comboami

[mlococo]

In addition to hardcoding a shared-key for official-committers, add a run-time flag so that people who fork the ami can sign their own commits or disable commit-signing.

@elad You've expressed interest in hacking the community part of this feature (I'll add in the new committer key after I merge your changes), and it's one that should go in prior to the next rebake. I'm excited to merge it if you have time to put the code-changes together. Also for the record, I will merge either an option to disable commit-signing (which I think will be sufficient for 99% of AMI users) or an option to specify a custom commit-signing key.

If you want to have any design discussions we can do so here, but feel free to just start hacking as I'm sure you'll come up with something nice.

[elad]

Working on it. :) Submitted #75 with the option to disable commit signature verification. I'll work on the other part (allowed keys) tomorrow morning.

[mlococo]

After much discussion in #75, I've decided to remove commit-signing entirely. It was implemented in response to #33 but has the following issues that mean it does more harm than good:

• From the time it was implemented until today, it was trivially bypassable (using a crafted commit-message) and so completely ineffective.
• The signature-bypass bug occurred because Python (and it's library ecosystem) offers no native facilities to perform sig-checks on git-repos, so we're forced to parsed the command-line output of git. This is a recipe for bugs of this kind, and we're not in a position to invest in something more robust. When it comes to security features, not doing them at all is better than doing them badly.
• Most of the benefit of commit-signing is provided by specifying a commit-hash to --repository or --forcecommit. Git commit hashes are already strong checksums, they are already delivered over https from github, the only piece missing is a signing key separate from the repository... which is admittedly helpful but not a guarantee that malicious code can't be shipped.
• The overhead of maintaining this poor quality commit-signing setup is out of alignment with the rest of the security infrastructure surrounding ComboAMI. ComboAMI stands up clusters with authentication disabled!!!

While we should always strive to improve the security of ComboAMI, over-investing in features that don't work or provide little benefit has the opposite effect. It's time for commit-signing to go.

[elad]

@mlococo this should probably be closed as well no?

[mlococo]

Yeah, my attention has been focused elsewhere this week. Closing.

Thanks again for your help on these features. Your PR's will always be welcome here.

[elad]

No problem, and you're welcome! Thank you and @joaquincasares for being so helpful. :)

[joaquincasares]

Sure thing! :)

[mlococo]

Re-opening this. We can't actually ship it until the rebake because ds0_updater.py doesn't restart itself after pulling the new code, so ds0_updater.py can't only be updated during a rebake.

The result is that unrebaked AMI's are still giving commit-signing errors.

[mlococo]

Tested and working in dev-2.6