On Wed, May 27, 2015 at 12:20:03PM +0100, Rebecca N. Palmer wrote: > >Why? Which attack do you envision[...]that would > >be thwarted by https but not by signed commits? > I don't; I see https as easier and hence more likely to actually get used in > practice.
Well, on that we disagree then, I suppose. Sure, https is easy to set up. But setting it up *right*? Not so much. - You need to get a certificate, which costs money. - You need to ensure that the certificate is replaced every so often (preferably before its expiration date), which requires procedures to be set up - Most importantly, you need to configure your webserver and SSL library so it disables outdated protocol versions, enables newer secure protocol versions (doing so in a way that older proprietary clients who don't speak those newer versions yet and make up the majority of your target audience aren't excluded), and a whole bunch of other things. Especially the latter is a bit of a black art, that can't really be taught and that you can only learn by doing, and failing a bunch of times. The ssllabs website can help you a bit, mostly by telling you when you're doing it wrong, but it doesn't give you the whole story. In contrast, gpg just requires you to generate a key, and configure git to use it. That's it. Yes, preferably you'd get that key signed by someone else so you're part of the web of trust, but that isn't a prerequisite (that is, you can start signing today, and worry about getting your key added to the WoT later). Explaining how to do that can be done in a fairly short web page. How is any of that harder than the SSL stuff? -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26
signature.asc
Description: Digital signature
