databases/couchdb: add CVE-2018-11769 for versions < 2.2.0

[jrm]

security/vuxml/vuln.xml

66

Do we have issues here with PORTEPOCH (and with vid=1e54d140-8493-11e8-a795-0028f8d09152)? I did some testing with pkg audit -f /usr/ports/security/vuxml/vuln.xml couchdb-x.x.

pkg audit -f /usr/ports/security/vuxml/vuln.xml couchdb-1.7.2,2
0 problem(s) in the installed packages found.

pkg audit -f /usr/ports/security/vuxml/vuln.xml couchdb-1.7.1,2
0 problem(s) in the installed packages found.

Do we want <le>1.7.2,2</le> here and <lt>1.7.2,2</lt> for vid=1e54d140-8493-11e8-a795-0028f8d09152 ?

[dch]

Doing pkg audit -f /usr/ports/security/vuxml/vuln.xml when couchdb is installed doesn't work due to epoch as you mentioned, so I also need to fix this in
(mea culpa) VID 1e54d140-8493-11e8-a795-0028f8d09152 from https://svnweb.freebsd.org/ports?view=revision&revision=474445 as well.

security/vuxml/vuln.xml

66

woops, thanks! That's not what I expected. I've been using the simplistic check to confirm I get expected output, but I need to check that the vuxml entry is not shown for the fictional next release to catch this next time.

[dch]

amend vuxml entries with missing EPOCH

[jrm]

security/vuxml/vuln.xml

66

Will there be future 1.x releases? Will you eventually remove databases/couchdb2 and upgrade database/couchdb to 2.x?

[dch]

security/vuxml/vuln.xml

66

good question.

future 1.x releases? -> extremely unlikely.
rename couchdb2 -> couchdb? personally no, notes below.

I'm not sure what makes most sense from ports@ policy, but here's what I had in mind, but haven't discussed in the couch community yet:

phase 1:

• release the couchdb2 port
• add a MOVED or UPDATED notification to ports tree pointing people how to migrate
• commit a work-around for the latest CVE that mitigates the impact for 1.7.x users

phase 2:

• given a few months across quarterly ports branches, for people who *choose* to migrate to do so without disruption and not needing to rename their devops stuff
• rename databases/couchdb to databases/couchdb17
• sprinkle DEPRECATION warnings whereever we do that sort of thing in ports

maybe phase 3?

• when couchdb3 arrives (2020 probably) we'll have a bunch of deprecations that matter, long overdue api changes. So that's a good time to either add databases/couchdb3 or add it as databases/couchb. IDK. Personally I feel having databases/couchdb[123] with mildly differing APIs is the nicest arrangement for sysadmins.

my reasoning:

• there's no direct migration path (no "move db files from A to B and restart) so people need to install 1.x and 2.x side by side, and replicate over HTTP to migrate.
• We (Apache CouchDB PMC) decided to move the 1.7.x line off support as we've had 2.x for a couple of years at least now.
• The functionality that adds clustering in 2.x also drops a small set of things that some people really want/need (I have 1 customer in this category for example) so I'd like at least to ensure that people who *really* want couchdb-17 can at least have it, and manage their own risks.

[jrm]

I am trying to make sense of the vuln entry with two different couchdb packages, couchdb-1.x.x,2 and couchdb2-2.x. Based on what you wrote, does <range><le>1.7.2,2</le></range> make more sense for the new entry, which I assume only applies to the couchdb-1.x.x,2 package?

[dch]

In D16820#358227, @jrm wrote:

I am trying to make sense of the vuln entry with two different couchdb packages, couchdb-1.x.x,2 and couchdb2-2.x. Based on what you wrote, does <range><le>1.7.2,2</le></range> make more sense for the new entry, which I assume only applies to the couchdb-1.x.x,2 package?

OK I see what you mean.

• 2.1.2 and lower is vulnerable, but 2.2.0 is not.
• 1.7.2 is vulnerable, and will not be patched as it's (long) out of support and we're not doing any more releases on the 1.x branches
• therefore 2.2.0 is the only version that is not vulnerable, and I'm not expecting any later patches to address < 2.2.0
• If at some future point, couchdb2 is renamed to databases/couchdb, the vulnerability list will still be correct

I don't see any other pattern that covers this other than < 2.2.0.

Of course any new vulnerabilities for 2.x series will need to be reported against that port only.

my poudriere box has finally caught up with rebuilding all the things so I'll have those in soon.