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 09:15:57 +0300 [thread overview]
Message-ID: <CAH+LVpnkJEVHXYdmg1odo4jnw3-_8rQPe1VOUOa-hLrULx+=RA@mail.gmail.com> (raw)
In-Reply-To: <m3k2h2l0ja.fsf@alum.mit.edu>
[-- Attachment #1: Type: text/plain, Size: 4098 bytes --]
Thanks for the clarification and the detailed analysis. Sounds like you did
you homework - I have a lot lo learn. Anyway, I would say that we agree on
most points, and I'm more than content to leave it at that :-).
Best Regards,
Kosta
--
)°))°((°(
Konstantin Kliakhandler
Sent on the go.
On Jul 4, 2016 03:17, "Robert Horn" <rjhorn@alum.mit.edu> wrote:
>
> Konstantin Kliakhandler writes:
>
> >
> > 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.
>
> Sufficient for current risk mitigation in my opinion. You disagree.
>
> We both agree that signed tags would be better.
>
> Choices are based on an evaluation of risks, threats, and mitigation
> costs. Emacs has had very few security vulnerabilities
> discovered. There are only 18 CVE since 2000. None of these allowed
> priviledge escalation, and the two most severe required local user
> assistance. So org-mode is not in a high risk location.
>
> That means that I look for very low cost steps, i.e., very simple easy
> changes. Signing tags falls into that category because it only affects
> a few people and is not particularly difficult to manage for very small
> groups.
>
> Another step that I would take is to establish and publish the planned
> security processes. These should be established and understood well
> before any event takes place. Taking adhoc reactive steps in an
> emergency often causes more problems.
>
> > 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.
> >
>
> I took a quick look inside package.el and it is still incomplete. It's
> also got a big todo list, so I expect this to change with subsequent
> releases. As of Emacs 24.3 ELPA did not have package signatures. Emacs
> 24.5 has package signatures, but no way for the user to verify that what
> is installed matches the signature.
>
> As of 24.5, the default behavior in package.el is:
> - package signatures are optional
> - package signatures are only checked to confirm that the tar file that
> is downloaded matches the signature. There is no tooling for subsequent
> verifications.
> - invalid signatures are ignored by default
> - missing signatures are ignored by default
> - package.el has dependencies on programs external to emacs. If these
> dependencies are not met, it reverts to default behavior.
>
> This is clearly better than 24.3.
>
> Again, in terms of risk/cost/mitigation evaluation I would have the tool
> that creates the ELPA package for org-mode also create a signature. It
> might do that already. Package.el does not indicate which packages are
> signed. I would let the folks taking care of ELPA deal with the rest in
> later releases.
>
> Use of https for most ELPA repositories does protect against in transit
> content corruption, but not necessarily much else. Looking at
> elpa.gnu.org I notice:
> - Their certificate expired today and has not been updated, oops
> - They use Let's Encrypt as signing authority. This means that the
> certificate verifies that whoever responds to the domain name http port
> controls the TLS certificate and web content. That's enough for
> many purposes, but it doesn't mean much in terms of server security.
>
> In transit MITM is a minor threat for software distribution. I've only
> detected MITM activity in public locations once in the real world. (I
> was thrilled. It's a really rare event.) It was in a very high threat
> location (Washington DC area, a public wifi).
>
> The big MITM threat is the dangers from malicious javascript insertion
> into unprotected browser activity.
>
> R Horn
> rjhorn@alum.mit.edu
>
[-- Attachment #2: Type: text/html, Size: 4763 bytes --]
prev parent reply other threads:[~2016-07-04 6:16 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
2016-07-04 0:17 ` Robert Horn
2016-07-04 6:15 ` Konstantin Kliakhandler [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: 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+LVpnkJEVHXYdmg1odo4jnw3-_8rQPe1VOUOa-hLrULx+=RA@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).