Verify TLS cert when fetching packages

[Sohalt]

Spacemacs should use verify the tls cert when fetching packages from elpa or melpa.
See https://glyph.twistedmatrix.com/2015/11/editor-malware.html for an article on how and why.

[syl20bnr]

Thank you for the report.
Although not a priority for now (but if anyone wanting to look at this now is welcome), this is definitely something we will support.

[StreakyCobra]

If we do something like this, it should be optional and not activated by default as it requires some configuration on the machine to make it works (i.e. installing and configuring the roots certificates)

[Sohalt]

Not sure security should be optional. I get that it's extra effort required and goes against spacemacs' "batteries included"/"be usable out of the box" approach, but the people who use spacemacs need to know how to use a command line and how to use git anyways, so I think it's not too much to ask them to install the certs as part of the installation process. And if it's optional for whatever reasons it should at least be enabled by default with a notice/warning on how to turn it off and the consequences thereof.

[StreakyCobra]

For me it should be, at least, optional by default because:

• As you said Spacemacs should work out of the box without having to install python/pip or some other packages on linux. I don't even know how it has to be done on OS X/Windows. I don't want to spend most of contributors' time explaining to user how to setup roots certificates and debugging related bugs (trust me, we already have tons of people with $PATH-related problem for instance)

• For this part:

  but the people who use spacemacs need to know how to use a command line and how to use git anyways

  It's not true because the only git commands users should use are written in the README. There may be researchers not used to git who may want to use it for latex, or some writers using it for Markdown/asciidoc, etc… Being a lot of time on gitter I can say without doubt that there are people not used to git nor command line who are using Spacemacs.

• If it's enabled by default then people can't even install it for giving it a try, as it will not be possible to install the packages from repositories without setting up the security first. If they just want to give Spacemacs a try, most of them will stop trying after 2 minutes.

• All this only secures the channel. They are probably some people in countries who want this because they don't trust their government/ISP, and we should offer them this feature. But all this only secures the channel. All installed packages through it are still not verified/signed, etc…

It's part of user freedom to have, or not have, this security enabled. If someone doesn't want this feature for any reason, it should be able to deactivate it. The opposite is also true. So it should be optional.

As not anybody will need, will have the time, will have the competences to setup this security level, it shouldn't be enabled by default.

[syl20bnr]

A middle ground is to add a question to the wizard with enabled selected by default. When the user disabled it a warning will be displayed in messages buffer.

Security is annoying but it is not responsible to remove it by default.

[syl20bnr]

Another possibility is to prompt the user about retrying with certificate verification ignored when the first attempt failed. This is more or less the approach of the Internet browsers.

[Sohalt]

It's not true because the only git commands users should use are written in the README.

I'm not saying they are super proficient with git, but at least they know how to use the command line. So with additional instructions in the README or possibly a shell script for setting up the cert they should be able to do it. I know this is far from ideal, as copy&pasting commands to set up the certs without knowing what the commands do sort of defeats the purpose of trying to increase security. But then on the other hand they also run spacemacs itself from the same repo that the README is contained in, so they have to trust you anyways.

If it's enabled by default then people can't even install it for giving it a try, as it will not be possible to install the packages from repositories without setting up the security first. If they just want to give Spacemacs a try, most of them will stop trying after 2 minutes.

Very true and important argument to make. As long as setting up the certs is not hassle free and well integrated in the installation process it's a show stopper for people quickly wanting to try spacemacs. I think @syl20bnr's suggestion is probably the best way to go. Ask to disable (with an explanation & disclaimer). And if it's disabled maybe ask again on each update. That way people who use spacemacs regularly and update get reminded to turn in back on if they turned it off while trying out spacemacs.

All this only secures the channel. They are probably some people in countries who want this because they don't trust their government/ISP, and we should offer them this feature. But all this only secures the channel. All installed packages through it are still not verified/signed, etc…

Also true, but nonetheless https is a big improvement over plain text. Of course ideally you would have signed packages, but that is currently not the case and therefore not possible to implement. What is possible though is using TLS to at least get a basic layer of security.

[StreakyCobra]

I'm fine either with prompting the user or asking him to try again without TLS check. I just don't want it to be forced by default.

The problem of having scripts to install root certificates at the right place is that it will be a nightmare to support for all platforms. I don't know if it is even possible at all.

so they have to trust you anyways.

Indeed. So as they have to trust us anyway, can it be an option to provide directly with spacemacs the few root certificates needed — like in a ~/.emacs/certs/ folder — with an option to use system-wise ones if wanted? If we do this I can even be fine with this enabled by default 😉

[Sohalt]

Indeed. So as they have to trust us anyway, can it be an option to provide directly with spacemacs the few root certificates needed — like in a ~/.emacs/certs/ folder — with an option to use system-wise ones if wanted? If we do this I can even be fine with this enabled by default 😉

Sounds like an option to me. Definitely not the most elegant solution, but then a shell script handling a dozen different OSes and fiddling with the truststore is neither. The "right" solution for emacs probably doesn't exist.

[StreakyCobra]

Yeah at the end it's always a notion of trust. Using the solution from the blog post, you also have to trust the certifi package owner.

I'll try to come up with something like this:

• Providing the minimal (root?) certificates needed to enable TLS verification for MELPA and GNU (ORGMODE later when https will be available) in certs/.
• Setting up a configuration like explained in the blog post using these certificates.
• Adding a variable for changing certificates location, for people wanting to use the system ones.

[Sohalt]

Thanks a lot! Really appreciate your work!

[Immortalin]

Maybe time for this?

[StreakyCobra]

It's kind of related, but out of the scope of TLS verification, as we need to provide the certificates even for people that will not use the potential bundle.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!

[ilyagr]

Has the situation improved since 2015? In 2018, https://lwn.net/Articles/759370/ happened, but I'm not sure if it means that Spacemacs is using HTTPS and checking certificates properly when loading its packages.

(Of course, this wouldn't help with malicious packages, but it would help with man-in-the-middle attacks)

Update: I'm still not quite sure what the answer is, but one place this is discussed is #7006.