Emacs and TLS(lwn.net)
lwn.net
Emacs and TLS
https://lwn.net/Articles/759370/
82 コメント
> We provide options with some reasonable defaults, and then let users make informed decisions which defaults are not good enough for them.
This is fine for things that are apparent to the user, such as "I don't like this popup window, so I'll configure it to not show", or "I want a better command to split a quoted email, so I'll create that function". But in this case it's about something that happens behind the scenes, which users may not know needs changing.
Now that I've had the relevant comment out of the way, let me be a little more general.
> It isn't the Emacs way to second-guess our users' needs
This is an odd statement to make. Or rather, let me say, Emacs has an approach to this that I haven't been able to explain to myself yet.
It is absolutely true that Emacs tends to ship with so-so defaults, and that this is not a big deal because most users will want to change the defaults anyway. It is also the case that Emacs is very customizeable, so changing any defaults whatsoever has never been a problem.
However, the term DWIM, meaning "do what I mean", originated in Emacs circles. It still flourishes there.
I create dwim forms of commands all the time. There is often a simple contextual, environmental indicator as to whether I want one variant of a command or another. Not encapsulating that check and dispatching into a new command would be silly. That's a core part of Emacs and Lisp culture, in my opinion.
So yes, it is also in fact the Emacs way to guess the users' needs. But transparently.
This is fine for things that are apparent to the user, such as "I don't like this popup window, so I'll configure it to not show", or "I want a better command to split a quoted email, so I'll create that function". But in this case it's about something that happens behind the scenes, which users may not know needs changing.
Now that I've had the relevant comment out of the way, let me be a little more general.
> It isn't the Emacs way to second-guess our users' needs
This is an odd statement to make. Or rather, let me say, Emacs has an approach to this that I haven't been able to explain to myself yet.
It is absolutely true that Emacs tends to ship with so-so defaults, and that this is not a big deal because most users will want to change the defaults anyway. It is also the case that Emacs is very customizeable, so changing any defaults whatsoever has never been a problem.
However, the term DWIM, meaning "do what I mean", originated in Emacs circles. It still flourishes there.
I create dwim forms of commands all the time. There is often a simple contextual, environmental indicator as to whether I want one variant of a command or another. Not encapsulating that check and dispatching into a new command would be silly. That's a core part of Emacs and Lisp culture, in my opinion.
So yes, it is also in fact the Emacs way to guess the users' needs. But transparently.
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
//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.
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.
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?
Can emacs adopt their settings wholesale?
I 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.
> 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.
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.
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 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.
> 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.
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.
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.
I'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?
There 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.
We all agree that Emacs should provide sensible defaults, the disagreement is what that sensible defaults consist of.
> Firefox and Chrome are secure-by-default and I do not find them inconvenient at all.
I really do.
I really do.
Now I'm curious. Can you elaborate?
I 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.
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.
Ah, then you might like the new `nsm-trust-local-network` knob I'm putting in. My "netsec" branch will also trust localhost unconditionally.
> Pinning is what is done by sites like gmail to prevent third world dictatorships from using stolen certificate credentials to spy on their citizens. People who have been victims of this have had their email read, been arrested by state security forces for dissent, and have been tortured to death for lack of certificate pinning working in their browsers.
Well, this is awkward - Chrome has deprecated HPKP in favor of a new header: 'Expect-CT' [1]. The new header requires any cert to have a valid certificate transparency log entry and has reporting features as well [2]. This is slightly different - the scenario above would be allowed to happen and would be be valid, but that it would be logged publicly. Whatever CA (dictatorships) had issued the cert would lose their trusted status. But then again, if you have a dictatorship, then you can require that your CA remains trusted and the burden of removing trust to your dictatorship CA would be on individual users.
[1]: https://www.zdnet.com/article/google-chrome-is-backing-away-... [2]: https://scotthelme.co.uk/a-new-security-header-expect-ct/
Well, this is awkward - Chrome has deprecated HPKP in favor of a new header: 'Expect-CT' [1]. The new header requires any cert to have a valid certificate transparency log entry and has reporting features as well [2]. This is slightly different - the scenario above would be allowed to happen and would be be valid, but that it would be logged publicly. Whatever CA (dictatorships) had issued the cert would lose their trusted status. But then again, if you have a dictatorship, then you can require that your CA remains trusted and the burden of removing trust to your dictatorship CA would be on individual users.
[1]: https://www.zdnet.com/article/google-chrome-is-backing-away-... [2]: https://scotthelme.co.uk/a-new-security-header-expect-ct/
> if you have a dictatorship, you can require that your CA remains trusted
How?
I mean, I suppose you could mandate that all computers sold in your country come preinstalled with state-approved monitoring software. But barring that, what's going to stop users from downloading the latest version of Firefox which includes code marking your CA as untrusted?
How?
I mean, I suppose you could mandate that all computers sold in your country come preinstalled with state-approved monitoring software. But barring that, what's going to stop users from downloading the latest version of Firefox which includes code marking your CA as untrusted?
A police baton
Used against whom? The Firefox/Chrome/Microsoft/Linux developers don't live under your dictatorship.
The people who sell the computers in your country.
Like I said, the burden at that point is on the users
Yeeeeeep. You are correct. That subthread was too contentious for me to intervene with this information, but I think I subsequently correctly him.
I'm the new guy mentioned in the article. This article is a bit late to the party and misses a lot of details that I've discovered since June.
One of the reasons prompted this giant thread on the emacs-devel mailing list is when I was updating my Emacs config to try out Gnus for email and newsgroup, I discovered that no one seems to know exactly what a good TLS Emacs config should look like and that Emacs comes with horrible defaults. In addition, I was shocked that I've been exposed to a dozen TLS vulns that might cause arbitrary code execution the whole time since package.el became a part of Emacs back in circa-2013. After stuffing myself with about a dozen RFCs and many dozen more papers and Chrome and Firefox blog posts, here's what I found very concerning:
1. The initial "a bit concerning" and "very concerning" qualifiers I originally posted aren't as clear cut anymore, most of the 2 dozen failing badssl tests are actually quite bad.
2. NSM has got half a foot in the 2010s and half a foot in the 2000s. The latest stable version of Emacs (26.1) only checks for SHA1 end-certificate, usage of SSL, DH < 1024 bits and a noop RC4 cipher check (GnuTLS actually calls it ARCFOUR).
3. The half-done pinning mechanism does Trust on First Use while the user can't even see the entire cert chain or the end cert.
4. Only one fingerprint per host for TOFU, where Google low balances at least between 2 end-certs AFAIK.
5. Excessive and theatrical prompts for any URL that has not been visited on a security level called 'paranoid.
6. Multiple prompts for different problems found for the same TLS handshake.
7. Setting one option in a configuration group called GnuTLS to true bypasses NSM entirely. i.e. no cipher suite checks and happily accepts any 256-bit DH key exchange attempts.
8. No attempt to do any OCSP or Certificate Transparency revocation checking.
9. 4 packages intermingled with each other all securing some network connections badly with no documented relationships between them.
10. Virtually no one who has commit access to the Emacs repo understands TLS.
11. RMS prefixes every one of his email with:
The good news is, a few of these problems are already fixed on master and I've pushed a branch called "netsec" to the Emacs repo last week that fixes most of the rest. OCSP is coming this weekend. CT is going to wait quite a bit longer as GnuTLS has no plan to support it anytime soon. I have hope to make at least some of these security fixes to Emacs 26.2 or 26.3 in the short term. Medium term plan is to lobby for requiring TLS for all email protocols because RFC 8314. The long plan is obviously support TLS 1.3 for Emacs 27, and possibly HTTP2.
One of the reasons prompted this giant thread on the emacs-devel mailing list is when I was updating my Emacs config to try out Gnus for email and newsgroup, I discovered that no one seems to know exactly what a good TLS Emacs config should look like and that Emacs comes with horrible defaults. In addition, I was shocked that I've been exposed to a dozen TLS vulns that might cause arbitrary code execution the whole time since package.el became a part of Emacs back in circa-2013. After stuffing myself with about a dozen RFCs and many dozen more papers and Chrome and Firefox blog posts, here's what I found very concerning:
1. The initial "a bit concerning" and "very concerning" qualifiers I originally posted aren't as clear cut anymore, most of the 2 dozen failing badssl tests are actually quite bad.
2. NSM has got half a foot in the 2010s and half a foot in the 2000s. The latest stable version of Emacs (26.1) only checks for SHA1 end-certificate, usage of SSL, DH < 1024 bits and a noop RC4 cipher check (GnuTLS actually calls it ARCFOUR).
3. The half-done pinning mechanism does Trust on First Use while the user can't even see the entire cert chain or the end cert.
4. Only one fingerprint per host for TOFU, where Google low balances at least between 2 end-certs AFAIK.
5. Excessive and theatrical prompts for any URL that has not been visited on a security level called 'paranoid.
6. Multiple prompts for different problems found for the same TLS handshake.
7. Setting one option in a configuration group called GnuTLS to true bypasses NSM entirely. i.e. no cipher suite checks and happily accepts any 256-bit DH key exchange attempts.
8. No attempt to do any OCSP or Certificate Transparency revocation checking.
9. 4 packages intermingled with each other all securing some network connections badly with no documented relationships between them.
10. Virtually no one who has commit access to the Emacs repo understands TLS.
11. RMS prefixes every one of his email with:
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
The good news is, a few of these problems are already fixed on master and I've pushed a branch called "netsec" to the Emacs repo last week that fixes most of the rest. OCSP is coming this weekend. CT is going to wait quite a bit longer as GnuTLS has no plan to support it anytime soon. I have hope to make at least some of these security fixes to Emacs 26.2 or 26.3 in the short term. Medium term plan is to lobby for requiring TLS for all email protocols because RFC 8314. The long plan is obviously support TLS 1.3 for Emacs 27, and possibly HTTP2.
Thanks for your efforts, really appreciate it. I use Emacs daily so it's critical for me that it's secure
Don't thank me yet, a lot of these haven't made into master, thank me later if my lobbying effort is successful. :)
Question: Wouldn't it just be easier for Emacs to link to libcurl which has pretty much reasonable defaults (afaik, correct me if I'm wrong). The result would be that Emacs wouldn't need to link to a specific TLS library or have to maintain this. libcurl's API has a good reputation for not breaking :-)
Also big thanks for putting this work into Emacs. I use Emacs for hours at least every work day and many non-workdays as well.
Also big thanks for putting this work into Emacs. I use Emacs for hours at least every work day and many non-workdays as well.
I thought about linking in curl, but curl doesn't seem to offer any help in making OCSP requests separately, it only has support for OCSP stapling. Not that not having OCSP by itself is a major issue, but not having OCSP, CT and a reliable and complete CRL set to check for certificate revocations is. Since GnuTLS is a readily available, and has APIs that make OCSP requests and verify OCSP responses, and Emacs itself can already open network sockets, in the end I've decided to stick to a bunch of Lisp and a couple of simple C functions for GnuTLS.
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).
If you push hard enough...: https://curl.haxx.se/mail/lib-2012-02/0234.html :)
As far as I know you can't use libcurl to talk to smtp, or other protocols like that. They need generic socket support.
I see SMTP here: https://curl.haxx.se/libcurl/c/smtp-mail.html
And on their page they have a zillion protocols: https://curl.haxx.se/
Maybe it would be worth trying out.
And on their page they have a zillion protocols: https://curl.haxx.se/
Maybe it would be worth trying out.
Briefly (?):
As the Fedora bug notes, Default TLS security policies for the Web PKI belong at the OS level, where they can be set by a small number of people who are really thinking about these problems, once. Microsoft has done this (not very well, but they've done it) in modern SChannel .NET support, it is finally relatively easy to write code which says "I don't know, please have the usual amount of security" rather than "I'm an expert, enable this protocol version, these exact ciphersuites, and use this key" or as it more commonly the case "Here's something I pasted from a 2010 Stack Overflow post". As much as possible, and despite all insistence to the contrary by individual developers, these preferences shouldn't live in some effectively unmaintained code in each individual component.
1. In particular if you don't actually care about the identity claimed in the certificate, you shouldn't bother verifying anything at all since obviously bad guys can trivially obtain a cert for some identity.
This was once a VERY common problem, and it's still seen in plenty of places (e.g. one of the toy operating systems doesn't check at all, so the whole OS is wide open, package updates, web browser, the whole thing - another has told users any time there's a problem to switch verification off manually, so I would expect few have it left switched on by now)
2a. Although it feels as though turning min-prime bits up to 2048 would fix things, in practice interoperability is very poor. You might get away with this, in some cases, for say IMAP and SMTP submission with TLS, but it's unlikely to be satisfactory on the general web. Try asking for Elliptic Curves instead.
2b. Everybody called it ARCFOUR (Alleged RC4) for legal reasons, it's fine, don't worry about _that_.
3. I sympathise here, in principle the user ought to have examined the cert, or at least key, they're trusting. But realistically users don't do this, so the security penalty is very small indeed. Examining the entire chain is largely futile, a lot more work and an even smaller number of users would gain anything from it.
8. There isn't really such a thing as "Certificate Transparency revocation checking" and revocation is largely a dead letter for big public CAs in the Web PKI. Almost certainly a bad guy able to attack you using a real cert isn't going to be prevented in their attack by revocation, they will block the signal and you'll fail open, because as we saw in every other item, users switch off any annoying fail-closed machinery.
10. This isn't great, but the idea behind SSL/TLS is that this ends up just being a drop-in replacement for the socket layer. With the exception of some scary features like TLS 1.3's Zero RTT no TLS expertise is needed, and the correct approach if you have no TLS expertise in the Emacs developer team is to just never use those scary features, they're supposed to be gated so that you can't use them by accident.
As the Fedora bug notes, Default TLS security policies for the Web PKI belong at the OS level, where they can be set by a small number of people who are really thinking about these problems, once. Microsoft has done this (not very well, but they've done it) in modern SChannel .NET support, it is finally relatively easy to write code which says "I don't know, please have the usual amount of security" rather than "I'm an expert, enable this protocol version, these exact ciphersuites, and use this key" or as it more commonly the case "Here's something I pasted from a 2010 Stack Overflow post". As much as possible, and despite all insistence to the contrary by individual developers, these preferences shouldn't live in some effectively unmaintained code in each individual component.
1. In particular if you don't actually care about the identity claimed in the certificate, you shouldn't bother verifying anything at all since obviously bad guys can trivially obtain a cert for some identity.
This was once a VERY common problem, and it's still seen in plenty of places (e.g. one of the toy operating systems doesn't check at all, so the whole OS is wide open, package updates, web browser, the whole thing - another has told users any time there's a problem to switch verification off manually, so I would expect few have it left switched on by now)
2a. Although it feels as though turning min-prime bits up to 2048 would fix things, in practice interoperability is very poor. You might get away with this, in some cases, for say IMAP and SMTP submission with TLS, but it's unlikely to be satisfactory on the general web. Try asking for Elliptic Curves instead.
2b. Everybody called it ARCFOUR (Alleged RC4) for legal reasons, it's fine, don't worry about _that_.
3. I sympathise here, in principle the user ought to have examined the cert, or at least key, they're trusting. But realistically users don't do this, so the security penalty is very small indeed. Examining the entire chain is largely futile, a lot more work and an even smaller number of users would gain anything from it.
8. There isn't really such a thing as "Certificate Transparency revocation checking" and revocation is largely a dead letter for big public CAs in the Web PKI. Almost certainly a bad guy able to attack you using a real cert isn't going to be prevented in their attack by revocation, they will block the signal and you'll fail open, because as we saw in every other item, users switch off any annoying fail-closed machinery.
10. This isn't great, but the idea behind SSL/TLS is that this ends up just being a drop-in replacement for the socket layer. With the exception of some scary features like TLS 1.3's Zero RTT no TLS expertise is needed, and the correct approach if you have no TLS expertise in the Emacs developer team is to just never use those scary features, they're supposed to be gated so that you can't use them by accident.
What I'm working on is only tangentially related to that Fedora bug. Essentially, what the user is seeing in the GnuTLS debug log will supposedly be checked by NSM. I wasn't even aware of that bug report before I emailed emacs-devel. I'm glad I didn't tho, as that'll only add to the confusion.
Emacs's use of GnuTLS already delegates something to the OS, namely getting the system's root CA certs. As for the rest, I lobbied leaving GnuTLS defaults alone instead of intentionally lowering it to accept 256 bit DHE primes only to be warned by NSM later. Also, the default cipher suite other than DHE prime bits is already left alone OTTB.
But.... Emacs being all about freedom and infinitely hackable, the philosophy (philosophers?) demand that we let users to be able to configure the lower bound of acceptable TLS security in 2 different places, because someone somewhere requested it at one time, therefore his or her need trumps everyone else's default security or requests to have a consistent UI for TLS configuration. This is the context behind that fixation quote Lars wrote. Of course, I disagree strongly. The good news is, I've already returned all GnuTLS knobs to their defaults in my branch, and Lars has fixed the docs so people know they probably shouldn't touch those GnuTLS settings unless they want to bypass NSM completely, say running a elisp script for example.
I'm not going to respond to the rest of your points, they require a fair bit of context to understand why I think they are problems. I'll probably explain it in a blog some time this weekend.
Emacs's use of GnuTLS already delegates something to the OS, namely getting the system's root CA certs. As for the rest, I lobbied leaving GnuTLS defaults alone instead of intentionally lowering it to accept 256 bit DHE primes only to be warned by NSM later. Also, the default cipher suite other than DHE prime bits is already left alone OTTB.
But.... Emacs being all about freedom and infinitely hackable, the philosophy (philosophers?) demand that we let users to be able to configure the lower bound of acceptable TLS security in 2 different places, because someone somewhere requested it at one time, therefore his or her need trumps everyone else's default security or requests to have a consistent UI for TLS configuration. This is the context behind that fixation quote Lars wrote. Of course, I disagree strongly. The good news is, I've already returned all GnuTLS knobs to their defaults in my branch, and Lars has fixed the docs so people know they probably shouldn't touch those GnuTLS settings unless they want to bypass NSM completely, say running a elisp script for example.
I'm not going to respond to the rest of your points, they require a fair bit of context to understand why I think they are problems. I'll probably explain it in a blog some time this weekend.
> One of the toy operating systems doesn't check at all, so the whole OS is wide open, package updates, web browser, the whole thing - another has told users any time there's a problem to switch verification off manually, so I would expect few have it left switched on by now
Could you say which OSes?
Could you say which OSes?
Sure, Haiku doesn't check, the Amiga systems advise people to switch off verification.
Huh? Haiku has had certificate verification for a long time, and the issues related to false-negative verifications got straightened out in 2012 or so; the web browser has always checked even before that, and for the package manager all builds past last December have had HTTPS downloads by default.
Your point #11 is a bit distasteful.
Beyond that, npm is far more vulnerable. But it rarely matters. The reason is culture and community.
Beyond that, npm is far more vulnerable. But it rarely matters. The reason is culture and community.
I appreciate you announcing your preference of taste, but honestly, if you don't have anything of substance to add to the conversation, please don't pollute the thread.
I'm a former pentester. I used to do this kind of work for a living. Secondly, the Snowden leaks were one of the most important events in modern history, and you're on here using them as a cheap way to push your own agenda. Thirdly, RMS hasn't been an active emacs developer for quite awhile, but you're still trying to criticize him.
To bring this back to the topic at hand: npm as an ecosystem is far more vulnerable than the points you mention. It's worth considering why people do not routinely pwn those who use npm. The fact that you are vulnerable does not mean it's a good idea to try to throw an entire ecosystem under the bus.
To bring this back to the topic at hand: npm as an ecosystem is far more vulnerable than the points you mention. It's worth considering why people do not routinely pwn those who use npm. The fact that you are vulnerable does not mean it's a good idea to try to throw an entire ecosystem under the bus.
> Secondly, the Snowden leaks were one of the most important events in modern history, and you're on here using them as a cheap way to push your own agenda. Thirdly, RMS hasn't been an active emacs developer for quite awhile, but you're still trying to criticize him.
I don't see where you got any of that. I read point #11 as citing RMS in his capacity as an authority on GNU goals and principles, a capacity in which he still contributes guidance to Emacs and other GNU projects.
Maybe there's some context missing. GNU is an unapologetically political project; decisions are meant to be made not solely in pursuit of some narrow definition of technical superiority or correctness, but being mindful of their effects on the free software movement and human societies in general. From that perspective, it's completely reasonable to be surprised if a GNU project appears to be out of alignment with a major sociopolitical concern of RMS. For example, if GCC 9.0 were released under the original BSD license, people would be surprised and concerned for fundamentally similar reasons.
I don't see where you got any of that. I read point #11 as citing RMS in his capacity as an authority on GNU goals and principles, a capacity in which he still contributes guidance to Emacs and other GNU projects.
Maybe there's some context missing. GNU is an unapologetically political project; decisions are meant to be made not solely in pursuit of some narrow definition of technical superiority or correctness, but being mindful of their effects on the free software movement and human societies in general. From that perspective, it's completely reasonable to be surprised if a GNU project appears to be out of alignment with a major sociopolitical concern of RMS. For example, if GCC 9.0 were released under the original BSD license, people would be surprised and concerned for fundamentally similar reasons.
What's my agenda exactly and why do you think I'm criticizing RMS? Is that quote my words? And what does being a former pentester have to do with anything you said? Which ecosystem am I throwing under the bus?
The quality of HN is more important than winning. Let's have a conversation worth reading.
The reason I laid out some creds is because you seemed to ignore the substantive part of my comment, twice now.
It is tradition in the security field to make every security incident seem like a very big deal. (See tptacek's comment on cloudflare's memory leak, for example.) But just because there exist vulnerabilities, it does not mean that (a) anyone has exploited them or (b) that you are in any kind of danger.
I was shocked that I've been exposed to a dozen TLS vulns that might cause arbitrary code execution the whole time since package.el became a part of Emacs back in circa-2013.
This sentence makes it sound like anyone who has used emacs in any way since 2013 has been in immediate risk of having their computer taken over. Maybe that's true. But even if it were true, what precisely would the steps be to make this attack happen? Have you proved that it can be done?
EDIT: The main point I'd like to get across is that it's worth fixing security problems, but it's important to maintain a spirit of cooperation rather than accusation. Everyone has security issues. Even (perhaps especially) the big names that you wouldn't expect to. That's why people pay pentesters a lot of money -- we're effective at making sure no one else finds them before we do. But emacs doesn't have the resources to get a pentest, and out of all the security vulnerabilities they could possibly have, a few TLS flaws wouldn't even be marked as medium severity unless there were a direct way to take over a user's computer via the flaw.
The reason I laid out some creds is because you seemed to ignore the substantive part of my comment, twice now.
It is tradition in the security field to make every security incident seem like a very big deal. (See tptacek's comment on cloudflare's memory leak, for example.) But just because there exist vulnerabilities, it does not mean that (a) anyone has exploited them or (b) that you are in any kind of danger.
I was shocked that I've been exposed to a dozen TLS vulns that might cause arbitrary code execution the whole time since package.el became a part of Emacs back in circa-2013.
This sentence makes it sound like anyone who has used emacs in any way since 2013 has been in immediate risk of having their computer taken over. Maybe that's true. But even if it were true, what precisely would the steps be to make this attack happen? Have you proved that it can be done?
EDIT: The main point I'd like to get across is that it's worth fixing security problems, but it's important to maintain a spirit of cooperation rather than accusation. Everyone has security issues. Even (perhaps especially) the big names that you wouldn't expect to. That's why people pay pentesters a lot of money -- we're effective at making sure no one else finds them before we do. But emacs doesn't have the resources to get a pentest, and out of all the security vulnerabilities they could possibly have, a few TLS flaws wouldn't even be marked as medium severity unless there were a direct way to take over a user's computer via the flaw.
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/IMAP equally applies to Emacs if you've ever downloaded something over HTTPS or login to a server say Github via an API package like ghub.el. Email is worse with STARTTLS, although the attributes are different. SMTP/IMAP connections tend to be much shorter and less frequent, so your area of exposure may be smaller> But since emails tend to contain a lot of vital PII, the actual harm is probably greater than knowing your session cookie for a blog. Losing email credentials is also quite devastating.
Second of all, TLS is mostly used to guard against all kinds of MITM attacks. There are some kinds of MITM attacks easier to carry out than others, and they don't have to be targeted. Logging into your email account using a coffee shop's wifi without checking for known vulns before tranmission of TLS records doesn't sound very comforting to me.
Security, most of the time is about prevention rather than mitigation after the fact, just like you would wear a seat belt even though your likelihood of dying in a car crash isn't very high. Am I supposed to be not shocked to discover my car comes with a seat belt made out of a thin piece of printer paper?
P.S Since we are putting out credentials, I used to work at Cloudflare, not that I was in any security or systems engineering capacity, but I have also been quite interested in security issues. I guess that makes me a "security-hobbyist".
//edit after your edit
You probably should stop accusing me of accusing anybody, that's the exact opposite of what I have done. Please read the last link in the article (https://lwn.net/Articles/759460/).
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/IMAP equally applies to Emacs if you've ever downloaded something over HTTPS or login to a server say Github via an API package like ghub.el. Email is worse with STARTTLS, although the attributes are different. SMTP/IMAP connections tend to be much shorter and less frequent, so your area of exposure may be smaller> But since emails tend to contain a lot of vital PII, the actual harm is probably greater than knowing your session cookie for a blog. Losing email credentials is also quite devastating.
Second of all, TLS is mostly used to guard against all kinds of MITM attacks. There are some kinds of MITM attacks easier to carry out than others, and they don't have to be targeted. Logging into your email account using a coffee shop's wifi without checking for known vulns before tranmission of TLS records doesn't sound very comforting to me.
Security, most of the time is about prevention rather than mitigation after the fact, just like you would wear a seat belt even though your likelihood of dying in a car crash isn't very high. Am I supposed to be not shocked to discover my car comes with a seat belt made out of a thin piece of printer paper?
P.S Since we are putting out credentials, I used to work at Cloudflare, not that I was in any security or systems engineering capacity, but I have also been quite interested in security issues. I guess that makes me a "security-hobbyist".
//edit after your edit
You probably should stop accusing me of accusing anybody, that's the exact opposite of what I have done. Please read the last link in the article (https://lwn.net/Articles/759460/).
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 about prevention rather than mitigation after the fact, just like you would wear a seat belt even though your likelihood of dying in a car crash isn't very high. Am I supposed to be not shocked to discover my car comes with a seat belt made out of a thin piece of printer paper?
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.
You have a responsibility as someone who is presenting security issues to know what you're talking about. Most people listen to whoever talks the most confidently. And the bare minimum work is proving that the exploits you're presenting are actually applicable to the situation at hand.
Most people don't know security, and very few people will check your work to ensure it's correct. That means when some hobbyist steps up and starts yelling about theoretical issues, it's important to step in and say "Actually, these issues haven't been demonstrated."
What if it takes $100M to MITM someone? Would you say it's still worth being shocked that you're theoretically vulnerable to this? What is the precise cost of someone who actually wanted to MITM someone else using emacs? Have you done the math?
This isn't me downplaying the significance. This is me saying "Do the work." And if you haven't, then you should classify the vulns as low severity. That's what we did whenever we didn't know for a fact that you could own someone's app/box.
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 about prevention rather than mitigation after the fact, just like you would wear a seat belt even though your likelihood of dying in a car crash isn't very high. Am I supposed to be not shocked to discover my car comes with a seat belt made out of a thin piece of printer paper?
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.
You have a responsibility as someone who is presenting security issues to know what you're talking about. Most people listen to whoever talks the most confidently. And the bare minimum work is proving that the exploits you're presenting are actually applicable to the situation at hand.
Most people don't know security, and very few people will check your work to ensure it's correct. That means when some hobbyist steps up and starts yelling about theoretical issues, it's important to step in and say "Actually, these issues haven't been demonstrated."
What if it takes $100M to MITM someone? Would you say it's still worth being shocked that you're theoretically vulnerable to this? What is the precise cost of someone who actually wanted to MITM someone else using emacs? Have you done the math?
This isn't me downplaying the significance. This is me saying "Do the work." And if you haven't, then you should classify the vulns as low severity. That's what we did whenever we didn't know for a fact that you could own someone's app/box.
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.
> 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.
The RMS quote should be seen in the light of the usual message when security researcher talk about the NSA. That is to say if you need protection against state level attackers, relying on a single layer of security technology is insufficient and should always be considered as an exploitable vulnerability that will be broken at some time in the future. Imploring the state actors to act in the same moral way as Snowden is here a last line of defense.
In the context of TLS in Emacs, I don't see how it is a very concerning point in similar style as failing badssl tests. The implied claim that RMS is writing his footer because he thinks the emacs security is faulty is not supported. As such the RMS part of #11 is not supported and do not contribute to the TLS implementation and configuration discussion in regards to Emacs.
In the context of TLS in Emacs, I don't see how it is a very concerning point in similar style as failing badssl tests. The implied claim that RMS is writing his footer because he thinks the emacs security is faulty is not supported. As such the RMS part of #11 is not supported and do not contribute to the TLS implementation and configuration discussion in regards to Emacs.
I agree with your first paragraph, but I didn't claim RMS thinks Emacs security is faulty. In fact, RMS doesn't seem to be aware of the problems of Emacs' network security. That RMS quote is there to point out the irony that RMS cares enough about security and privacy to prefix all of his emails with that preamble, but not enough to alarm emacs-devs about it. It's well-known that RMS has not been active in Emacs' development for many years now, the responsibility is not on him anymore.
I am missing something here. Emacs is a text/programmer's editor (I know you browse the web, read email, talk to eliza, etc...), but where is TLS being used exactly? (BTW, I have been using emacs since at least the early 90's, but never did anything requiring TLS).
Do you ever install packages from Emacs? If so, you definitely want that to be at least TLS protected.
https://glyph.twistedmatrix.com/2015/11/editor-malware.html is a post describing the problem and some solutions. I haven't checked to see how many of the steps are still necessary on Emacs 26, but I bet it's still non-zero.
https://glyph.twistedmatrix.com/2015/11/editor-malware.html is a post describing the problem and some solutions. I haven't checked to see how many of the steps are still necessary on Emacs 26, but I bet it's still non-zero.
>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 right solution for something like that.
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 right solution for something like that.
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 can't meddle with the packages, or the metadata, or anything.
You absolutely can secure everything in your package management system, but it will be a bit trickier than just signing individual packages. Whereas using TLS is enough.
Back in 1995 when anonymous FTP distribution was commonplace, signing packages made a whole lot more sense than trying to get all your mirrors to update to HTTPS. In 2018 this is not so true.
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 can't meddle with the packages, or the metadata, or anything.
You absolutely can secure everything in your package management system, but it will be a bit trickier than just signing individual packages. Whereas using TLS is enough.
Back in 1995 when anonymous FTP distribution was commonplace, signing packages made a whole lot more sense than trying to get all your mirrors to update to HTTPS. In 2018 this is not so true.
They should be doing all of that anyhow. Servers get hacked. TLS doesn't fix the metadata replay problem.
This blog post was not a complete advice then and it's not a complete advice now, as it says nothing about what to give to gnutls-min-prime-bit, gnutls-algorith-priority and how to turn off NSM.
See if this works for you on Emacs 25 and 26: https://news.ycombinator.com/item?id=17573969
See if this works for you on Emacs 25 and 26: https://news.ycombinator.com/item?id=17573969
There are people running and working with emacs' shell, read the news, rss, stock market, emails, calendar etc. See the OS punchline below. Thus beyond basic operations of emacs like package management that require a secure connection you have a user's day to day activity.
Many places. Emacs has a built-in web browser, IMAP client, etc. It also has a package manager that can download packages over https.
Most common use case for people using only the text editor part is probably the package manager downloading files in clear text.
The old joke goes, Emacs is a great OS, if only it had a decent text editor!
You beat me to the punchline. Yes, you can do pretty much anything. (Edit: I guess in the spirit of the joke anything besides writing lol. Shameless plug: I use emacs.)
How about booting straight into emacs? https://www.informatimago.com/linux/emacs-on-user-mode-linux...
You answered it yourself: When you browse the web and read email.
[deleted]
Yes, but who actually does that?
I use exwm (emacs) as my windows manager, rcirc as my irc client, eww as my browser, gnus for email, magit for git, tramp for remote control. All of these tools make use of TLS. Honestly, I literally live my life on a computer. If you do it to the extreme that I do then you will find that customizing your experience becomes important. Emacs is designed from the ground up for customizability.
I use notmuch-mode[0] to read my email and I get a lot of email. It's easy to sort and quick to search. In this case, other tools communicate with the mail server.
I use Calfw[1] to keep an eye on my calendar, I believe this mode uses TLS when communicating with Google, etc.
[0]: https://notmuchmail.org/notmuch-emacs/
[1]: https://github.com/kiwanami/emacs-calfw
I use Calfw[1] to keep an eye on my calendar, I believe this mode uses TLS when communicating with Google, etc.
[0]: https://notmuchmail.org/notmuch-emacs/
[1]: https://github.com/kiwanami/emacs-calfw
I read e-mail. I'm not yet comfortable with browsing the web through Emacs, but I'm slowly getting to it.
Emacs is a superior environment for anything having to do primarily with text. Mail is mostly text, so it's a natural fit. Most of the actually useful content on the Web is text as well, so a large percentage of browsing can benefit from this environment as well.
Emacs is a superior environment for anything having to do primarily with text. Mail is mostly text, so it's a natural fit. Most of the actually useful content on the Web is text as well, so a large percentage of browsing can benefit from this environment as well.
There are tons of people who read email in Emacs, mu4e is great. Browsing the web is probably less common.
Don’t all of the package managers use the web?
I build my Emacs distribution, including packages, using Nix[1], which means that input hashes of all the package sources are fully pinned. This process is external to Emacs though.
The Emacs internal managers all go towards the same HTTP(S) sources and I haven't seen one that pins input hashes or uses signatures, with the exception of pinning git commit hashes when using git as a package source in straight.el[2].
[1]: https://github.com/tazjin/nixos-config/blob/master/emacs.nix [2]: https://github.com/raxod502/straight.el#advantages-of-straig...
The Emacs internal managers all go towards the same HTTP(S) sources and I haven't seen one that pins input hashes or uses signatures, with the exception of pinning git commit hashes when using git as a package source in straight.el[2].
[1]: https://github.com/tazjin/nixos-config/blob/master/emacs.nix [2]: https://github.com/raxod502/straight.el#advantages-of-straig...
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.
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...
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...
Thank you for this explanation, it gives me a better idea about Emacs' design.
Kinda on-topic, I still don't know how to setup Emacs 26 (which is a relatively recent release) on macOS - as opposed to all prior versions.
Installation of packages will fail due to the TLS changes.
This seems the best-informed solution but it's not working for me: https://blog.vifortech.com/posts/emacs-tls-fix/
Installation of packages will fail due to the TLS changes.
This seems the best-informed solution but it's not working for me: https://blog.vifortech.com/posts/emacs-tls-fix/
I don't know exactly why this solution won't work for you, there could be a number of issues at play here.
In short, try this:
1. Reset all your 'tls 'nsm and 'gnutls customize options to their defaults.
2. $ rm -rf ~/.emacs.d/network-security.data
3. Install https://github.com/antifuchs/safe-tls-defaults-mode/blob/mas...
This nice gentlement packaged up the settings I suggested on a Reddit thread. It should work most of the time, if not, you can adjust the CLI string.
In short, try this:
1. Reset all your 'tls 'nsm and 'gnutls customize options to their defaults.
2. $ rm -rf ~/.emacs.d/network-security.data
3. Install https://github.com/antifuchs/safe-tls-defaults-mode/blob/mas...
This nice gentlement packaged up the settings I suggested on a Reddit thread. It should work most of the time, if not, you can adjust the CLI string.
Tried out, no luck unfortunately. With that setup, both E25 and E26 get stuck forever while trying to fill the `~/.emacs/d/elpa` directory (with an actual freeze and no feedback)
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?
I just removed the repo - I'd say that Melpa won in recent years?
Oh it's won many years ago :)
I install it from MacPorts with no problems.
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?
But maybe it's Emacs' fault?
> It is IMO unreasonable to make our defaults match what happens in dictatorships that you describe, because that would unnecessarily inconvenience the majority of the users. Let's not follow the bad example of the TSA (whose rationale is, unsurprisingly, also matters of life and death).
Here's that same response in an alternate Gnuniverse where software development is... different...:
"Thanks, Jimmy. Security is outside my wheelhouse, so let me run your ideas by a security researcher I already know and trust. Then we'll figure out the most effective way to improve TLS in Emacs without creating a maintenance burden for the project.
Best, A sensible developer who knows what they don't know"