Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 00A0990D9 for ; Wed, 22 Feb 2012 19:48:19 +0000 (UTC) Received: (qmail 87310 invoked by uid 500); 22 Feb 2012 19:48:18 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 87276 invoked by uid 500); 22 Feb 2012 19:48:18 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 87268 invoked by uid 99); 22 Feb 2012 19:48:18 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 22 Feb 2012 19:48:18 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of paul.joseph.davis@gmail.com designates 209.85.220.180 as permitted sender) Received: from [209.85.220.180] (HELO mail-vx0-f180.google.com) (209.85.220.180) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 22 Feb 2012 19:48:12 +0000 Received: by vcbfo1 with SMTP id fo1so461206vcb.11 for ; Wed, 22 Feb 2012 11:47:51 -0800 (PST) Received-SPF: pass (google.com: domain of paul.joseph.davis@gmail.com designates 10.52.91.193 as permitted sender) client-ip=10.52.91.193; Authentication-Results: mr.google.com; spf=pass (google.com: domain of paul.joseph.davis@gmail.com designates 10.52.91.193 as permitted sender) smtp.mail=paul.joseph.davis@gmail.com; dkim=pass header.i=paul.joseph.davis@gmail.com Received: from mr.google.com ([10.52.91.193]) by 10.52.91.193 with SMTP id cg1mr3464832vdb.21.1329940071304 (num_hops = 1); Wed, 22 Feb 2012 11:47:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=fovhhRfWX1cEqMpeYY6HzeE6cT8+FXJXWzm0N9Ov9+A=; b=HDuwAgcjyuVh/Ax7q4/CSGAp78TcNjYxw/f+Jw1kkX1GtdSRJq8nV5rBQYUXrFnoPd A97yKezbYxhgqfpn+/G/qMzxef9eXgfCkb2/FsGZ2b6UyXzjC5vMmGzkUPjhk1rS9beZ hYK9/DRUo+Zl9A8hqlhj4xK4Dgs3lHidPC3uo= Received: by 10.52.91.193 with SMTP id cg1mr2911343vdb.21.1329940071242; Wed, 22 Feb 2012 11:47:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.218.132 with HTTP; Wed, 22 Feb 2012 11:47:11 -0800 (PST) In-Reply-To: References: <1FE932A3-8DF7-4B8A-9E88-448FBA671F8F@apache.org> <53080A6A-93C2-478F-B739-BBF7A3634C07@apache.org> <23D481E8-3F4E-4DF2-9818-935BB3FDA2F1@apache.org> From: Paul Davis Date: Wed, 22 Feb 2012 13:47:11 -0600 Message-ID: Subject: Re: Issues blocking the 1.2.0 release To: dev@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org JSON patch is committed: http://git-wip-us.apache.org/repos/asf?p=3Dcouchdb.git;a=3Dcommitdiff;h=3Db= a271a70b83c6df16af43204c2ba9f4d5ca89711 On Wed, Feb 22, 2012 at 12:39 AM, Filipe David Manana wrote: > I think COUCHDB-1413 wouldn't hurt to have for 1.2.0, after all it's > about correct query results. 1.2.1 is also aceptable. > If no objections, I'll push the fix to 1.2.x as well. > > On Tue, Feb 21, 2012 at 6:32 PM, Jason Smith wrote: >> My reading of the JIRA ticket (FWIW) is that Paul explained pretty >> convincingly why this is only a minor bug if at all. For this release, >> Paul had a simple fix; although I do not see it in 1.2.x nor JIRA and >> don't recall offhand what it was exactly. >> >> On Tue, Feb 21, 2012 at 10:50 PM, Robert Newson wro= te: >>> heh, actually I don't think we did. >>> >>> On 21 February 2012 22:41, Paul Davis wro= te: >>>> Did we fix the original JSON thing that started this whole broughaha? >>>> >>>> On Tue, Feb 21, 2012 at 3:57 PM, Noah Slater wr= ote: >>>>> Thanks. >>>>> >>>>> On Tue, Feb 21, 2012 at 9:46 PM, Jan Lehnardt wrote: >>>>> >>>>>> On 21.02.2012, at 22:38, Robert Newson wrote: >>>>>> >>>>>> > I resolved the ipv6 ticket as 'cannot reproduce' given that two >>>>>> > committers have verified ipv6 replication with 1.2.x. Time for rou= nd >>>>>> > 2? >>>>>> >>>>>> +1 >>>>>> >>>>>> >>>>>> > >>>>>> > On 21 February 2012 21:11, Noah Slater wrot= e: >>>>>> >> Are we blocked on anything else? Are we good to go? >>>>>> >> >>>>>> >> On Tue, Feb 21, 2012 at 7:21 PM, Jan Lehnardt wr= ote: >>>>>> >> >>>>>> >>> Thanks guys, committed. >>>>>> >>> >>>>>> >>> Noah, 1.2.0 is unblocked on this one. >>>>>> >>> >>>>>> >>> On Feb 21, 2012, at 20:13 , Paul Davis wrote: >>>>>> >>> >>>>>> >>>> +1 on the patch to require admin for _changes. >>>>>> >>>> >>>>>> >>>> On Tue, Feb 21, 2012 at 3:36 AM, Jan Lehnardt = wrote: >>>>>> >>>>> *nudge* >>>>>> >>>>> >>>>>> >>>>> I don't feel very confident with a single opinion (thanks Robe= rt), >>>>>> and >>>>>> >>> would love your input on this one. >>>>>> >>>>> >>>>>> >>>>> Cheers >>>>>> >>>>> Jan >>>>>> >>>>> -- >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> On Feb 16, 2012, at 16:12 , Jan Lehnardt wrote: >>>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Feb 14, 2012, at 13:14 , Noah Slater wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Devs, >>>>>> >>>>>>> >>>>>> >>>>>>> Please outline: >>>>>> >>>>>>> >>>>>> >>>>>>> =A0- What remains to be fixed for regression purposes >>>>>> >>>>>> >>>>>> >>>>>> I want to bring up one more thing (sorry :). >>>>>> >>>>>> >>>>>> >>>>>> /_users/_changes is currently end-user readable. While >>>>>> >>> /_users/_changes?include_docs=3Dtrue will not fetch docs the req= uesting >>>>>> user >>>>>> >>> doesn't have access to, it still gets all doc ids in the /_users= db and >>>>>> >>> thus easily can generate a list of all users. >>>>>> >>>>>> >>>>>> >>>>>> I'd like to propose to make /_user/_changes also admin-only b= efore >>>>>> we >>>>>> >>> ship 1.2.0. Again, I'm happy to revisit and make things configur= able >>>>>> down >>>>>> >>> the road. >>>>>> >>>>>> >>>>>> >>>>>> Note that the information that a particular user is registere= d is >>>>>> >>> leaked (a user can't sign up with a username that is already tak= en, >>>>>> from >>>>>> >>> that it can be deduced that that particular username is already >>>>>> >>> registered). This is in line with most signup systems. Making >>>>>> >>> /_users/_changes admin-only doesn't prevent all leakage of what = users >>>>>> have >>>>>> >>> signed up, but it stops bulk-leakage of *all* users in one swoop= . >>>>>> >>>>>> >>>>>> >>>>>> What do you think? >>>>>> >>>>>> >>>>>> >>>>>> Cheers >>>>>> >>>>>> Jan >>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>>> >>> >>>>>> >>> >>>>>> >> >> >> >> -- >> Iris Couch > > > > -- > Filipe David Manana, > > "Reasonable men adapt themselves to the world. > =A0Unreasonable men adapt the world to themselves. > =A0That's why all progress depends on unreasonable men."