#651143 dropbox doesn't verify the HTTP return code when downloading the binaries

Package:
nautilus-dropbox
Source:
nautilus-dropbox
Submitter:
Teemu Ikonen
Date:
2011-12-29 07:21:03 UTC
Severity:
important
#651143#5
Date:
2011-12-05 13:42:08 UTC
From:
To:
Installation of dropboxd fails:

$ dropbox start -i
Starting Dropbox...
Dropbox is the easiest way to share and store your files online. Want
to learn more? Head to http:/
/www.dropbox.com/

Downloading Dropbox... 100%
Traceback (most recent call last):
  File "/usr/bin/dropbox", line 1372, in <module>
    ret = main(sys.argv)
  File "/usr/bin/dropbox", line 1361, in main
    result = commands[argv[i]](argv[i+1:])
  File "/usr/bin/dropbox", line 805, in update
    download()
  File "/usr/bin/dropbox", line 544, in download
    name, i, total = one_member.next()
  File "/usr/bin/dropbox", line 267, in unpack
    if not verify_signature(StringIO.StringIO(DROPBOX_PUBLIC_KEY),
signature, self.local_file):
  File "/usr/bin/dropbox", line 201, in verify_signature
    sigs = ctx.verify(sig_file, plain_file, None)
gpgme.GpgmeError: (7, 58, u'No data')
The installation of Dropbox failed.


Best,

Teemu
#651143#10
Date:
2011-12-05 16:01:57 UTC
From:
To:
Hello,

That's probably the sign that the download of the signature failed for
some unknown reason.

Do you have to use a proxy to access the internet? If yes, do you have
correctly configured the http_proxy environment variable?

It's true however that pkexec does filter environment variables so the
problem could well be here.

Does "dropbox update" work if you run it in a root shell where http_proxy
is correctly configured?

Cheers,
#651143#15
Date:
2011-12-05 17:19:16 UTC
From:
To:
Hello,

Thanks for the quick reply, indeed the problem was that I could not
connect to dropbox.com without a proxy. The downloader could perhaps
give a more informative error message in this case, but the problem
was not really there, so I'm closing this bug.

Best,

Teemu
#651143#20
Date:
2011-12-05 17:55:46 UTC
From:
To:
How did you fix your problem ?

Because as I said if you run "dropbox start -i" as a user and have to
install dropbox, it will use pkexec to run "dropbox update" as root and
then the http_proxy environment variable is lost and things should break.

So I think that you possibly closed this bug too quickly. :)

Cheers,
#651143#25
Date:
2011-12-05 18:11:09 UTC
From:
To:
I ran dropbox start -i under tsocks, i.e. a SOCKS proxy, and the
dropbox client download succeeded. The client can also be configured
to use a SOCKS proxy from the GUI, so syncing now works also.

Setting a working http_proxy and running under root would have
probably worked as well, but SOCKS was easier to set up now.

Best,

Teemu
#651143#30
Date:
2011-12-05 20:23:31 UTC
From:
To:
It's weird because tsocks uses LD_PRELOAD to override the system calls
but that variable is not kept by pkexec and pkexec is a setuid program
so even ld.so should not accept to pre-load the tsocks library.

Looking further I see that the message you pasted says “Downloading
Dropbox... 100%” so the download actually worked but only the
download of the signature failed (or worked but returned nothing).

Not sure how to explain that. Maybe a transient problem somewhere in the
chain.

Cheers,
#651143#35
Date:
2011-12-05 20:33:51 UTC
From:
To:
Hi Raphael,

I ran 'tsocks dropbox update' as root, so pkexec was probably not involved.

The failure was instantaneous, so the client was not downloaded. The
downloader script probably mistook the '403 forbidden' message as a
success.

Best,

Teemu
#651143#40
Date:
2011-12-06 07:27:09 UTC
From:
To:
reopen 651065
retitle 651065 'dropbox start -i' doesn't respect http_proxy as expected
severity 651065 important
clone 651065 -1
retitle -1 dropbox doesn't verify the HTTP return code when downloading the binaries
thanks

Right. So we probably still have the problem that I described.

Indeed, you're right. Yet another bug in the implementation... that also
explains why I have seen many errors where the failure involved the lack
of a Content-Length field in the answer. Probably a proxy that did not put
this field in its answer...

Cloning into a new bug for this one.

Cheers,
#651143#57
Date:
2011-12-28 09:38:16 UTC
From:
To:
Hello Rian & David,

while investigating a user problem we noticed that the wrapper doesn't
check the HTTP return code. Thus the program continues and usually fails
later during the GPG verification with an error messages that is very
difficult to understand for the end user (see
http://bugs.debian.org/651143 or
https://bugs.launchpad.net/ubuntu/+source/nautilus-dropbox/+bug/905223).
It can also fail sooner if the answer is lacking a Content-Length field
since you're trying to use that field even if it's not here (which in turn
leads to failures like those here:
https://bugs.launchpad.net/ubuntu/+source/nautilus-dropbox/+bug/846871).

In particular, if a proxy answers with 403 forbidden or something similar,
you should really fail early with an error message that better explains
the real underlying problem.

Cheers,