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.
next prev parent 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).