Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Emacs and TLS

lwn.net

Post reply on HN
Print view View original

71–80 of 83 posts

Re: Emacs and TLS

#71

Post by jancsika »

wyuenho wrote: post #15
jancsika wrote: post #14

> It isn't the Emacs way to second-guess our users' needs, definitely not to decide for them what is and what isn't a matter of life and death for them. We provide options with some reasonable defaults, and then let users make informed decisions which defaults are not good enough for them. > It is IMO unreasonable to make our defaults match what happens in dictatorships that you describe, because that would unnecessa…

LOL, if only. It'll certainly save me a lot of work. //edit BTW, those aren't my words, those are Eli's responding to Perry

It is funny, but I didn't mean it as a joke.

It should generally be possible to predict the range of responses when submitting a patch to a free software project, or when posting to a free software list. If the input is "TLS" and the output is "TSA," it puts a strain on everyone and free software development suffers as a result.

Re: Emacs and TLS

#72

Post by wyuenho »

vemv wrote: post #70
wyuenho wrote: post #51

Earlier quoted context omitted.

What about emacs -q ? Does the same issue still happen? If it doesn't, that sounds like a different package is locking up your emacs.

Finally identified the issue - I was adding Marmalade as a repo, which cert is legitimately wrong (Chrome will warn over https://marmalade-repo.org/ ). I just removed the repo - I'd say that Melpa won in recent years?

Oh it's won many years ago :)

Re: Emacs and TLS

#73

Post by __david__ »

oblio wrote: post #39
__david__ wrote: post #30

Earlier quoted context omitted.

Emacs uses TLS for more than just HTTP. SMTP+STARTLS for instance…

You were saying: https://stackoverflow.com/questions/14722556/using-curl-to-s... ? :D

Fair enough, but does it do nntp, irc, pop, imap, jabber, etc? Emacs (for better or worse) has a complete network API so people can implement all of these things, and it doesn't want to be limited by a high-level library that only supports some small subset (however large that subset is).

Re: Emacs and TLS

#74

Post by oblio »

__david__ wrote: post #73
oblio wrote: post #39

Earlier quoted context omitted.

You were saying: https://stackoverflow.com/questions/14722556/using-curl-to-s... ? :D

Fair enough, but does it do nntp, irc, pop, imap, jabber, etc? Emacs (for better or worse) has a complete network API so people can implement all of these things, and it doesn't want to be limited by a high-level library that only supports some small subset (however large that subset is).

If you push hard enough...: https://curl.haxx.se/mail/lib-2012-02/0234.html :)

Re: Emacs and TLS

#75

Post by pecg »

I know that from a technical point of view, Emacs is not just a text editor; I think it is a complete lisp virtual machine with a text-based interface that happens to be prepared for editing text by default, and thus it should be treated as such, instead of running it over as a userland program maybe one day it works as a standalone operating system, with its own kernel and JIT compiled lisp dialect. I'm saying this, because when I first started using Unix-like operating systems Emacs was one of the things that attracted me the most, but after actively using it for almost a year I saw how it moved away from the expected operation mode of a typical Unix environment, and I didn't like that. I came to appreciate the phylosophy of "One program to do one thing and do it well... make programs that work together", I consider it an elegant way to design and implement software, thus I don't see where Emacs fits on a Unix-like system. In the end, I ditched it in favor of something much more simple, fast and adecuate, this is where vis does an outstanding job, having the unique plus of using a structural regular expressions engine, and extensible using Lua. vis is small (source code and binary) and I don't have to think about what SSL implementation it should use, because there is a system library that does it for me, since vis is just a text editor, and succeeds at it.

Re: Emacs and TLS

#76

Post by dreamcompiler »

I haven't been able to load a Melpa library with https for many months. I had assumed it was just because MacOS is weird about TLS since it doesn't use OpenSSL (getting freaking curl to work for https in MacOS sometimes takes hours of futzing around with libraries).

But maybe it's Emacs' fault?

Re: Emacs and TLS

#77

Post by wyuenho »

sillysaurus3 wrote: post #68
wyuenho wrote: post #27

Earlier quoted context omitted.

I'm not trying to win anything, I'm trying to find out where that dismissive tone came from, and see if there's any merit. Back to topic: While I agree that being vulnerable is not the same as being attacked, I still have a hard time understanding why you seem to be downplaying the significance. First of all, I don't have to prove anything, all the papers that describe actual explotable TLS vulns over HTTP and SMTP/I…

First of all, I don't have to prove anything Yes, you do. That's pentesting 101. Think of it this way. Would it be reasonable for pentesters to say "You're critically vulnerable. But I haven't verified this"? More times than I can count, when I went back to verify whether I was correct, I wasn't. For subtle reasons. If you haven't put in the work, you don't know whether you are right. Security, most of the time is ab…

You seem to be singularly focused on pentesting, whatever that means to you, and I'm mostly concerned with leakage of information. Being able to prove whether I can pwn Emacs or not is irrelevent. For my purpose, all I have to establish is if Emacs is treated as a TLS client on internet. This is trivial.

> You have never worked in security. The fact that you're shocked at this shows how green you are. I don't mean that in a dismissive or insulting way, but if you'd just go do a stint as a pentester for a year, or talk to some pentesters in the field, you'll quickly stop being shocked at this.

Does the fact that you are numbed to snafus like this justify the terrible state of network security of a continuously maintained 30+ year old editor? I expected more from the countless number of Emacs hackers came before me.

I urge to you go thru the mailing list thread, but if you don't want to, I understand as it's rather long, but please don't assume you know what I've done or haven't done or how much I understand these issues, or my intentions. We've never met, never conversed before, you don't know anything about me.

Re: Emacs and TLS

#78

Post by wahern »

tialaramex wrote: post #64
simias wrote: post #35

Earlier quoted context omitted.

>Do you ever install packages from Emacs? If so, you definitely want that to be at least TLS protected. Wouldn't it make more sense to sign individual packages so that it doesn't matter if an attacker can mess with them "in flight"? That's generally how package managers work in my experience. It also means that you can let third parties create mirrors without trusting them fully. TLS doesn't really seem like the righ…

This feels like enough, doesn't it? But it's not. You will also need to sign and timestamp all repository metadata. Otherwise when you learn of bug X and fix it with patch P to produce new package package-V+1 I also learn of bug X, but I ensure my victims don't get told about new package-V+1, they will be told package-V is the latest version and they're now safely up-to-date - but I can exploit them. If you use TLS I…

They should be doing all of that anyhow. Servers get hacked. TLS doesn't fix the metadata replay problem.

Re: Emacs and TLS

#79

Post by wyuenho »

ekidd wrote: post #58
wyuenho wrote: post #44

Earlier quoted context omitted.

A number of people on emacs-devel, and IIRC, RMS too, suggests that we should not be over-protective parents of Emacs users, and on most levels, I agree. While this might seem like a strange philosophical position to take when it comes to security, I don't think it is (or will be) the case for Emacs. An Emacs user can override pretty much everything Emacs does, and there are well-defined options where you can force a…

> A number of people on emacs-devel, and IIRC, RMS too, suggests that we should not be over-protective parents of Emacs users, and on most levels, I agree. While this might seem like a strange philosophical position to take when it comes to security, I don't think it is (or will be) the case for Emacs. I've been a heavy Emacs user since 1997, using it as my primary editor on all platforms. (In the last year or so, I'…

I love Emacs, but if I'm to be honest, if network security is of concern per a company's policy, Emacs, any version of it past and present, should be immediately banned.

Re: Emacs and TLS

#80

Post by lispm »

pecg wrote: post #75

I know that from a technical point of view, Emacs is not just a text editor; I think it is a complete lisp virtual machine with a text-based interface that happens to be prepared for editing text by default, and thus it should be treated as such, instead of running it over as a userland program maybe one day it works as a standalone operating system, with its own kernel and JIT compiled lisp dialect. I'm saying this,…

Emacs is a wide family of text editors. GNU Emacs is just one. Originally Emacs was implemented as a set of TECO macros. The second Emacs was then EINE (Eine is not Emacs). EINE was implemented in Lisp Machine Lisp on top of the Lisp Machine OS. One of the next Emacs editors was Multics Emacs, an Emacs implemented in Maclisp for the Multics mainframe computer. Both Maclisp and Lisp Machine Lisp were full-featured Lisp implementations and thus their Emacs was a Lisp-only implementation. From then on zillions of Emacs variants were implemented. This provides a list of Emacs implementations: http://www.finseth.com/emacs.html

GNU Emacs was developed as a text editor. Its implementation language are C and Elisp - not only the VM is coded in C, but there are other parts written in C. See for example: https://github.com/emacs-mirror/emacs/blob/master/src/frame....

Then Elisp is the extension language for writing extensions (like minor or major modes) and applications using a text-editor user interface. These applications are using the programmable editor buffer as their user interface building block.

General enhanced Lisp implementations which run as a standalone operating system, but which are not special purpose for editor implementation and which are not providing an editor-based user interface exist(ed) several: MIT Lisp Machine OS (and derived), Interlisp-D, ... Mezzano ( https://github.com/froggey/Mezzano ).

Since Elisp was an uncomplete and smaller Lisp - and not a systems programming dialect like Lisp Machine Lisp - its code base is mostly like that: no lexical binding, no real multithreading, no really scalable language constructs, ... moving this language forward is a) not easy and b) not really in the core interest (the core task is being a language for editor extensions).

Also it is questionable whether its editor user interface is a good model for a general UI...

Post reply on HN