couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: Issues blocking the 1.2.0 release
Date Tue, 21 Feb 2012 21:46:49 GMT
On 21.02.2012, at 22:38, Robert Newson <rnewson@apache.org> 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 <nslater@tumbolia.org> wrote:
>> Are we blocked on anything else? Are we good to go?
>> 
>> On Tue, Feb 21, 2012 at 7:21 PM, Jan Lehnardt <jan@apache.org> 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 <jan@apache.org> 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
>>>>>> --
>>>>>> 
>>>>>> 
>>>>> 
>>> 
>>> 

Mime
View raw message