Killing plaintext git:// in favor of https:// cloning

Eric Wong normalperson at
Tue Feb 23 07:21:22 CET 2016

"Jason A. Donenfeld" <Jason at> wrote:
> On Tue, Feb 23, 2016 at 2:19 AM, Eric Wong <normalperson at> wrote:
> > git already has plenty of integrity checking built-in and
> > getting the proper hashes for the heads/tags over a
> > trusted-enough medium is enough (or reading the fine code).
> No, git's built-in integrity protection really is not sufficient if
> the transport is compromised.

git commits, tags, and request-pull-formatted emails (with
unabbreviated commit IDs) may all be signed with GPG.

Once those are verified, "git fsck" results can be trusted.

> > And as others have said, HTTPS isn't impenetrable
> I'd like some specific details on this repeated claim.

The known problem would be CAs being compromised.
I've also heard of MITM stripping proxies; but don't know
much about them.

> > the CA system is still a major problem.
> True. But there doesn't appear to be a widely deployed alternative.

GPG-signed tags/commits/emails.  Probably not as widely deployed
as TLS CAs, but probably sufficient in Free Software circles.

> > Also, TLS libraries can introduce new bugs and vulnerabilities
> > like Heartbleed.
> This is true, but I already require a public TLS deployment, so it's
> there regardless.

Vulnerabilities may affect clients, too (for example, the recent
OpenSSH roaming vulnerability).  IMHO, users should be given a
choice of which poison to pick.

Disclaimer: Personally, I don't GPG sign anything, myself,
either.  For selfish reasons, I do not want people to trust me
or my signature and would prefer they read and scrutinize
what little I write.  And we can't rule out undiscovered
vulnerabilties affecting GPG, either.

More information about the CGit mailing list