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
>