On Mon, May 25, 2015, at 09:09, Rebecca N. Palmer 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
When you are in a position to actually mandate the full certificate validation (i.e. enforce pin and validation on the client, and control the server certificate), you would get one security benefit out of HTTPS/TLS for git transport: * Data must be modified at rest at either endpoint, it cannot be corrupted while in transit. You cannot even get that much benefit out of the typical web browser https/TLS use, because either the user will just say "yes" to the security exception dialog, or because it is not too difficult to get a fraudulent certificate that can be used for MITM from a shady or otherwise crappy/compromised CA that could be anywhere in the world, etc. git as a https client is not really different from the typical web https/TLS use, except that it doesn't give you a dialog to shoot yourself in the foot and say "ignore security exception" -- instead it gives you command line parameters or environment variables to do so. However, it will still trust all "system CAs" equally, etc. unless specifically configured to do something else. You must always keep in mind that https and TLS _cannot_ protect you against data tampering on the repositories themselves. For this, you need signed tags and signed commits, which will protect the data at rest (i.e. stored on both the remote and the local repositories). Once you have that, it doesn't matter that much if you use the git protocol or http, or https as far as security goes, as you can (and should) verify the result of the transfer instead. > Any suggestions for persuading upstreams to care about these issues? If upstream signs tags and commits (i.e. if every branch always have a signed tag or signed commit as the tip), I'd recommend that you don't pester them about https. Chances are they know what they're doing. If upstream won't even sign release tags, try to talk to them about the several instances of data tampering that several projects have been through, and the need to have signatures on code repositories. Pointing them to http://mikegerwitz.com/papers/git-horror-story might, or might not help. That text goes a bit overboard (on purpose), so it might come across as needless paranoia to many... especially to anyone that cannot even be bothered to sign tags in the first place :-) But pestering upstream about https for git clone/fetch ? That's knocking on the wrong door. > Mine has no https on the repository (though they do on the release > tarballs), no signed anything, and have not responded to me pointing out > that this is a security hole: > https://bugs.freedesktop.org/show_bug.cgi?id=89682 https for git access is not what you should be asking out of freedesktop.org, IMO. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique de Moraes Holschuh <h...@debian.org> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1432573901.624401.277617881.5b46d...@webmail.messagingengine.com
