Re: serving ELPA over HTTP/S

[Ted Zlatanov]

On Tue, 05 May 2015 07:50:14 -0400 Stefan Monnier <address@hidden> wrote: 

>> Clearly, because I think it's worth annoying the user, since plain HTTP
>> should be the exception.

SM> "Because I like it" is not a very compelling argument in this case.

That's not what I said.  I just didn't think I needed to explain why a
plaintext protocol is a bad choice here.  There are two issues:

1) all web traffic should be encrypted by default. Unencrypted traffic
is much easier to monitor, MITM, and DoS. You can find support for this
stance pretty easily, e.g.
http://blog.codinghorror.com/should-all-web-traffic-be-encrypted/ or in
the proposed HTTP 2.0 standard. You may disagree, but I think the burden
of proof today should be on those who want to *disable* encryption.

2) Specifically for Emacs, several attacks (e.g. those against package
signature verification that have been posted on the bugs list, like the
replay attack in
https://lists.gnu.org/archive/html/bug-gnu-emacs/2015-01/msg00002.html)
are dramatically easier against a plaintext transfer than against an
encrypted one. 

If the user doesn't have GnuPG installed (and we've agreed to treat that
as an acceptable situation, right?), encrypting the transfer is even
more crucial. It's too easy for the annoyed user to say "forget
verifying signatures, I want to get my work done" so we should try to at
least put some defenses around them.

This user laziness is not a theoretical problem. See for example
https://emacs.stackexchange.com/questions/233/how-to-proceed-on-package-el-signature-check-failure
where one of the suggestions is https://emacs.stackexchange.com/a/5502

    "I changed the package-check-signature value to nil and the problem
    was resolved."

Users are not going to look into why the key was missing and contact the
package author or inspect their HTTP traffic, they'll blaze ahead.

So I note again that my proposal is simply to warn the user, not to
block them from using plain HTTP. And, of course, they'll be able to
turn off the warning if they really don't want to encrypt their package
download channel. Is that really unreasonable and annoying?

SM> Why?  Why not just
SM> (if (we-have-gnutls) <thehttpsurl> <thehttpurl>)
>> 2) because I don't think this should be set in the code.  It's a user choice.

SM> We're talking about the expression that computes the default value of
SM> a custom var.  So, of course, the user can override it in the usual way.

The default you propose is *code*, determined at runtime (unless the
user customizes it). I think instead, *in this case*, we should always
try HTTP/S first and complain when it's not available, as I said above.
The user can then choose to silence all such warnings or change the default.

>> 1) so ELPA archives can have multiple URLs. Assuming there's just one is
>> not ideal in the long term.

SM> That's a separate issue, unrelated to http/https.

And yet it would also be addressed by my proposal, so I think it's worth
considering.

Please consider how many other package managers allow multiple URLs.  Is
there a real disadvantage to allowing a list for `package-archives'
entries, especially since it degrades gracefully to the current format?
Regardless of your opinion on HTTP/S, I think this is a useful feature.

Ted