couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@tumbolia.org>
Subject Re: Issues blocking the 1.2.0 release
Date Tue, 21 Feb 2012 21:57:13 GMT
Thanks.

On Tue, Feb 21, 2012 at 9:46 PM, Jan Lehnardt <jan@apache.org> wrote:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message