Fix __exit__ in contexts

The return value of __exit__ is used to determine if Python should
re-raise exceptions, False meaning 're-raise'.

The dangerous looking one is the one in StreamPadFileObj, where a
.close() that might somehow yield a non-False-ish return could cause
exceptions to be swallowed.

It doesn't seem likely that'd ever be the case, but the code as
written needlessly relies on that for correct behavior and obscures
the intent.

Backpatch this change to 0.5, too.
Move documentation about WALE_S3_INTEGRATION_TESTS

test_s3_worker is among the oldest of the tests and introduced the
WALE_S3_INTEGRATION_TESTS pattern.  Since then, it has enjoyed use in
other tests and its code has been factored out to another module, but
those tests do not document the convention.

So, instead move the advisory about that to that module and explain it
at a higher level.
Make WALE_S3_INTEGRATION_TESTS more sensitive

Instead of accepting any string as the affirmative, only accept
'TRUE'.

Previously, modifying WALE_S3_INTEGRATION_TESTS=FALSE to toggle
acceptance tests off would run them anyway, since 'FALSE' is an extant
string, which is all this used to care about.  That's confusing.
Fix crash when listing latest backup

A one-element list containing "None" was emitted rather than an empty
list.  Fix this bug and insert some assertions to make such defects
more perspicuous.

Exercise the crash with an integration test.
Fix double-formatting of UserExceptions

Previously, both the __str__ method of UserException would run the
exception through WalELogger.fmt_logline() and so would the
instance-method to WalELogger.log().  This resulted in output like:

    wal_e.main   ERROR    MSG: MSG: invalid backup query submitted
            DETAIL: The submitted query operator was "/tmp."
            STRUCTURED: time=2013-09-08T11:28:32.788848-00 pid=2130
            STRUCTURED: time=2013-09-08T11:28:32.788912-00 pid=2130

Where "MSG" appears twice and "STRUCTURED" appears twice.

The second level of formatting treated the first level as an opaque
string, which is why only "MSG" and "STRUCTURED" were repeated.
More robustly print multiple stored exceptions

This would die with a crash in event that a non-UserException was
propagated, because such exceptions won't have "msg", "detail", "hint"
fields, and so on.

Try to format things the normal way in event it's an expected sort of
exception, otherwise print the exception with its __str__ rendering.
Blacklist weak and slow cipher suites in TLS

Per the comments in cmd.py:

Instate a cipher suite that bans a series of weak and slow ciphers.
Both RC4 (weak) DES (weak and slow) have been seen with default cipher
suites on both Ubuntu Raring and Ubuntu Precise, respectively.

Only Python 2.7+ possesses the 'ciphers' keyword to wrap_socket.
Add gevent version to oldest-version tox environments

As a finding of that, gevent 0.13.0 does not work, so state the
reliance on 0.13.1.

gevent of the 0.13.0 vintage seems to crash when performing 'import
gevent', so it seems unlikely even a single such user relying on
0.13.0 exists.  I doubt amending this requirement would materially
hurt anyone, and may have never worked anyway.
Update requirements.txt to require gevent 0.13.1

This properly reflects the new standard set in
f685ae38e5ab590d68c5895883aeabd47c43dfbf, on discovering 0.13.0
probably never worked for anyone anyway after setting up tox.ini to
exercise this..

Conflicts:
	requirements.txt
Rename PipeViwerRateLimitFilter to PipeViewerRateLimitFilter

This was a typo.
Run tests on Travis CI
Add Timothée Peignier as a contributor
While transferring WAL ensure concurrent greenlets can clean up

There have been some reports that WAL-E can leave around temporary
files pathologically often.

This is because when an error is propagated to the main greenlet,
there's a good chance that it will exit the process before allowing
the other concurrent greenlets to clean up: instead, those greenlets
are abruptly terminated, and in doing with temporary files are leaked.

This bug probably exists elsewhere in WAL-E (e.g. base backups), but
the introduction of parallel WAL upload has rendered its effect
uniquely noticeable to date, probably because so many of
start-up-shut-down cycles of WAL-E are performed in a short period of
time, and each such cycle is an opportunity to leak these files given
an error condition.
Update cipher string and explain it with more detail

I don't think this makes a functional difference, but the intent
behind each component is now more clear.  These decisions were
informed by reading OpenSSL's s2_lib.c and s3_lib.c.

