heh, actually I don't think we did.
On 21 February 2012 22:41, Paul Davis <[email protected]> wrote: > Did we fix the original JSON thing that started this whole broughaha? > > On Tue, Feb 21, 2012 at 3:57 PM, Noah Slater <[email protected]> wrote: >> Thanks. >> >> On Tue, Feb 21, 2012 at 9:46 PM, Jan Lehnardt <[email protected]> wrote: >> >>> On 21.02.2012, at 22:38, Robert Newson <[email protected]> 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 >>> >>> >>> > >>> > On 21 February 2012 21:11, Noah Slater <[email protected]> wrote: >>> >> Are we blocked on anything else? Are we good to go? >>> >> >>> >> On Tue, Feb 21, 2012 at 7:21 PM, Jan Lehnardt <[email protected]> wrote: >>> >> >>> >>> 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 <[email protected]> wrote: >>> >>>>> *nudge* >>> >>>>> >>> >>>>> I don't feel very confident with a single opinion (thanks Robert), >>> 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: >>> >>>>>>> >>> >>>>>>> - 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=true will not fetch docs the requesting >>> 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 before >>> we >>> >>> ship 1.2.0. Again, I'm happy to revisit and make things configurable >>> down >>> >>> the road. >>> >>>>>> >>> >>>>>> 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 >>> have >>> >>> signed up, but it stops bulk-leakage of *all* users in one swoop. >>> >>>>>> >>> >>>>>> What do you think? >>> >>>>>> >>> >>>>>> Cheers >>> >>>>>> Jan >>> >>>>>> -- >>> >>>>>> >>> >>>>>> >>> >>>>> >>> >>> >>> >>> >>>
