emacs-devel
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

https and emacs and package archives

From: Nic Ferrier
Subject: https and emacs and package archives
Date: Mon, 27 Oct 2014 17:07:42 +0000 
I moved marmalade-repo to HTTPS.

Ever since a few people with 24.4 have been having trouble.


And today I experienced a really strange thing with 24.4.

I wrote this code to be used to automatically download packages:

  (when (member
         "elpakit-run.el"
         (mapcar 'file-name-nondirectory command-line-args))
    (let ((package-user-dir (make-temp-name "elpakit-run")))
      (package-initialize)
      (add-to-list
       'package-archives
       '("marmalade" . "https://marmalade-repo.org/packages/";))
      (package-refresh-contents)
      (package-install 'elpakit)))

And here's what happened when I ran it:

 $ ~/emacs-24-4/bin/emacs -batch -l ~/work/elpakit/elpakit-run.el 

 ("/home/nicferrier/emacs-24-4/bin/emacs" "-l" 
"/home/nicferrier/work/elpakit/elpakit-run.el")
 Importing package-keyring.gpg...
 Importing package-keyring.gpg...done
 Contacting host: marmalade-repo.org:443
 Contacting host: elpa.gnu.org:80
 Making version-control local to dash-autoloads.el while let-bound!
 Generating autoloads for dash.el...
 Generating autoloads for dash.el...done
 Saving file 
/home/nicferrier/scratch/elpakit-run15942qZn/dash-2.9.0/dash-autoloads.el...
 Wrote /home/nicferrier/scratch/elpakit-run15942qZn/dash-2.9.0/dash-autoloads.el
 Checking /home/nicferrier/scratch/elpakit-run15942qZn/dash-2.9.0...
 Compiling 
/home/nicferrier/scratch/elpakit-run15942qZn/dash-2.9.0/dash-autoloads.el...
 Compiling 
/home/nicferrier/scratch/elpakit-run15942qZn/dash-2.9.0/dash-pkg.el...
 Wrote /home/nicferrier/scratch/elpakit-run15942qZn/dash-2.9.0/dash-pkg.elc
 Compiling /home/nicferrier/scratch/elpakit-run15942qZn/dash-2.9.0/dash.el...
 Wrote /home/nicferrier/scratch/elpakit-run15942qZn/dash-2.9.0/dash.elc
 Done (Total of 2 files compiled, 1 skipped)
 Contacting host: marmalade-repo.org:443
 Contacting host: marmalade-repo.org:443
 Generating autoloads for anaphora.el...
 Generating autoloads for anaphora.el...done
 Saving file 
/home/nicferrier/scratch/elpakit-run15942qZn/anaphora-1.0.0/anaphora-autoloads.el...
 Wrote 
/home/nicferrier/scratch/elpakit-run15942qZn/anaphora-1.0.0/anaphora-autoloads.el
 (No changes need to be saved)
 Checking /home/nicferrier/scratch/elpakit-run15942qZn/anaphora-1.0.0...
 Compiling 
/home/nicferrier/scratch/elpakit-run15942qZn/anaphora-1.0.0/anaphora-autoloads.el...
 Compiling 
/home/nicferrier/scratch/elpakit-run15942qZn/anaphora-1.0.0/anaphora-pkg.el...
 Wrote 
/home/nicferrier/scratch/elpakit-run15942qZn/anaphora-1.0.0/anaphora-pkg.elc
 Compiling 
/home/nicferrier/scratch/elpakit-run15942qZn/anaphora-1.0.0/anaphora.el...
 Wrote /home/nicferrier/scratch/elpakit-run15942qZn/anaphora-1.0.0/anaphora.elc
 Done (Total of 2 files compiled, 1 skipped)
 https://marmalade-repo.org/packages/elpakit-1.1.1.el: Bad Request

In other words downloading that file over https did not work.

But then I tried changing the package-archive reference to:

  http://marmalade-repo.org/packages/

in other words, dropping the HTTPS.

Guess what? It worked.

That is NOT because marmalade-repo.org is serving HTTP, it isn't. It
simply redirects every HTTP request to an equivalent HTTPS request with
a 301 redirect.

If you doubt that, you're not alone. I was so bemused by the behaviour I
checked it and here's the packet log:

  
http://nic.ferrier.me.uk/pastes/OTU2N2QxNTQ3ZTEwNTQ3MGU0ZTUzYzE1NjhmMDdhMjA5ZTgyYTE2MQ==

So that definitely shows marmalade is working properly.


So switching back to HTTPS, what is going wrong?

The depends of a package are all downloaded with HTTPS fine. But then:

  GET /packages/elpakit-1.1.1.el HTTP/1.1..
  MIME-Version: 1.0..
  Connection: keep-alive..
  Extension: Security/Digest Security/SSL..
  Host: marmalade-repo.org..
  Accept-encoding: gzip..Accept: */*..
  User-Agent: URL/Emacs....  
##
T 80.69.77.43:443 -> 172.30.1.18:48975 [AP]
  HTTP/1.1 400 Bad Request..
  Server: nginx/1.7.1..
  Date: Mon, 27 Oct 2014 16:51:04 GMT..
  Content-Type: text/html..
  Content-Length: 270..
  Connection: close....
  <html>..<head><title>
  400 The plain HTTP request was sent to HTTPS port
  </title></head>.....

That looks to me like the packaging system is forgetting that the
package source is HTTPS when it downloads the target package and is
sending the request as HTTP.


Is this a regression? Yes. Doing exactly the same thing with my 24.3
install works fine.

The packaging system had extensive changes of course, related to the
internals of it's API. You may remember I remarked at the time about how
frustrating it was.


Why is this a big deal? I can just tell people to use HTTP can't I? Why
yes. Of course I can. In fact, now I have to.

But that's very sad. We should be encouraging users (and package
archives) to use HTTPS where possible, shouldn't we?


Probably the response to this will be "implement package signing".


Nic
reply via email to
[Prev in Thread] Current Thread [Next in Thread]