Re: git and https
On Wed, May 27, 2015 at 10:08:35AM +0200, Wouter Verhelst wrote:
> On Mon, May 25, 2015 at 11:38:06AM -0700, Josh Triplett wrote:
> > > While we're on the subject of git security...should we stop
> > > recommending that non-account-holders use git:// (most efficient, but
> > > insecure against MITM unless you manually check the commit number) in
> > > preference to https:// (at least some security)?
> > > https://wiki.debian.org/Alioth/Git#Accessing_repositories
> >
> > https:// is actually just as efficient as git:// these days (other than the
> > minor overhead of TLS, which is worth it for security).
>
> Why? Which attack do you envision (other than the ridiculous "the NSA would see
> that we're pushing!", which they can by just doing a git clone too) that would
> be thwarted by https but not by signed commits?
My comment was regarding https:// versus git:// , not https:// versus
"git:// plus signed commits". Most repositories do not use signed
commits. And even for those that do, how many people cloning the
repository actually check the key used for the signatures?
https:// avoids MITM; with git://, it'd be quite possible to MITM a git
clone and feed out subtly altered code (for instance, burying a rootkit
installer in the build system scripting). And when you consider that
many people will pull but never push, and no *automatic* process checks
the identity of the key used to sign commits/tags, such alteration might
not be noticed very quickly, especially for repositories where the
developers (who do push) use ssh.
Beyond that, https:// also supports secure authentication, and https://
hides *which* repository and objects are being accessed (particularly
useful for large git hosting sites).
I hope to one day see a complete absence of unencrypted traffic.
- Josh Triplett
Reply to: