From dev-return-20804-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Tue Feb 21 21:45:12 2012 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 E87E79C99 for ; Tue, 21 Feb 2012 21:45:11 +0000 (UTC) Received: (qmail 77815 invoked by uid 500); 21 Feb 2012 21:45:11 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 77766 invoked by uid 500); 21 Feb 2012 21:45:11 -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 77758 invoked by uid 99); 21 Feb 2012 21:45:11 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 21 Feb 2012 21:45:11 +0000 X-ASF-Spam-Status: No, hits=0.7 required=5.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [80.244.253.218] (HELO mail.traeumt.net) (80.244.253.218) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 21 Feb 2012 21:45:03 +0000 Received: from [192.168.0.197] (91-64-56-102-dynip.superkabel.de [91.64.56.102]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.traeumt.net (Postfix) with ESMTPSA id D4D083CE76 for ; Tue, 21 Feb 2012 22:44:42 +0100 (CET) Subject: Re: Issues blocking the 1.2.0 release References: <1FE932A3-8DF7-4B8A-9E88-448FBA671F8F@apache.org> <53080A6A-93C2-478F-B739-BBF7A3634C07@apache.org> <23D481E8-3F4E-4DF2-9818-935BB3FDA2F1@apache.org> From: Jan Lehnardt Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (9A405) In-Reply-To: Message-Id: Date: Tue, 21 Feb 2012 22:46:49 +0100 To: "dev@couchdb.apache.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) X-Virus-Checked: Checked by ClamAV on apache.org 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 round > 2? +1 >=20 > On 21 February 2012 21:11, Noah Slater wrote: >> Are we blocked on anything else? Are we good to go? >>=20 >> On Tue, Feb 21, 2012 at 7:21 PM, Jan Lehnardt wrote: >>=20 >>> Thanks guys, committed. >>>=20 >>> Noah, 1.2.0 is unblocked on this one. >>>=20 >>> On Feb 21, 2012, at 20:13 , Paul Davis wrote: >>>=20 >>>> +1 on the patch to require admin for _changes. >>>>=20 >>>> On Tue, Feb 21, 2012 at 3:36 AM, Jan Lehnardt wrote: >>>>> *nudge* >>>>>=20 >>>>> I don't feel very confident with a single opinion (thanks Robert), and= >>> would love your input on this one. >>>>>=20 >>>>> Cheers >>>>> Jan >>>>> -- >>>>>=20 >>>>>=20 >>>>> On Feb 16, 2012, at 16:12 , Jan Lehnardt wrote: >>>>>=20 >>>>>>=20 >>>>>> On Feb 14, 2012, at 13:14 , Noah Slater wrote: >>>>>>=20 >>>>>>> Devs, >>>>>>>=20 >>>>>>> Please outline: >>>>>>>=20 >>>>>>> - What remains to be fixed for regression purposes >>>>>>=20 >>>>>> I want to bring up one more thing (sorry :). >>>>>>=20 >>>>>> /_users/_changes is currently end-user readable. While >>> /_users/_changes?include_docs=3Dtrue will not fetch docs the requesting u= ser >>> 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. >>>>>>=20 >>>>>> I'd like to propose to make /_user/_changes also admin-only before we= >>> ship 1.2.0. Again, I'm happy to revisit and make things configurable dow= n >>> the road. >>>>>>=20 >>>>>> Note that the information that a particular user is registered is >>> leaked (a user can't sign up with a username that is already taken, 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 ha= ve >>> signed up, but it stops bulk-leakage of *all* users in one swoop. >>>>>>=20 >>>>>> What do you think? >>>>>>=20 >>>>>> Cheers >>>>>> Jan >>>>>> -- >>>>>>=20 >>>>>>=20 >>>>>=20 >>>=20 >>>=20