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 Mon, 20 Feb 2012 16:45:38 GMT
Nudge. Where do we stand with this.

Is anyone currently working on COUCHDB-665?

Has anyone reviewed or merged in Jan's patch?

On Thu, Feb 16, 2012 at 10:44 PM, Randall Leeds <randall.leeds@gmail.com>wrote:

> Also blocking 1.2:
> https://issues.apache.org/jira/browse/COUCHDB-665
>
> On Thu, Feb 16, 2012 at 07:40, Jan Lehnardt <jan@apache.org> wrote:
> >
> > 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?
> >
> > And a patch & tests for your consideration:
> https://github.com/janl/couchdb/commit/a61a2068a9ff8c1b9c7dc3596a999a6e164c0d42
> >
> > Cheers
> > Jan
> > --
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message