Re: Why no secure code retrieval

[Robert Horn <rjhorn@alum.mit.edu>]

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