CouchDB needs to properly enable SSL support

Upstream has fixed this in the 0.10.x release branch, preparing a new snapshot package now.

This bug was fixed in the package couchdb - 0.10.0~svn813472-0ubuntu1

---------------
couchdb (0.10.0~svn813472-0ubuntu1) karmic; urgency=low

  * New snapshot of couchdb 0.10.x stable prerelease branch
    - pass config reset option to recursed background startup (LP: #424330)
      closes COUCHDB-498
    - Fix for building on snow leopard COUCHDB-490
    - Fix SSL replication (LP: #422178) COUCHDB-491
    - Fix continuous-after-normal replication
    - Use the same password hash calculation for user creation via ini
      file and user db, closes COUCHDB-492
    - Fix for WebKit XHR, closes COUCHDB-483
    - Don't check for response code text, closes COUCHDB-482
    - Remove a debugging leftover

 -- Elliot Murphy <email address hidden> Thu, 10 Sep 2009 11:35:54 -0400

Actually, I think this was mistakenly marked as fix. We used a workaround on our servers to force clients to use non-streaming replication, but this is no longer available in couchdb 1.0+. I do not know why upstream marked the problem as fixed, since the behavior seems exactly the same in 1.0.1 as it was in 0.9.

lp:~pedronis/ubuntuone-servers/local-replication-testing contain a script to test desktopcouch to cloud couch replication locally

The ubuntuone-server branch attached above demonstrates the problem. As well as the attached script, when run as follows:

ubuntuone-couchdb-replicate staging contacts to desktopcouch

(where contacts can be replaced by any of the users' databases.)

We have a package with fixes from couch.io that makes the above test work here:

https://launchpad.net/~ubuntuone/+archive/hackers/+sourcepub/1295911/+listing-archive-extra

Oops, please ignore, that one was mistakenly built for lucid.

The correct package is here:

https://launchpad.net/~ubuntuone/+archive/hackers/+sourcepub/1295934/+listing-archive-extra

This bug was fixed in the package couchdb - 1.0.1-0ubuntu3

---------------
couchdb (1.0.1-0ubuntu3) maverick; urgency=low

  * Patchset from CouchIO to fix U1 replication over SSL (LP: #422178)
    - couchio-fix-0001-replicator_redirect_atts.patch
    - couchio-fix-0002-replicator_db_proxy_fix.patch
    - couchio-fix-0003-changes_redirect_1.patch
    - couchio-fix-0004-changes_redirect_2.patch
    - couchio-fix-0005-changes_proxy.patch
    - couchio-fix-0006-replicator_reader_errors.patch
    - couchio-fix-0007-ibrowse_upgrade.patch
    - couchio-fix-0008-replicator_doc_id_encoding.patch
    - couchio-fix-0009-replicator_changes_error.patch
    - couchio-fix-0010-replicator_changes_connection_close.patch
    - couchio-fix-0011-ibrowse_chunked_encoding_streaming.patch
    - couchio-fix-0012-replicator_ssl.patch [fixed up]
 -- Samuele Pedroni <email address hidden> Fri, 24 Sep 2010 14:53:26 -0400

Samuele or Eric, please attach information on test cases for this to be verified on Karmic and Lucid.

The uploaded package is a backport from maverick, which introduces a lot of new upstream versions and jumps from 0.10.1 to 1.0.1. This is not at all what an SRU is supposed to do. Can we please just backport the SSL fix?

.. and even if this was acceptable, if an upload introduces more than just the last changelog record, it needs to be built with -v<version in lucid/-updates/-security>. Rejecting upload.

Attached a tarball, that when unzipped allows for testing of OAuth authenticated push and pull replication over SSL.

To use, extract the tarball, enter the directory that it creates, and then run:

make test

(it needs apache installed, as that handles the SSL part of the equation.)

The output should contain something like this:

[...]
pushed the expected 100 docs to the cloud test_db: True
increased update_seq by 100 pushing docs to the cloud test_db: True
[...]
pulled the expected 100 docs to the desktop test_db2: True
increased update_seq by 100 pulling docs to the desktop test_db2: True
[...]

where the important information is the 'True' values.

If any of these 4 lines shows False, the test failed.

(unsubscribing ubuntu-release to get it off the list. Fixed already in maverick.)

So we Lucid users are waiting for weeks an update jet ready for Maverick. But Lucid isn't a LTS?

LTS doesn't mean faster updates...

@luca I think the Lucid update is an SRU and as such will have to undergo a crap load of testing, which is a good thing.

Karmic has long since stopped to receive any updates. Marking the Karmic task for this ticket as "Won't Fix".

lucid has seen the end of its life and is no longer receiving any updates. Marking the lucid task for this ticket as "Won't Fix".