remove --insecure option

[glyph]

It is not appropriate for spacemacs to execute arbitrary unverified code from the Internet; the risks are not clearly explained. (If they were, the option would not exist.)

Instead, the README should document an easy way to properly verify TLS.

[StreakyCobra]

It is not appropriate for spacemacs to execute arbitrary unverified code from the Internet

Even when packages are downloaded through HTTPS, there isn't any form of verification nor signing on MELPA yet, so it's still arbitrary unverified code that you are executing (except if you review manually all the packages downloaded on your computer, what most users don't). Also, the secure is the default now, so I don't see the problem having a flag that let the user disable it. If you really want to remove this flag, please also take care of all issues related to HTTPS (Misconfigurations, proxies, companies firewalls, China users, …).

Don't misunderstand me, HTTPS is far better and it's why it's the Spacemacs default. But being pragmatic, it's not possible to force its usage to everyone, and anyway it's still not a guarantee of code verification, so it shouldn't be sold with this argument.

the risks are not clearly explained. (If they were, the option would not exist.)

The risks can be explained better (PR welcome), and maybe this should not be the default code snippet for installation in the README, this can of course be discussed. But we need to keep in mind that doing this will result in more opened issues.

Instead, the README should document an easy way to properly verify TLS.

A PR would be a nice starting point. Also it would be better to directly include the support within Spacemacs. Feel free to take over my initial attempt at
#4009 and improve/finish it :-)

[d12frosted]

To be honest, we could add verification just like @glyph described in this article (look for sections 4 and 5).

[TheBB]

I believe that's what #4009 is about. @StreakyCobra doesn't work here any more so it's just waiting for somebody to take over.

Thanks for voicing the pragmatic point of view though @StreakyCobra. We get enough ticket traffic about this as it is.

[d12frosted]

@TheBB oh sorry, didn't look at that PR 😲

@StreakyCobra doesn't work here any more so it's just waiting for somebody to take over.

@StreakyCobra he exploded on keyboard-layouts layer 😸 💃

[glyph]

Even when packages are downloaded through HTTPS, there isn't any form of verification nor signing on MELPA yet, so it's still arbitrary unverified code that you are executing (except if you review manually all the packages downloaded on your computer, what most users don't).

This is a common misunderstanding of the distinction between package signing and HTTPS. If the code is retrieved via HTTPS, then it is verified; the bytes sent over the wire must be signed by a private key, which was itself signed by a certificate authority. By contrast, bytes signed by an arbitrary PGP key are not verified; you have to have some way to trust the PGP key (which probably means retrieving it over HTTPS, practically speaking, since the "web of trust" model is something that very few people participate in).

Package signatures are mostly a performance optimization; they allow you to trust more and different people in the path of handling the bytes, allowing for more widespread mirroring, secure peer-to-peer transfers, etc. Ultimately the trust roots resolve in similar ways (although signatures may be a security benefit if there's a strong certification authority that is stricter than WebTrust).

Don't misunderstand me, HTTPS is far better and it's why it's the Spacemacs default.

My tone did not adequately express my gratitude for this. Spacemacs definitely does better than emacs by default ;)

Also, the secure is the default now, so I don't see the problem having a flag that let the user disable it. If you really want to remove this flag, please also take care of all issues related to HTTPS (Misconfigurations, proxies, companies firewalls, China users, …).

Users may have legitimate reasons to want to change their trust roots; although, I think you may be overestimating the number of places where they might need to do so. (Users in China, for example, have perfectly functioning TLS; the great firewall mostly just blocks sites, it rarely disables their security.) Browsers have been slowly ratcheting up the complexity of the UI to disable security over time.

However, while you might want to change your trust roots or set a proxy, the main reason for wanting to disable security entirely is your first point: misconfiguration. So what are the common misconfigurations that users encounter? How can they be fixed? Why is this suggestion present in the README at all; shouldn't spacemacs be correctly configured out of the box?

[StreakyCobra]

This is a common misunderstanding of the distinction between package signing and HTTPS. If the code is retrieved via HTTPS, then it is verified; the bytes sent over the wire must be signed by a private key, which was itself signed by a certificate authority. By contrast, bytes signed by an arbitrary PGP key are not verified; you have to have some way to trust the PGP key (which probably means retrieving it over HTTPS, practically speaking, since the "web of trust" model is something that very few people participate in).

Package signatures are mostly a performance optimization; they allow you to trust more and different people in the path of handling the bytes, allowing for more widespread mirroring, secure peer-to-peer transfers, etc. Ultimately the trust roots resolve in similar ways (although signatures may be a security benefit if there's a strong certification authority that is stricter than WebTrust).

For me the two are verification, but of different kind. With HTTPS you just verify that you are really downloading the bytes from where they come from, but in the MELPA case you have no guarantee about what the codes are doing and whom wrote them, because MELPA is just an intermediary platform for sharing other people's code automatically. With package signing you would be able to verify that the code you have downloaded is coming from a trusted person, and that is hasn't been altered in the meantime of arriving to your computer.

Using HTTPS is already a must have because you know the code you asked on MELPA is coming from MELPA and hasn't been altered on the way. But I wouldn't say that it is verified (in the sense reviewed/trusted). I can create a malicious MELPA package, and share it to the world, HTTPS won't prevent people to get and run my malicious code.

Users may have legitimate reasons to want to change their trust roots; although, I think you may be overestimating the number of places where they might need to do so. (Users in China, for example, have perfectly functioning TLS; the great firewall mostly just blocks sites, it rarely disables their security.) Browsers have been slowly ratcheting up the complexity of the UI to disable security over time.

I based my saying on the issues that I saw arriving after we introduced HTTPS as the default, so there were some chinese users having trouble with HTTPS, there were people having troubles with companies firewall, and so on.

However, while you might want to change your trust roots or set a proxy, the main reason for wanting to disable security entirely is your first point: misconfiguration. So what are the common misconfigurations that users encounter? How can they be fixed? Why is this suggestion present in the README at all; shouldn't spacemacs be correctly configured out of the box?

There are probably too many different possible combinations of proxy, firewall, network configuration, device, etc… to be able to give general fixes to the misconfigurations. Some others issues, like companies firewall, can not be fixed by Spacemacs users at all.

---

What I'm trying to say is that:

• Yes, HTTPS should be used and should be the default.
• No, HTTPS does not fully resolve the problem of package verification.
• No, we can not remove the --insecure option because some users don't have the possibilities to fix their networking environment.
• Yes, documentation can be improved regarding these problems. Someone just has to do it, PR welcome :-)

[JAremko]

If you are in the environment where TLS is unavailable you won't be unable to get "verified" Spacemacs from the github. So it doesn't matter what this Spacemacs version will download and from where 😃

[glyph]

No, we can not remove the --insecure option because some users don't have the possibilities to fix their networking environment.

This is what I'm disagreeing with. Chrome, firefox, et. al. do not have an "insecure" option for HTTPS. They just have the ability to add trust roots.

[StreakyCobra]

This is what I'm disagreeing with. Chrome, firefox, et. al. do not have an "insecure" option for HTTPS. They just have the ability to add trust roots.

For me the comparison doesn't hold because chrome, firefox, etc. are still allowing you to access the HTTP version of a website even when an HTTPS version is available, exactly like we allow our users to access MELPA trough HTTP even is HTTPS is available.

I respect your fight for pushing forward the use of HTTPS — I use HttpsEverywhere and other privacy plugins and I'm convinced by the need of doing so — but I disagree with your method. We should try to explain this to the users, we should try to convince them to use HTTPS with arguments, by encouraging HTTPS usage (as we did by setting HTTPS as the default), but not by the force. We should let them the freedom to decide to use HTTP anyway if they want to, and this whatever are their reasons.

[glyph]

I respect your fight for pushing forward the use of HTTPS — I use HttpsEverywhere and other privacy plugins and I'm convinced by the need of doing so — but I disagree with your method. We should try to explain this to the users, we should try to convince them to use HTTPS with arguments, by encouraging HTTPS usage (as we did by setting HTTPS as the default), but not by the force. We should let them the freedom to decide to use HTTP anyway if they want to, and this whatever are their reasons.

The problem is the issue of informed consent. Users - even quite technically sophisticated users - rarely understand the potentially terrible consequences of executing code that was retrieved over plain-text; the ridiculously low cost of attack, the free availability of tools that can execute one, etc.

However, you're a maintainer of spacemacs and I'm not, so ultimately if we disagree it's your decision :).

Hopefully we can agree that mentioning it front-and-center in the README Is not a good idea. If users are told "use HTTPS, and if there's a problem, whatever, security's weird, fall back to HTTP, here's how" then users will learn to ignore SSL warnings and just pass --insecure. And if users are going to do that by default, we might as well just forget about having SSL by default, because an attacker can just block the HTTPS port or offer an invalid cert and users will blindly accept their malware as a result. The README literally tells users to ignore warnings and skip straight to --insecure.

While the option itself might have to remain for some circumstances you believe exist, "you saw a warning, you didn't know what it meant" should absolutely not be something that the README recommends to new users.

[StreakyCobra]

However, you're a maintainer of spacemacs and I'm not, so ultimately if we disagree it's your decision :).

I'm not anymore, so my opinion is not better or worse than yours regarding this :-)

Hopefully we can agree that mentioning it front-and-center in the README Is not a good idea. If users are told "use HTTPS, and if there's a problem, whatever, security's weird, fall back to HTTP, here's how" then users will learn to ignore SSL warnings and just pass --insecure. And if users are going to do that by default, we might as well just forget about having SSL by default, because an attacker can just block the HTTPS port or offer an invalid cert and users will blindly accept their malware as a result. The README literally tells users to ignore warnings and skip straight to --insecure.

Yes, I think we can agree that this shouldn't be the README default to tell people to use --insecure.

While the option itself might have to remain for some circumstances you believe exist, "you saw a warning, you didn't know what it meant" should absolutely not be something that the README recommends to new users.

I do believe the option should remain, not only for circumstances reasons, but also for freedom reason..

---

What about not proposing the --insecure in the README by default, but instead to propose a link to a FAQ entry in case of troubles. The FAQ entry then explains the risks and reasons of HTTP/HTTPS, let the user know about --insecure and the security implications of using it?

[JAremko]

I wonder what @syl20bnr thinks 😕

[syl20bnr]

I'm on the pragmatic side but we can greatly improve the situation with better information like it has been suggested here. A link to the blog article where we explain briefly the risks is a must have.

[kini]

A rather severe bug in Emacs versions earlier than 26 make it impossible to make HTTPS connections over a proxy: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=11788

So the best network configuration in the world won't stop users of Emacs <=25 from needing the --insecure option when behind a proxy.

[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!

[glyph]

If the option still exists, the issue is still valid; does it?

[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!

[syl20bnr]

@glyph don't mind too much about the bot, it just blindly marks the issues after some time with no activity. It gives us an opportunity to review the old issues.

This issue is still valid indeed.

[glyph]

@syl20bnr Thanks for continuing to pay attention to it :)

[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!

[glyph]

@syl20bnr Would you accept a PR that at least removed it from the README? Very few people in the world are behind the sort of proxy that would require this option.

[lebensterben]

@glyph

How about moving it from README to FAQ?

[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!

[glyph]

How about moving it from README to FAQ?

The option should be removed entirely; there's no reason to enable it.