The express banning of DES has been lifted, because per the standard
DES is too weak a cipher to be in 'HIGH'.  The forbidding of 3DES,
which can have long enough keys to be in the 'HIGH' category, is still
explicitly forbidden for performance reasons.

SSLv2 has been expressly banned for lucidity sake, even though it is
not strictly necessary given "!3DES": thanks to accidents of history
the only 'HIGH'-class cipher suite present is based on 3DES.  Thus
'HIGH:[...]:!3DES' should be sufficient to the same meaning, but only
through a close reading of the availability of what's in SSLv2.

Also deny use of cipher suites using MD5.  It's not clear this can
mount a practical attack against a SSLv3 session, and seems even less
likely so in TLS v1.0+ since they use HMAC, where MD5 is thought to be
fine, but given that flavors of SHA are widely deployed and thought to
be stronger, it doesn't seem such a ban will be of predicable
practical consequence to compatibility.

At the time of writing, the cipher suites that OpenSSL will support
given these constraints are:

$ openssl version
OpenSSL 1.0.1c 10 May 2012

(Line breaks inserted for clarity below)

$ openssl ciphers 'HIGH:!aNULL:!SSLv2:!RC4:!3DES:!MD5'
ECDHE-RSA-AES256-GCM-SHA384:
ECDHE-ECDSA-AES256-GCM-SHA384:
ECDHE-RSA-AES256-SHA384:
ECDHE-ECDSA-AES256-SHA384:
ECDHE-RSA-AES256-SHA:
ECDHE-ECDSA-AES256-SHA:
SRP-DSS-AES-256-CBC-SHA:
SRP-RSA-AES-256-CBC-SHA:
DHE-DSS-AES256-GCM-SHA384:
DHE-RSA-AES256-GCM-SHA384:
DHE-RSA-AES256-SHA256:
DHE-DSS-AES256-SHA256:
DHE-RSA-AES256-SHA:
DHE-DSS-AES256-SHA:
DHE-RSA-CAMELLIA256-SHA:
DHE-DSS-CAMELLIA256-SHA:
ECDH-RSA-AES256-GCM-SHA384:
ECDH-ECDSA-AES256-GCM-SHA384:
ECDH-RSA-AES256-SHA384:
ECDH-ECDSA-AES256-SHA384:
ECDH-RSA-AES256-SHA:
ECDH-ECDSA-AES256-SHA:
AES256-GCM-SHA384:
AES256-SHA256:
AES256-SHA:
CAMELLIA256-SHA:
PSK-AES256-CBC-SHA:
ECDHE-RSA-AES128-GCM-SHA256:
ECDHE-ECDSA-AES128-GCM-SHA256:
ECDHE-RSA-AES128-SHA256:
ECDHE-ECDSA-AES128-SHA256:
ECDHE-RSA-AES128-SHA:
ECDHE-ECDSA-AES128-SHA:
SRP-DSS-AES-128-CBC-SHA:
SRP-RSA-AES-128-CBC-SHA:
DHE-DSS-AES128-GCM-SHA256:
DHE-RSA-AES128-GCM-SHA256:
DHE-RSA-AES128-SHA256:
DHE-DSS-AES128-SHA256:
DHE-RSA-AES128-SHA:
DHE-DSS-AES128-SHA:
DHE-RSA-CAMELLIA128-SHA:
DHE-DSS-CAMELLIA128-SHA:
ECDH-RSA-AES128-GCM-SHA256:
ECDH-ECDSA-AES128-GCM-SHA256:
ECDH-RSA-AES128-SHA256:
ECDH-ECDSA-AES128-SHA256:
ECDH-RSA-AES128-SHA:
ECDH-ECDSA-AES128-SHA:
AES128-GCM-SHA256:
AES128-SHA256:
AES128-SHA:
CAMELLIA128-SHA:
PSK-AES128-CBC-SHA
Shorten cipher string documentation

This information is maybe not quite correct (the cause of selection of
a cipher suite by S3 is a little mysterious) and flat out wrong when
it comes to the use of DES: 3DES is used, even if it is sometimes
rendered as DES with a long key.
Change the expected result of a call to ls

The format is slightly different on OSX
Merge pull request #39 from alex/osx

Change the expected result of a call to ls
Add Alex Gaynor as a contributor
Implement --terse option

Defined as suppressing logs of level INFO and below.

Altered from original '--quiet' patch with additional hacking from
Daniel Farina <daniel@heroku.com>.
Add Christophe Pettus as a contributor