From: Konstantin Kliakhandler <kosta@slumpy.org>
To: Robert Horn <rjhorn@alum.mit.edu>
Cc: Arun Isaac <arunisaac@systemreboot.net>, Bastien <bzg@gnu.org>,
Stromeko@nexgo.de, emacs-orgmode@gnu.org,
Nicolas Goaziou <mail@nicolasgoaziou.fr>,
Ian Barton <lists@wilkesley.net>
Subject: Re: Why no secure code retrieval
Date: Mon, 4 Jul 2016 01:36:59 +0300 [thread overview]
Message-ID: <CAH+LVpkRMLvzGbyK1wZ7sdKWNwSeyX0rDmuj+2HDg7ONLvBpdg@mail.gmail.com> (raw)
In-Reply-To: <m3bn2ev5tu.fsf@alum.mit.edu>
[-- Attachment #1: Type: text/plain, Size: 2993 bytes --]
Hello,
On 3 July 2016 at 23:12, Robert Horn <rjhorn@alum.mit.edu> 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
[-- Attachment #2: Type: text/html, Size: 4447 bytes --]
next prev parent reply other threads:[~2016-07-03 22:37 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-28 12:10 Why no secure code retrieval Konstantin Kliakhandler
2016-06-29 6:11 ` Arun Isaac
2016-06-30 11:50 ` Nicolas Goaziou
2016-07-02 14:18 ` Bastien Guerry
2016-07-02 16:51 ` Ian Barton
2016-07-03 7:09 ` Bastien Guerry
2016-07-03 15:11 ` Robert Klein
2016-07-03 15:20 ` Achim Gratz
2016-07-03 16:57 ` Robert Horn
2016-07-03 18:18 ` Konstantin Kliakhandler
2016-07-03 18:25 ` Achim Gratz
2016-07-03 20:12 ` Robert Horn
2016-07-03 22:36 ` Konstantin Kliakhandler [this message]
2016-07-04 0:17 ` Robert Horn
2016-07-04 6:15 ` Konstantin Kliakhandler
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: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAH+LVpkRMLvzGbyK1wZ7sdKWNwSeyX0rDmuj+2HDg7ONLvBpdg@mail.gmail.com \
--to=kosta@slumpy.org \
--cc=Stromeko@nexgo.de \
--cc=arunisaac@systemreboot.net \
--cc=bzg@gnu.org \
--cc=emacs-orgmode@gnu.org \
--cc=lists@wilkesley.net \
--cc=mail@nicolasgoaziou.fr \
--cc=rjhorn@alum.mit.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://git.savannah.gnu.org/cgit/emacs/org-mode.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).