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" <rjh...@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 > rjh...@alum.mit.edu >
