couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <rnew...@apache.org>
Subject Re: Issues blocking the 1.2.0 release
Date Tue, 21 Feb 2012 21:38:27 GMT
I resolved the ipv6 ticket as 'cannot reproduce' given that two
committers have verified ipv6 replication with 1.2.x. Time for round
2?

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