List for cgit developers and users
 help / color / mirror / Atom feed
From: normalperson at yhbt.net (Eric Wong)
Subject: Killing plaintext git:// in favor of https:// cloning
Date: Tue, 23 Feb 2016 06:21:22 +0000	[thread overview]
Message-ID: <20160223062122.GA4438@dcvr.yhbt.net> (raw)
In-Reply-To: <CAHmME9oJ5wnd2y5smLe0MF16Ao9TB8VNTX__sHOvPK5qYPCMRA@mail.gmail.com>

"Jason A. Donenfeld" <Jason at zx2c4.com> wrote:
> On Tue, Feb 23, 2016 at 2:19 AM, Eric Wong <normalperson at yhbt.net> 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.


  reply	other threads:[~2016-02-23  6:21 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-22 18:16 Jason
2016-02-22 18:22 ` Jason
2016-02-22 19:18 ` mailings
2016-02-22 19:56   ` Jason
2016-02-23  1:19 ` normalperson
2016-02-23  1:28   ` Jason
2016-02-23  5:08   ` Jason
2016-02-23  6:21     ` normalperson [this message]
     [not found]     ` <CANyOob14C3cZuwkQBpEv=Tr==KY=oULyUg7NX3B6vb8mfRkgDg@mail.gmail.com>
2016-02-23 14:03       ` [pass] " Jason
     [not found]         ` <CANyOob1KEfFd5-e5e9ETauvmakEiK7pU5083-7t8CzTW5-QrKQ@mail.gmail.com>
2016-02-23 14:34           ` Jason
2016-02-24 19:00 ` hacking
2016-02-25 17:21 ` Jason
2016-02-22 19:50 jea-signup-cgit
2016-02-22 19:57 ` webmaster
2016-02-23  5:02   ` Jason
2016-02-22 19:59 ` mailings
2016-02-22 20:43 jea-signup-cgit
2016-02-23  5:05 ` Jason

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160223062122.GA4438@dcvr.yhbt.net \
    --to=cgit@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).