From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konstantin Kliakhandler Subject: Re: Why no secure code retrieval Date: Mon, 4 Jul 2016 01:36:59 +0300 Message-ID: References: <87mvm4sewl.fsf@systemreboot.net> <87y45m28vp.fsf@saiph.selenimh> <87lh1k5dj1.fsf@free.fr> <20160702165130.GA1401@scamper2.bantercat.co.uk> <87eg7bnqob.fsf@free.fr> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113f9726c30a0a0536c2dcb9 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:40873) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bJq0x-0002eg-B9 for emacs-orgmode@gnu.org; Sun, 03 Jul 2016 18:37:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bJq0u-0007BY-OE for emacs-orgmode@gnu.org; Sun, 03 Jul 2016 18:37:22 -0400 Received: from mail-io0-x230.google.com ([2607:f8b0:4001:c06::230]:36670) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bJq0u-0007BC-Gs for emacs-orgmode@gnu.org; Sun, 03 Jul 2016 18:37:20 -0400 Received: by mail-io0-x230.google.com with SMTP id s63so139753960ioi.3 for ; Sun, 03 Jul 2016 15:37:19 -0700 (PDT) In-Reply-To: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: Robert Horn Cc: Arun Isaac , Bastien , Stromeko@nexgo.de, emacs-orgmode@gnu.org, Nicolas Goaziou , Ian Barton --001a113f9726c30a0a0536c2dcb9 Content-Type: text/plain; charset=UTF-8 Hello, On 3 July 2016 at 23:12, Robert Horn wrote: > > The SHA1's are reference elements used throughout git, and are primarily > for integrity protection against accidents, not against attackers. Hence > it's sufficient that > they be maintained by the git processes. > Sufficient for what? I believe we were discussing security (that was my intention at least, and so did your previous email seem to indicate). And if this is the case, you have just contradicted yourself. I apologize for pointing it out so directly, and also if I misunderstood you. > The plain vanilla git process does not include distribution of SHA1 > values by an independent path, so it's not easy to verify against a > trusted source for the correct values. > Which trusted source? This is the whole point of said discussion. If I haven't a secure connection to the server and none of the commits are signed, what exactly are you proposing to compare to? My proposal was comparison to the gpg signatures in git itself, at least for tagged revisions. This would provide a canonical source to compare to, and can be done automatically by git itself (the comparison). I certainly can live off just tagged versions. Even when you want to fix a bug/add a feature, most likely you need to just work against files that haven't changed since last tag. With your permission I'll quote the entire message of Achim Gratz: > > Getting the same data via https doesn't give you that sort of guarantee > > either, it only ensures that the data cannot be read and altered in > > transport. If the server or repo gets compromised, then it is game over > > until someone notices that the server suddenly doesn't match up the > local clone. No, it does not give me a guarantee. But very few things do. Signatures come closer to that, although https://xkcd.com/538/ should convince you that it isn't a guarantee either. But who said that there will ever be a point when the server doesn't match the local clone? https://mikegerwitz.com/papers/git-horror-story But just because there are other ways to enter your house does not mean you should not put a lock on your front door. This would be a reasonable step for org-mode releases. The release > process only involves a few people, and key management would not be too > hard. It doesn't solve the problem for non-git distribution methods. > My guess is that the ELPA users are the most exposed. Fixing that > really belongs to ELPA, but if I were putting together the cyber > security plan for org-mode I would call out this gap and make clear that > it is a gap that can't be easily solved by org-mode. (Maybe tweaking > someone more familier with ELPA to tell me how to solve it for ELPA.) > I believe that these days elpa is accessed by default via https and that archives are signed, though please correct me here. Assuming it is the case, there isn't much one can do beyond the currently suggested steps, I think. Have a nice week, Kosta --001a113f9726c30a0a0536c2dcb9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

On 3 July 2016 at 23:12, Robert Horn= <rjhorn@alum.mit.edu> wrote:

The SHA1's are reference=C2=A0elements used through= out git, and are primarily for integrity protection=C2=A0against accidents,= not against attackers.=C2=A0 Hence it's sufficient that
they be maintained by the git processes.

Sufficient for what? I believe we were discussing security (that was my i= ntention at least, and so did your previous email seem to indicate). And if= this is the case, you have just contradicted yourself. I apologize for poi= nting it out so directly, and also if I misunderstood you.
=C2=A0=
The plain vanilla git process does not include distribution of SHA1
values by an independent path, so it's not easy to verify against a
trusted source for the correct values.

= Which trusted source? This is the whole point of said discussion. If I have= n't a secure connection to the server and none of the commits are signe= d, what exactly are you proposing to compare to? My proposal was comparison= to the gpg signatures in git itself, at least for tagged revisions. This w= ould provide a canonical source to compare to, and can be done automaticall= y by git itself (the comparison).

I certainly can = live off just tagged versions. Even when you want to fix a bug/add a featur= e, most likely you need to just work against files that haven't changed= since last tag.
=C2=A0
With your permission I'= ll quote the entire message of Achim Gratz:
=C2=A0
> Getting the same data via https doesn't give you that sort= of guarantee
> either, it only ensures that the data cannot be read = and altered in
> transport. If the server or repo gets compromised, t= hen it is game over
> until someone notices that the server suddenly = doesn't match up the local clone.=C2=A0

No,= it does not give me a guarantee. But very few things do. Signatures come c= loser to that, although https://xkcd.com/= 538/ should convince you that it isn't a guarantee either. But who = said that there will ever be a point when the server doesn't match the = local clone?=C2=A0https://mikegerwitz.com/papers/git-horror-story

=
But just because there are other ways to enter your house does not mea= n you should not put a lock on your front door.

This would be a reasonable step for org-mode releases.=C2=A0 The = release
process only involves a few people, and key management would not be too
hard.=C2=A0 It doesn't solve the problem for non-git distribution metho= ds.
My guess is that the ELPA users are the most exposed.=C2=A0 Fixing that
really belongs to ELPA, but if I were putting together the cyber
security plan for org-mode I would call out this gap and make clear that it is a gap that can't be easily solved by org-mode.=C2=A0 (Maybe tweak= ing
someone more familier with ELPA to tell me how to solve it for ELPA.)

I believe that these days elpa is accessed b= y default via https and that archives are signed, though please correct me = here. Assuming it is the case, there isn't much one can do beyond the c= urrently suggested steps, I think.

Have a nice wee= k,
Kosta
=C2=A0=C2=A0
--001a113f9726c30a0a0536c2dcb9--