git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: David Lang <david@lang.hm>
To: Santiago Torres <santiago@nyu.edu>
Cc: Jeff King <peff@peff.net>, Git <git@vger.kernel.org>
Subject: Re: [OT] USENIX paper on Git
Date: Wed, 3 Aug 2016 13:03:00 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.02.1608031259500.16896@nftneq.ynat.uz> (raw)
In-Reply-To: <20160803174459.knlmyx6txmggixzi@LykOS.localdomain>

On Wed, 3 Aug 2016, Santiago Torres wrote:

>> So if you want to treat Git as a cryptographic end-to-end distribution
>> mechanism, then no, it fails horribly at that. But the state of the art
>> in source code distribution, no matter which system you use, is much
>> less advanced than that. People download tarballs, even ones with GPG
>> signatures, all the time without verifying their contents. Most packages
>> distribute a sha1sum or similar (sometimes even gpg-signed), but quite
>> often the source of authority is questionable.
>
> Yes, this happens an awful lot of times. We did some work with python's
> pypi last year, and we found out that less than 1% of people actually
> downloaded the gpg signature for the package they are retrieving[1].
>
>>
>> For example, consider somebody downloading a new package for the first
>> time. They don't know the author in any out-of-band way, so any
>> signatures are likely meaningless. They _might_ be depending on the
>> source domain for some security (and using some hierarchical PKI like
>> TLS+x.509 to be sure they're talking to that domain), but in your threat
>> model, even well-known hosts like FSF could be compromised internally.
>>
>> So yes, I think the current state of affairs (especially open-source) is
>> that people download and run possibly-compromised code all the time. But
>> I'm not sure that lack of tool support is really the limiting factor. Or
>> that it has turned out to be all that big a problem in practice.
>
> I couldn't agree more. I feel that OSS is slowly moving towards a more
> cryptographically robust, trust-based way of doing things, which I find
> pleasing.

It's too easy to look at this from purely a technical, cryptographic point of 
view and miss a very important point.

It may be very easy to see that this was signed by "cool-internet-name" but how 
can I tell if this is really Joe Blow the developer? and if it is, I still have 
no way of knowing if he's working for the NSA or not.

The lack of meaningful termination of the signatures to the real world is why so 
few people bother to check package signatures, etc.

David Lang

      parent reply	other threads:[~2016-08-03 20:03 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20160801224043.4qmf56pmv27riq4i@LykOS.localdomain>
2016-08-03 14:58 ` [OT] USENIX paper on Git Santiago Torres
2016-08-03 15:22   ` Johannes Schindelin
2016-08-03 15:25     ` Santiago Torres
2016-08-03 17:14       ` Stefan Beller
2016-08-03 17:22         ` Santiago Torres
2016-08-03 17:35           ` Stefan Beller
2016-08-03 18:02             ` Santiago Torres
2016-08-03 17:35           ` Junio C Hamano
2016-08-03 17:58             ` Santiago Torres
2016-08-03 17:11   ` Jeff King
2016-08-03 17:18     ` Junio C Hamano
2016-08-03 17:45     ` Santiago Torres
2016-08-03 17:58       ` Jeff King
2016-08-03 18:31         ` Santiago Torres
2016-08-03 20:03       ` David Lang [this message]

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=alpine.DEB.2.02.1608031259500.16896@nftneq.ynat.uz \
    --to=david@lang.hm \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    --cc=santiago@nyu.edu \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).