4 ms·
Why is a tradeoff between convenience-and-security being considered? It's a false dichotomy - Firefox and Chrome are secure-by-default and I do not find them in
by mappu 8y ago
Why is a tradeoff between convenience-and-security being considered? It's a false dichotomy - Firefox and Chrome are secure-by-default and I do not find them inconvenient at all.
Can emacs adopt their settings wholesale?
- wyuenho 8y agoI agree. Many of the checks in my "netsec" branch does take inspirations from Firefox and Chrome. However, there's a fundamental distinction - Emacs currently has 4 security levels (hopefully soon reduced to 3), whereas browsers only have one. There are also a few RFCs that demand terminating your connection say when you've negotiated SSLv3. Emacs doesn't terminate and won't terminate before asking the user first (with caveats). Another difference is Emacs is used for all kinds of comms including email and Jabber, so browser practices may present compatibility problems with protocols other than HTTP. This is something that needs to be tested when my branch is merged into master, but this is difficult, as the current strategy seems to be just wait for a while and see if anybody complains. There's also a tendency for some people to avoid the emacs mailing lists, so the signal, or lack there of, may not be representative.
- gsnedders 8y ago> There are also a few RFCs that demand terminating your connection say when you've negotiated SSLv3. Emacs doesn't terminate and won't terminate before asking the user first (with caveats). That seems bad. There's plenty of evidence that if you ask the user "hey, do you want to continue but be insecure?" they'll blindly click "yes". While non-browser focused protocols may still rely on clients not forbidding insecure protocols, we should absolutely be trying to move away from blindly allowing insecure protocols (or effectively allowing them, given users typically click "yes"). I'd strongly suggest failing hard, and allowing per (host, port) exceptions in the config file, rather than asking every time.
- wyuenho 8y agoA 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 cipher suite or bypass NSM completely. This might sound dangerous, but it's necessary in the event of a new TLS attack was discovered, and that Emacs' default is vulnerable, the user can easily override Emacs' and GnuTLS' default outside of both of these project's release cycles. Given how infrequent Emacs releases, I think this is the right approach.
- ChrisSD 8y agoI'm struggling to see the philosophical problem with being as secure as possible by default (aka "over protective") and letting the user configure overrides as necessary?
- wyuenho 8y agoThere isn't. I've said this a couple of times in the mailing list. It's just some people appear to think there is, but I don't believe them. We all agree that Emacs should provide sensible defaults, the disagreement is what that sensible defaults consist of.
- ekidd 8y ago> 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've been mixing Emacs and Visual Studio Code, because of the latter's solid support for particular language servers.) I am completely horrified at the suggestion that it might be OK for Emacs to have have insecure TLS defaults. This would be an absolute deal-breaker for me (and would almost certainly result in Emacs being banned at work, with no objection from me). I do not have the time to fix every Emacs install on every server to be secure with the latest TLS standards. I need to be able to trust the developers of the software I use to get this right. I do not want to worry about whether `package-install` has been affected by a MITM attack.
- jcelerier 8y ago> Firefox and Chrome are secure-by-default and I do not find them inconvenient at all. I really do.
- wyuenho 8y agoNow I'm curious. Can you elaborate?
- bonaldi 8y agoI can, since I share the viewpoint. For me as a consumer, the security doesn’t affect me negatively at all. For me as a developer, working often on incomplete, immature, broken or partially broken systems, it often gets in the way. Because those things often can’t reach the high barrier of consumer-grade security - maybe because they’re broken! So to interact with those systems via HTML I have do lots of “yes I know it’s insecure, I’m trying to fix that, let me past.” As the barrier is getting higher, sometimes I simply can’t get past. This is a pain. Emacs, let’s be kind, doesn’t have a consumer audience. It has an audience working on immature/developing/broken systems.
- wyuenho 8y agoAh, then you might like the new `nsm-trust-local-network` knob I'm putting in. My "netsec" branch will also trust localhost unconditionally.