Re: [ANNOUNCE] Nolan Lawson elected as CouchDB committer

[Robert Newson]

'Bout time. Condragulations! 

> On 19 Apr 2016, at 17:43, Johannes Jörg Schmidt  wrote:
> 
> Congratulations Nolan! \o/
> 
>> On 19.04.2016 18:19, Joan Touzet wrote:
>> Congrats, Nolan!
>> 
>> - Original Message -
>>> From: "Robert Kowalski" 
>>> To: dev@couchdb.apache.org
>>> Sent: Tuesday, April 19, 2016 12:04:22 PM
>>> Subject: Re: [ANNOUNCE] Nolan Lawson elected as CouchDB committer
>>> 
>>> Whohoo, congrats Nolan! :)
>>> 
>>> On Tue, Apr 19, 2016 at 5:21 PM, Darío Cravero 
>>> wrote:
 Congrats Nolan!! :)
 
 On Tue, Apr 19, 2016 at 3:49 PM Nolan Lawson
  wrote:
 
> Thanks, Jan and Garren!! I'm happy to join up with such a fine and
> welcoming community. :) Here's to a great 2016 for CouchDB!
> 
> Cheers,
> Nolan
> 
> On Tue, Apr 19, 2016 at 10:46 AM, Jan Lehnardt 
> wrote:
> 
>> Woohoo contrats and welcome Nolan :)
>> 
>> Best
>> Jan
>> --
>>> On 19 Apr 2016, at 16:43, Garren Smith 
>>> wrote:
>>> 
>>> Dear community,
>>> 
>>> I am pleased to announce that the CouchDB Project Management
>>> Committee
>>> has elected Nolan Lawson as a CouchDB committer.
>>> 
>>>   Apache ID: nolan
>>> 
>>>   IRC nick: nolanlawson
>>> 
>>>   Twitter: @nolanlawson
>>> 
>>> Committers are given a binding vote in certain project
>>> decisions, as
>>> well as write access to public project infrastructure.
>>> 
>>> This election was made in recognition of Nolan's commitment to
>>> the
>>> project. We mean this in the sense of being loyal to the
>>> project and
>>> its interests.
>>> 
>>> Please join me in extending a warm welcome to Nolan!
>>> 
>>> On behalf of the CouchDB PMC,
>>> 
>>> Cheers
>>> 
>>> Garren
>> 
>> --
>> Professional Support for Apache CouchDB:
>> https://neighbourhood.ie/couchdb-support/
> 
> 
> --
> Nolan Lawson
> nolanlawson.com
> github.com/nolanlawson
> 

Re: On dependency management and CI issues associated with it

[Alexander Shorin]

On Tue, Apr 19, 2016 at 11:26 PM, Ilya Khlopotov  wrote:
>
> Thank you for you feedback and great discussion. It looks like I am the only 
> one who prefer multi-repo model (with tools assistance).

You're not alone, actually, but it's hard to fight with reality now. I
think we all agreed that multi-repo is good, but at some point of
decomposition all the profits get covered by growing number of
problems: infrastructure, tools, learning curve, workflow.

Actually, I did a notice to myself to look into how other projects has
same repos model and how they deal with it. I don't think we're unique
on this problem.

If we'll get the good solution for most of our current issues, we can
stay with what we have. I don't think there is somebody who would love
to fold the repos preserving history and else bits. But so far...

--
,,,^..^,,,

Re: On dependency management and CI issues associated with it

[Ilya Khlopotov]

Hey all,

Thank you for you feedback and great discussion. It looks like I am the
only one who prefer multi-repo model (with tools assistance).

BR,
ILYA



From:   Jan Lehnardt 
To: dev@couchdb.apache.org
Date:   2016/04/15 01:39 AM
Subject:Re: On dependency management and CI issues associated with it



Hey all, love the discussion! :)

I’ve identified these issues in this thread:

1. multi-repo vs. mono-repo
 - with the sub-issues of how mono the repo should be
 - and how to get tooling and process going specifically

2. keeping safe copies of upstream dependencies to avoid left-padding
 - with the sub-issue of not being able to do this for every single one
   because of licensing.

Let’s try to keep those separate :)


* * * Summary

As for 1, I think we have a rough consensus about going back to some form
of mono-repo. I don’t think anyone disagrees with keeping fauxton and the
docs in separate repos as well, same with nano and nmo, essentially
everything “non-core Erlang”.

The open question then is do we bundle *everything* else together,
including
the Erlang apps that are usable standalone as outlined by Paul, or fold
them
in. I think we have to further separate these by “developed by us” and
“forks
from upstream“ like mochiweb, ibrowse and jiffy (although, nice overlap
here :).

2. we should be discussing. Which deps are we afraid of going away, what
should
our policy be, etc? But let’s spin this out in a new thread. If you want to
reply to this, please choose a new Subject line.


* * * Opinion

From a “this sounds neat”-perspective, I’d prefer these three tiers:

1. one repo for all ASF-developed CouchDB bits that are not reasonably
different
   Erlang apps (couch-replicator, chttpd, etc)*
2. one repo each for ASF-developed CouchDB bits that are reasonably used in
   other projects (khash, b64url, snappy, etc)
3. one repo each for upstream forks.

* although they should continue to be separated in src/subdirs, and not all
in
src/couchdb as we did in 1.x.

My assumption is that category 2 deps are usually not the ones causing
trouble
in today’s development flow (please correct me if I’m wrong).

And I don’t know if development tooling gets any easier if we keep some
things
separate and others not, but if at all possible, I think the above is the
most
sensible.

I don’t have too much experience with git subtree, but the docs are surely
not beginner friendly, but I’m sure with a nice dev guide, we should be
able
to follow along.

Best
Jan
--


> On 13 Apr 2016, at 19:42, Robert Newson  wrote:
>
> As for the separation we have enforcing good practices, I don't buy it.
>
> I don't think it will be difficult to prevent the kind of coupling you
(and I) would find troubling.  It might even be easier to see if a single
commit touches multiple src/ subdirectories that might be missed when
reviewing separate pr's. At least, I'm not sure I could slide a credit card
between them.
>
>> On 13 Apr 2016, at 17:44, Adam Kocoloski  wrote:
>>
>>
>>> On Apr 13, 2016, at 12:30 PM, Alexander Shorin 
wrote:
>>>
>>> Hi Paul!
>>>
>>> Thanks for great input!
>>>
 On Wed, Apr 13, 2016 at 7:11 PM, Paul Davis
 wrote:
 If anyone has a strong objection to a monolithic Erlang repo I'd like
 to hear it. Otherwise I may work up a lengthier and more thorough
 proposal for dev@ to consider consolidating all of these repositories
 for sanity and profit.
>>>
>>> It's hard to object against that since this actually solves a lot of
>>> problems solution of which will require more work to do and still will
>>> leave a place for mistakes or require quite specific toolchain to
>>> work.
>>>
>>> Making our current repos design work right will require even more work
to apply.
>>>
>>> So, for point of time/resources/usability there is no much choice.
>>>
>>> I think folding the "Erlang repos developed by ASF" list will solve
>>> most part of the problems. However, I think it worth to keep these
>>> apps in own repos:
>>> - rexi
>>> - b64url
>>> - config
>>> - snappy
>>> - khash
>>> - ets-lru
>>> - twig (why we still need it?)
>>>
>>> As they could be reused outside and they shouldn't involve any
>>> dependencies with other couch modules by design. Everyone else may
>>> stand on where they are.
>>>
>>> P.S. I'm not sure if git-subtree will not introduce more new problems
>>> as it's quite tricky thing to live with it.
>>>
>>> --
>>> ,,,^..^,,,
>>
>> +1 Alex. I disagree that “one Erlang repo” is the goal. Erlang is just
starting to get better support for package managers and the like, and it’d
be a shame to miss out on opportunities for adoption of and contribution to
general-purpose libraries like config, rexi, khash or ets-lru by bundling
them into a repo that doesn’t look or feel like an idiomatic Erlang repo.
And at any rate I certainly hope no one is proposing to copy/paste other
upstream deps into one 

Re: Admin party considered harmful

[Alexander Shorin]

On Tue, Apr 19, 2016 at 10:17 PM, Jan Lehnardt  wrote:
>> On 19 Apr 2016, at 21:06, Alexander Shorin  wrote:
>>
>> On Tue, Apr 19, 2016 at 5:53 PM, Nolan Lawson  wrote:
>>> Thanks Jan, a setup wizard sounds awesome. Believe me, no one would be
>>> happier than me to deprecate add-cors-to-couchdb! :)
>>
>> What had happened with the story about enable CORS by default, btw?
>
> trouble is with a wildcard Host header, CORS doesn’t allow any
> user credentials (Authorization header etc.) to go over CORS.
>
> So either we need Admin Party (n), or the end user has to
> specify the hosts that are allowed to talk to CouchDB, so it’s
> not really CORS-by-default.

Aha, I see. Thanks for explanation!

--
,,,^..^,,,

Re: Admin party considered harmful

[Jan Lehnardt]

> On 19 Apr 2016, at 21:06, Alexander Shorin  wrote:
> 
> On Tue, Apr 19, 2016 at 5:53 PM, Nolan Lawson  wrote:
>> Thanks Jan, a setup wizard sounds awesome. Believe me, no one would be
>> happier than me to deprecate add-cors-to-couchdb! :)
> 
> What had happened with the story about enable CORS by default, btw?

trouble is with a wildcard Host header, CORS doesn’t allow any
user credentials (Authorization header etc.) to go over CORS.

So either we need Admin Party (n), or the end user has to
specify the hosts that are allowed to talk to CouchDB, so it’s
not really CORS-by-default.

Best
Jan
--

Re: Admin party considered harmful

[Alexander Shorin]

On Tue, Apr 19, 2016 at 5:53 PM, Nolan Lawson  wrote:
> Thanks Jan, a setup wizard sounds awesome. Believe me, no one would be
> happier than me to deprecate add-cors-to-couchdb! :)

What had happened with the story about enable CORS by default, btw?

--
,,,^..^,,,

Re: Admin party considered harmful

[Jan Lehnardt]

Just to be clear: the wizard exists in master/2.0, all it needs is a “CORS 
button” :)

Any takers? https://github.com/apache/couchdb-fauxton 


Best
Jan
--

> On 19 Apr 2016, at 16:53, Nolan Lawson  wrote:
> 
> Thanks Jan, a setup wizard sounds awesome. Believe me, no one would be
> happier than me to deprecate add-cors-to-couchdb! :)
> 
> - Nolan
> 
> On Tue, Apr 19, 2016 at 3:09 AM, Jan Lehnardt  wrote:
> 
>> From this thread alone, it should be obvious that this is a contentious
>> topic.
>> 
>> CouchDB 2.0 will have a happy-path setup that requires a setup. You can get
>> out of it, if you run a single-node instance, but for a cluster, you have
>> to
>> have an admin user. Discussions about this are about two years old and now
>> is not the time to revisit them.
>> 
>> This is a good default security that CouchDB has been dinged for over the
>> years
>> and the devs generally agree that having a server admin at least is a good
>> idea.
>> Note that this means regular doc r/w is still open to anyone, just db and
>> ddoc
>> creation is limited to admins.
>> 
>> Then we have to balance this with user-friendliness of course, and I think
>> things like the setup wizard (thanks Robert!) in Fauxton here can help.
>> This
>> is what normal users* and especially beginners will go through to set up
>> one
>> or more 2.0 nodes. As part of the setup procedure, Fauxton could offer a
>> button “enable CORS for dev purposes“, or something else that helps them
>> set
>> it up correctly that would replace
>> https://github.com/pouchdb/add-cors-to-couchdb
>> that effectively all PouchDB users will just use without learning the
>> consequences (FWIW, I’ve used this myself, configuring CORS is too hard in
>> CouchDB).
>> 
>> In addition: we have agreed last summer that we are not going to offer the
>> /_config endpoint in 2.0 because that’d require to build a CP system on top
>> of an AP one and we didn’t want to delay 2.0 because of that (imagine!) We
>> made per-node /_config available under /_node//_config and I’d
>> be happy to have Fauxton use this to make CORS a simple setup. This
>> wouldn’t
>> work well for larger clusters, but that’s not the target audience here.
>> 
>> * expert users will use deploy scripts and other ways to deploy
>> pre-configured
>> instances, they will know what they are doing.
>> 
>> Best
>> Jan
>> --
>> 
>> 
>> 
>> 
>> 
>>> On 19 Apr 2016, at 08:39, Eli Stevens (Gmail) 
>> wrote:
>>> 
>>> Honestly, the entire topic feels over-thought to me. If someone sets
>>> up a database, has it listen to a port that's open to the internet,
>>> and doesn't set a password... The situation is pretty much hopeless.
>>> There's zero chance that *this* is the only security hole that they
>>> have, and IMO it's kinda silly to think that adding some CouchDB
>>> nanny-state will result in a now-airtight system. Obviously, sane
>>> defaults and documentation in the default config are great.
>>> 
>>> I've been running into this with some other tools that I use - I want
>>> to do a certain thing, but the tools prevent me, since the author of
>>> the tool apparently has a philosophical disagreement with the workflow
>>> I prefer (to the point of actively inserting somewhat arbitrary
>>> precondition checks before performing operations that would otherwise
>>> succeed).
>>> 
>>> Needless to say, when I need to do something, and the tool has gone
>>> out of it's way to block the thing that I'd like to do, it's quite
>>> frustrating. Please trust me to do my job, and to know my use cases.
>>> 
>>> FWIW, all of my CouchDB instances are in admin party, and were an
>>> attacker to penetrate deep into our systems enough to access CouchDB,
>>> we'd have been so hopelessly compromised that "oh, they can access the
>>> DB too" wouldn't meaningfully increase the severity of the event.
>>> Making me play an obfuscation shell game with a password or auth token
>>> so that the various programs I have can access the DB isn't going to
>>> actually make my systems more secure.
>>> 
>>> Thanks,
>>> Eli
>>> 
>>> On Mon, Apr 18, 2016 at 6:32 PM, Michael Fair 
>> wrote:
 SMTP open relays; wikis; and comment/bulletin board systems have taught
>> us
 that if there's any hope of monetizing something an ip scanner can
>> attack,
 they will.
 
 This includes a default admin password.  The problem isn't really admin
 party mode; it's a trivially automated type of default attack profile.
 
 I agree with Nolan that people (myself included) succeed in getting
 started/familiar with Couch largely because of a text editor, admin
>> party
 mode, curl, and futon.  Following the breadcrumb tutorials and
>> immediately
 creating/destroying databases; Editing data docs and design docs
>> quickly,
 directly "on the server"; and practicing replication; without having to
 

Re: Admin party considered harmful

[Eli Stevens (Gmail)]

On Tue, Apr 19, 2016 at 12:09 AM, Jan Lehnardt  wrote:
> Discussions about this are about two years old and now
> is not the time to revisit them.

I probably didn't do a good job of conveying my stance earlier, but I
wholeheartedly agree with this position.

Thanks,
Eli

Re: [ANNOUNCE] Nolan Lawson elected as CouchDB committer

[Johannes Jörg Schmidt]

Congratulations Nolan! \o/

On 19.04.2016 18:19, Joan Touzet wrote:
> Congrats, Nolan!
> 
> - Original Message -
>> From: "Robert Kowalski" 
>> To: dev@couchdb.apache.org
>> Sent: Tuesday, April 19, 2016 12:04:22 PM
>> Subject: Re: [ANNOUNCE] Nolan Lawson elected as CouchDB committer
>>
>> Whohoo, congrats Nolan! :)
>>
>> On Tue, Apr 19, 2016 at 5:21 PM, Darío Cravero 
>> wrote:
>>> Congrats Nolan!! :)
>>>
>>> On Tue, Apr 19, 2016 at 3:49 PM Nolan Lawson
>>>  wrote:
>>>
 Thanks, Jan and Garren!! I'm happy to join up with such a fine and
 welcoming community. :) Here's to a great 2016 for CouchDB!

 Cheers,
 Nolan

 On Tue, Apr 19, 2016 at 10:46 AM, Jan Lehnardt 
 wrote:

> Woohoo contrats and welcome Nolan :)
>
> Best
> Jan
> --
>> On 19 Apr 2016, at 16:43, Garren Smith 
>> wrote:
>>
>> Dear community,
>>
>> I am pleased to announce that the CouchDB Project Management
>> Committee
>> has elected Nolan Lawson as a CouchDB committer.
>>
>>Apache ID: nolan
>>
>>IRC nick: nolanlawson
>>
>>Twitter: @nolanlawson
>>
>> Committers are given a binding vote in certain project
>> decisions, as
>> well as write access to public project infrastructure.
>>
>> This election was made in recognition of Nolan's commitment to
>> the
>> project. We mean this in the sense of being loyal to the
>> project and
>> its interests.
>>
>> Please join me in extending a warm welcome to Nolan!
>>
>> On behalf of the CouchDB PMC,
>>
>> Cheers
>>
>> Garren
>
> --
> Professional Support for Apache CouchDB:
> https://neighbourhood.ie/couchdb-support/
>
>


 --
 Nolan Lawson
 nolanlawson.com
 github.com/nolanlawson

>>

Re: [ANNOUNCE] Nolan Lawson elected as CouchDB committer

[Joan Touzet]

Congrats, Nolan!

- Original Message -
> From: "Robert Kowalski" 
> To: dev@couchdb.apache.org
> Sent: Tuesday, April 19, 2016 12:04:22 PM
> Subject: Re: [ANNOUNCE] Nolan Lawson elected as CouchDB committer
> 
> Whohoo, congrats Nolan! :)
> 
> On Tue, Apr 19, 2016 at 5:21 PM, Darío Cravero 
> wrote:
> > Congrats Nolan!! :)
> >
> > On Tue, Apr 19, 2016 at 3:49 PM Nolan Lawson
> >  wrote:
> >
> >> Thanks, Jan and Garren!! I'm happy to join up with such a fine and
> >> welcoming community. :) Here's to a great 2016 for CouchDB!
> >>
> >> Cheers,
> >> Nolan
> >>
> >> On Tue, Apr 19, 2016 at 10:46 AM, Jan Lehnardt 
> >> wrote:
> >>
> >> > Woohoo contrats and welcome Nolan :)
> >> >
> >> > Best
> >> > Jan
> >> > --
> >> > > On 19 Apr 2016, at 16:43, Garren Smith 
> >> > > wrote:
> >> > >
> >> > > Dear community,
> >> > >
> >> > > I am pleased to announce that the CouchDB Project Management
> >> > > Committee
> >> > > has elected Nolan Lawson as a CouchDB committer.
> >> > >
> >> > >Apache ID: nolan
> >> > >
> >> > >IRC nick: nolanlawson
> >> > >
> >> > >Twitter: @nolanlawson
> >> > >
> >> > > Committers are given a binding vote in certain project
> >> > > decisions, as
> >> > > well as write access to public project infrastructure.
> >> > >
> >> > > This election was made in recognition of Nolan's commitment to
> >> > > the
> >> > > project. We mean this in the sense of being loyal to the
> >> > > project and
> >> > > its interests.
> >> > >
> >> > > Please join me in extending a warm welcome to Nolan!
> >> > >
> >> > > On behalf of the CouchDB PMC,
> >> > >
> >> > > Cheers
> >> > >
> >> > > Garren
> >> >
> >> > --
> >> > Professional Support for Apache CouchDB:
> >> > https://neighbourhood.ie/couchdb-support/
> >> >
> >> >
> >>
> >>
> >> --
> >> Nolan Lawson
> >> nolanlawson.com
> >> github.com/nolanlawson
> >>
> 

Re: [ANNOUNCE] Nolan Lawson elected as CouchDB committer

[Robert Kowalski]

Whohoo, congrats Nolan! :)

On Tue, Apr 19, 2016 at 5:21 PM, Darío Cravero  wrote:
> Congrats Nolan!! :)
>
> On Tue, Apr 19, 2016 at 3:49 PM Nolan Lawson  wrote:
>
>> Thanks, Jan and Garren!! I'm happy to join up with such a fine and
>> welcoming community. :) Here's to a great 2016 for CouchDB!
>>
>> Cheers,
>> Nolan
>>
>> On Tue, Apr 19, 2016 at 10:46 AM, Jan Lehnardt  wrote:
>>
>> > Woohoo contrats and welcome Nolan :)
>> >
>> > Best
>> > Jan
>> > --
>> > > On 19 Apr 2016, at 16:43, Garren Smith  wrote:
>> > >
>> > > Dear community,
>> > >
>> > > I am pleased to announce that the CouchDB Project Management Committee
>> > > has elected Nolan Lawson as a CouchDB committer.
>> > >
>> > >Apache ID: nolan
>> > >
>> > >IRC nick: nolanlawson
>> > >
>> > >Twitter: @nolanlawson
>> > >
>> > > Committers are given a binding vote in certain project decisions, as
>> > > well as write access to public project infrastructure.
>> > >
>> > > This election was made in recognition of Nolan's commitment to the
>> > > project. We mean this in the sense of being loyal to the project and
>> > > its interests.
>> > >
>> > > Please join me in extending a warm welcome to Nolan!
>> > >
>> > > On behalf of the CouchDB PMC,
>> > >
>> > > Cheers
>> > >
>> > > Garren
>> >
>> > --
>> > Professional Support for Apache CouchDB:
>> > https://neighbourhood.ie/couchdb-support/
>> >
>> >
>>
>>
>> --
>> Nolan Lawson
>> nolanlawson.com
>> github.com/nolanlawson
>>

Re: Closing in on 2.0

[Robert Kowalski]

I have a bug we are recently running into.

Our CI system for Fauxton uses fresh builds of 2.0. We _sometimes_ get
a 503 error from Couch when we try to create our test database. We
boot Couch and wait 30 seconds, raising to 120 seconds did not help.

Example build: https://travis-ci.org/robertkowalski/couchdb-fauxton#L4039

It looks like the 503 comes from:
https://github.com/apache/couchdb-chttpd/blob/be1e959504ac7b0332110a9918365ff20937bc43/src/chttpd.erl#L863

The 503 error stays for the whole 30min our testsuite runs, so giving
it more time after boot probably also wouldn't help.

Our setup for travis is quite standard, we get the Couch master, build
it, and run ./dev/run, see
https://github.com/apache/couchdb-fauxton/blob/master/.travis.yml

On Tue, Apr 19, 2016 at 9:54 AM, Michael Fair  wrote:
>> blockers, not new work. And, yes, I still believe you are proposing
>> something major, with ramifications that require real thought.
>>
>
>
> Thanks guys :)
>
> Mike

Re: [ANNOUNCE] Nolan Lawson elected as CouchDB committer

[Darío Cravero]

Congrats Nolan!! :)

On Tue, Apr 19, 2016 at 3:49 PM Nolan Lawson  wrote:

> Thanks, Jan and Garren!! I'm happy to join up with such a fine and
> welcoming community. :) Here's to a great 2016 for CouchDB!
>
> Cheers,
> Nolan
>
> On Tue, Apr 19, 2016 at 10:46 AM, Jan Lehnardt  wrote:
>
> > Woohoo contrats and welcome Nolan :)
> >
> > Best
> > Jan
> > --
> > > On 19 Apr 2016, at 16:43, Garren Smith  wrote:
> > >
> > > Dear community,
> > >
> > > I am pleased to announce that the CouchDB Project Management Committee
> > > has elected Nolan Lawson as a CouchDB committer.
> > >
> > >Apache ID: nolan
> > >
> > >IRC nick: nolanlawson
> > >
> > >Twitter: @nolanlawson
> > >
> > > Committers are given a binding vote in certain project decisions, as
> > > well as write access to public project infrastructure.
> > >
> > > This election was made in recognition of Nolan's commitment to the
> > > project. We mean this in the sense of being loyal to the project and
> > > its interests.
> > >
> > > Please join me in extending a warm welcome to Nolan!
> > >
> > > On behalf of the CouchDB PMC,
> > >
> > > Cheers
> > >
> > > Garren
> >
> > --
> > Professional Support for Apache CouchDB:
> > https://neighbourhood.ie/couchdb-support/
> >
> >
>
>
> --
> Nolan Lawson
> nolanlawson.com
> github.com/nolanlawson
>

Re: [ANNOUNCE] Nolan Lawson elected as CouchDB committer

[Alexander Shorin]

Congratulations, Nolan! (:
--
,,,^..^,,,


On Tue, Apr 19, 2016 at 5:49 PM, Nolan Lawson  wrote:
> Thanks, Jan and Garren!! I'm happy to join up with such a fine and
> welcoming community. :) Here's to a great 2016 for CouchDB!
>
> Cheers,
> Nolan
>
> On Tue, Apr 19, 2016 at 10:46 AM, Jan Lehnardt  wrote:
>
>> Woohoo contrats and welcome Nolan :)
>>
>> Best
>> Jan
>> --
>> > On 19 Apr 2016, at 16:43, Garren Smith  wrote:
>> >
>> > Dear community,
>> >
>> > I am pleased to announce that the CouchDB Project Management Committee
>> > has elected Nolan Lawson as a CouchDB committer.
>> >
>> >Apache ID: nolan
>> >
>> >IRC nick: nolanlawson
>> >
>> >Twitter: @nolanlawson
>> >
>> > Committers are given a binding vote in certain project decisions, as
>> > well as write access to public project infrastructure.
>> >
>> > This election was made in recognition of Nolan's commitment to the
>> > project. We mean this in the sense of being loyal to the project and
>> > its interests.
>> >
>> > Please join me in extending a warm welcome to Nolan!
>> >
>> > On behalf of the CouchDB PMC,
>> >
>> > Cheers
>> >
>> > Garren
>>
>> --
>> Professional Support for Apache CouchDB:
>> https://neighbourhood.ie/couchdb-support/
>>
>>
>
>
> --
> Nolan Lawson
> nolanlawson.com
> github.com/nolanlawson

Re: Admin party considered harmful

[Nolan Lawson]

Thanks Jan, a setup wizard sounds awesome. Believe me, no one would be
happier than me to deprecate add-cors-to-couchdb! :)

- Nolan

On Tue, Apr 19, 2016 at 3:09 AM, Jan Lehnardt  wrote:

> From this thread alone, it should be obvious that this is a contentious
> topic.
>
> CouchDB 2.0 will have a happy-path setup that requires a setup. You can get
> out of it, if you run a single-node instance, but for a cluster, you have
> to
> have an admin user. Discussions about this are about two years old and now
> is not the time to revisit them.
>
> This is a good default security that CouchDB has been dinged for over the
> years
> and the devs generally agree that having a server admin at least is a good
> idea.
> Note that this means regular doc r/w is still open to anyone, just db and
> ddoc
> creation is limited to admins.
>
> Then we have to balance this with user-friendliness of course, and I think
> things like the setup wizard (thanks Robert!) in Fauxton here can help.
> This
> is what normal users* and especially beginners will go through to set up
> one
> or more 2.0 nodes. As part of the setup procedure, Fauxton could offer a
> button “enable CORS for dev purposes“, or something else that helps them
> set
> it up correctly that would replace
> https://github.com/pouchdb/add-cors-to-couchdb
> that effectively all PouchDB users will just use without learning the
> consequences (FWIW, I’ve used this myself, configuring CORS is too hard in
> CouchDB).
>
> In addition: we have agreed last summer that we are not going to offer the
> /_config endpoint in 2.0 because that’d require to build a CP system on top
> of an AP one and we didn’t want to delay 2.0 because of that (imagine!) We
> made per-node /_config available under /_node//_config and I’d
> be happy to have Fauxton use this to make CORS a simple setup. This
> wouldn’t
> work well for larger clusters, but that’s not the target audience here.
>
> * expert users will use deploy scripts and other ways to deploy
> pre-configured
> instances, they will know what they are doing.
>
> Best
> Jan
> --
>
>
>
>
>
> > On 19 Apr 2016, at 08:39, Eli Stevens (Gmail) 
> wrote:
> >
> > Honestly, the entire topic feels over-thought to me. If someone sets
> > up a database, has it listen to a port that's open to the internet,
> > and doesn't set a password... The situation is pretty much hopeless.
> > There's zero chance that *this* is the only security hole that they
> > have, and IMO it's kinda silly to think that adding some CouchDB
> > nanny-state will result in a now-airtight system. Obviously, sane
> > defaults and documentation in the default config are great.
> >
> > I've been running into this with some other tools that I use - I want
> > to do a certain thing, but the tools prevent me, since the author of
> > the tool apparently has a philosophical disagreement with the workflow
> > I prefer (to the point of actively inserting somewhat arbitrary
> > precondition checks before performing operations that would otherwise
> > succeed).
> >
> > Needless to say, when I need to do something, and the tool has gone
> > out of it's way to block the thing that I'd like to do, it's quite
> > frustrating. Please trust me to do my job, and to know my use cases.
> >
> > FWIW, all of my CouchDB instances are in admin party, and were an
> > attacker to penetrate deep into our systems enough to access CouchDB,
> > we'd have been so hopelessly compromised that "oh, they can access the
> > DB too" wouldn't meaningfully increase the severity of the event.
> > Making me play an obfuscation shell game with a password or auth token
> > so that the various programs I have can access the DB isn't going to
> > actually make my systems more secure.
> >
> > Thanks,
> > Eli
> >
> > On Mon, Apr 18, 2016 at 6:32 PM, Michael Fair 
> wrote:
> >> SMTP open relays; wikis; and comment/bulletin board systems have taught
> us
> >> that if there's any hope of monetizing something an ip scanner can
> attack,
> >> they will.
> >>
> >> This includes a default admin password.  The problem isn't really admin
> >> party mode; it's a trivially automated type of default attack profile.
> >>
> >> I agree with Nolan that people (myself included) succeed in getting
> >> started/familiar with Couch largely because of a text editor, admin
> party
> >> mode, curl, and futon.  Following the breadcrumb tutorials and
> immediately
> >> creating/destroying databases; Editing data docs and design docs
> quickly,
> >> directly "on the server"; and practicing replication; without having to
> >> first understand the security model/settings to grant oneself permission
> >> (or write curl command lines embedding the passwords straight into
> >> bash_history).
> >>
> >> 1)
> >> What about only allowing admin party from a machine with the same ip
> >> addresses Couch is listening on.  So listen to 0.0.0.0 but make source
> ip a
> >> factor in the privileges 

Re: [ANNOUNCE] Nolan Lawson elected as CouchDB committer

[Andy Wenk]

Hey Nolan,

welcome and very happy to have you on board ;-)

All the best

Andy

--
Andy Wenk
Hamburg - Germany
RockIt!

GPG public key: https://pgp.mit.edu/pks/lookup?op=get=0x4F1D0C59BC90917D



> On 19 Apr 2016, at 16:49, Nolan Lawson  wrote:
> 
> Thanks, Jan and Garren!! I'm happy to join up with such a fine and
> welcoming community. :) Here's to a great 2016 for CouchDB!
> 
> Cheers,
> Nolan
> 
> On Tue, Apr 19, 2016 at 10:46 AM, Jan Lehnardt  wrote:
> 
>> Woohoo contrats and welcome Nolan :)
>> 
>> Best
>> Jan
>> --
>>> On 19 Apr 2016, at 16:43, Garren Smith  wrote:
>>> 
>>> Dear community,
>>> 
>>> I am pleased to announce that the CouchDB Project Management Committee
>>> has elected Nolan Lawson as a CouchDB committer.
>>> 
>>>   Apache ID: nolan
>>> 
>>>   IRC nick: nolanlawson
>>> 
>>>   Twitter: @nolanlawson
>>> 
>>> Committers are given a binding vote in certain project decisions, as
>>> well as write access to public project infrastructure.
>>> 
>>> This election was made in recognition of Nolan's commitment to the
>>> project. We mean this in the sense of being loyal to the project and
>>> its interests.
>>> 
>>> Please join me in extending a warm welcome to Nolan!
>>> 
>>> On behalf of the CouchDB PMC,
>>> 
>>> Cheers
>>> 
>>> Garren
>> 
>> --
>> Professional Support for Apache CouchDB:
>> https://neighbourhood.ie/couchdb-support/
>> 
>> 
> 
> 
> --
> Nolan Lawson
> nolanlawson.com
> github.com/nolanlawson



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [ANNOUNCE] Nolan Lawson elected as CouchDB committer

[Nolan Lawson]

Thanks, Jan and Garren!! I'm happy to join up with such a fine and
welcoming community. :) Here's to a great 2016 for CouchDB!

Cheers,
Nolan

On Tue, Apr 19, 2016 at 10:46 AM, Jan Lehnardt  wrote:

> Woohoo contrats and welcome Nolan :)
>
> Best
> Jan
> --
> > On 19 Apr 2016, at 16:43, Garren Smith  wrote:
> >
> > Dear community,
> >
> > I am pleased to announce that the CouchDB Project Management Committee
> > has elected Nolan Lawson as a CouchDB committer.
> >
> >Apache ID: nolan
> >
> >IRC nick: nolanlawson
> >
> >Twitter: @nolanlawson
> >
> > Committers are given a binding vote in certain project decisions, as
> > well as write access to public project infrastructure.
> >
> > This election was made in recognition of Nolan's commitment to the
> > project. We mean this in the sense of being loyal to the project and
> > its interests.
> >
> > Please join me in extending a warm welcome to Nolan!
> >
> > On behalf of the CouchDB PMC,
> >
> > Cheers
> >
> > Garren
>
> --
> Professional Support for Apache CouchDB:
> https://neighbourhood.ie/couchdb-support/
>
>


-- 
Nolan Lawson
nolanlawson.com
github.com/nolanlawson

Re: [ANNOUNCE] Nolan Lawson elected as CouchDB committer

[Jan Lehnardt]

Woohoo contrats and welcome Nolan :)

Best
Jan
--
> On 19 Apr 2016, at 16:43, Garren Smith  wrote:
> 
> Dear community,
> 
> I am pleased to announce that the CouchDB Project Management Committee
> has elected Nolan Lawson as a CouchDB committer.
> 
>Apache ID: nolan
> 
>IRC nick: nolanlawson
> 
>Twitter: @nolanlawson
> 
> Committers are given a binding vote in certain project decisions, as
> well as write access to public project infrastructure.
> 
> This election was made in recognition of Nolan's commitment to the
> project. We mean this in the sense of being loyal to the project and
> its interests.
> 
> Please join me in extending a warm welcome to Nolan!
> 
> On behalf of the CouchDB PMC,
> 
> Cheers
> 
> Garren

-- 
Professional Support for Apache CouchDB:
https://neighbourhood.ie/couchdb-support/

[ANNOUNCE] Nolan Lawson elected as CouchDB committer

[Garren Smith]

Dear community,

I am pleased to announce that the CouchDB Project Management Committee
has elected Nolan Lawson as a CouchDB committer.

Apache ID: nolan

IRC nick: nolanlawson

Twitter: @nolanlawson

Committers are given a binding vote in certain project decisions, as
well as write access to public project infrastructure.

This election was made in recognition of Nolan's commitment to the
project. We mean this in the sense of being loyal to the project and
its interests.

Please join me in extending a warm welcome to Nolan!

On behalf of the CouchDB PMC,

Cheers

Garren

Re: Adam Kocoloski is now an IBM Fellow

[Dave Cottlehuber]

On Fri, 15 Apr 2016, at 10:50, Jan Lehnardt wrote:
> Hey all,
> 
> our own Adam made IBM Fellow! He’s now one of only 267* individuals
> who’ve been awarded this honour for their contributions to IBM and
> computing in general:
> 
>   http://www.ibm.com/ibm/ideasfromibm/us/ibm_fellows/2016/
> 
> Congratulations Adam, very proud to have you on the team :)
> 
> Best
> Jan
> --

That's spectacular Adam! A very influential and I'm sure well-earned
position.

A+
Dave

Re: Closing in on 2.0

[Michael Fair]

> blockers, not new work. And, yes, I still believe you are proposing
> something major, with ramifications that require real thought.
>


Thanks guys :)

Mike

Re: Admin party considered harmful

[Jan Lehnardt]

From this thread alone, it should be obvious that this is a contentious topic.

CouchDB 2.0 will have a happy-path setup that requires a setup. You can get
out of it, if you run a single-node instance, but for a cluster, you have to
have an admin user. Discussions about this are about two years old and now
is not the time to revisit them.

This is a good default security that CouchDB has been dinged for over the years
and the devs generally agree that having a server admin at least is a good idea.
Note that this means regular doc r/w is still open to anyone, just db and ddoc
creation is limited to admins.

Then we have to balance this with user-friendliness of course, and I think
things like the setup wizard (thanks Robert!) in Fauxton here can help. This
is what normal users* and especially beginners will go through to set up one
or more 2.0 nodes. As part of the setup procedure, Fauxton could offer a
button “enable CORS for dev purposes“, or something else that helps them set
it up correctly that would replace 
https://github.com/pouchdb/add-cors-to-couchdb
that effectively all PouchDB users will just use without learning the
consequences (FWIW, I’ve used this myself, configuring CORS is too hard in
CouchDB).

In addition: we have agreed last summer that we are not going to offer the
/_config endpoint in 2.0 because that’d require to build a CP system on top
of an AP one and we didn’t want to delay 2.0 because of that (imagine!) We
made per-node /_config available under /_node//_config and I’d
be happy to have Fauxton use this to make CORS a simple setup. This wouldn’t
work well for larger clusters, but that’s not the target audience here.

* expert users will use deploy scripts and other ways to deploy pre-configured
instances, they will know what they are doing.

Best
Jan
-- 





> On 19 Apr 2016, at 08:39, Eli Stevens (Gmail)  wrote:
> 
> Honestly, the entire topic feels over-thought to me. If someone sets
> up a database, has it listen to a port that's open to the internet,
> and doesn't set a password... The situation is pretty much hopeless.
> There's zero chance that *this* is the only security hole that they
> have, and IMO it's kinda silly to think that adding some CouchDB
> nanny-state will result in a now-airtight system. Obviously, sane
> defaults and documentation in the default config are great.
> 
> I've been running into this with some other tools that I use - I want
> to do a certain thing, but the tools prevent me, since the author of
> the tool apparently has a philosophical disagreement with the workflow
> I prefer (to the point of actively inserting somewhat arbitrary
> precondition checks before performing operations that would otherwise
> succeed).
> 
> Needless to say, when I need to do something, and the tool has gone
> out of it's way to block the thing that I'd like to do, it's quite
> frustrating. Please trust me to do my job, and to know my use cases.
> 
> FWIW, all of my CouchDB instances are in admin party, and were an
> attacker to penetrate deep into our systems enough to access CouchDB,
> we'd have been so hopelessly compromised that "oh, they can access the
> DB too" wouldn't meaningfully increase the severity of the event.
> Making me play an obfuscation shell game with a password or auth token
> so that the various programs I have can access the DB isn't going to
> actually make my systems more secure.
> 
> Thanks,
> Eli
> 
> On Mon, Apr 18, 2016 at 6:32 PM, Michael Fair  wrote:
>> SMTP open relays; wikis; and comment/bulletin board systems have taught us
>> that if there's any hope of monetizing something an ip scanner can attack,
>> they will.
>> 
>> This includes a default admin password.  The problem isn't really admin
>> party mode; it's a trivially automated type of default attack profile.
>> 
>> I agree with Nolan that people (myself included) succeed in getting
>> started/familiar with Couch largely because of a text editor, admin party
>> mode, curl, and futon.  Following the breadcrumb tutorials and immediately
>> creating/destroying databases; Editing data docs and design docs quickly,
>> directly "on the server"; and practicing replication; without having to
>> first understand the security model/settings to grant oneself permission
>> (or write curl command lines embedding the passwords straight into
>> bash_history).
>> 
>> 1)
>> What about only allowing admin party from a machine with the same ip
>> addresses Couch is listening on.  So listen to 0.0.0.0 but make source ip a
>> factor in the privileges assignment.
>> 
>> So in a sense, it's multifactor authorization defaulted to only allow
>> certain source ips admin party access (role="admin", connection="source
>> ip/port").
>> 
>> 2)
>> Make modes enumerable: "Admin Party", "Production", "Development", "Client"
>> (for clients connecting to server hosts and the default when not supplied),
>> "" (like "Internal Production" which would mean the
>> 

Re: Admin party considered harmful

[Eli Stevens (Gmail)]

Honestly, the entire topic feels over-thought to me. If someone sets
up a database, has it listen to a port that's open to the internet,
and doesn't set a password... The situation is pretty much hopeless.
There's zero chance that *this* is the only security hole that they
have, and IMO it's kinda silly to think that adding some CouchDB
nanny-state will result in a now-airtight system. Obviously, sane
defaults and documentation in the default config are great.

I've been running into this with some other tools that I use - I want
to do a certain thing, but the tools prevent me, since the author of
the tool apparently has a philosophical disagreement with the workflow
I prefer (to the point of actively inserting somewhat arbitrary
precondition checks before performing operations that would otherwise
succeed).

Needless to say, when I need to do something, and the tool has gone
out of it's way to block the thing that I'd like to do, it's quite
frustrating. Please trust me to do my job, and to know my use cases.

FWIW, all of my CouchDB instances are in admin party, and were an
attacker to penetrate deep into our systems enough to access CouchDB,
we'd have been so hopelessly compromised that "oh, they can access the
DB too" wouldn't meaningfully increase the severity of the event.
Making me play an obfuscation shell game with a password or auth token
so that the various programs I have can access the DB isn't going to
actually make my systems more secure.

Thanks,
Eli

On Mon, Apr 18, 2016 at 6:32 PM, Michael Fair  wrote:
> SMTP open relays; wikis; and comment/bulletin board systems have taught us
> that if there's any hope of monetizing something an ip scanner can attack,
> they will.
>
> This includes a default admin password.  The problem isn't really admin
> party mode; it's a trivially automated type of default attack profile.
>
> I agree with Nolan that people (myself included) succeed in getting
> started/familiar with Couch largely because of a text editor, admin party
> mode, curl, and futon.  Following the breadcrumb tutorials and immediately
> creating/destroying databases; Editing data docs and design docs quickly,
> directly "on the server"; and practicing replication; without having to
> first understand the security model/settings to grant oneself permission
> (or write curl command lines embedding the passwords straight into
> bash_history).
>
> 1)
> What about only allowing admin party from a machine with the same ip
> addresses Couch is listening on.  So listen to 0.0.0.0 but make source ip a
> factor in the privileges assignment.
>
> So in a sense, it's multifactor authorization defaulted to only allow
> certain source ips admin party access (role="admin", connection="source
> ip/port").
>
> 2)
> Make modes enumerable: "Admin Party", "Production", "Development", "Client"
> (for clients connecting to server hosts and the default when not supplied),
> "" (like "Internal Production" which would mean the
> "Client" request mode isn't allowed)
> And then by default prevent servers in different modes from
> replicating/querying each other (add "req_mode" field (the mode of the
> thing requesting); and "rep_mode" field (the mode the database replying
> should be in) to the request parameters).
>
> Make database operational settings for which request modes are enabled for
> which reply modes.
> By default:
> "Admin Party" only allows requests from "Admin Party" and "Client"
> "Production" allows "Production" and "Client"
> "Development" allows "Development" and "Client"
>
> 3)
> Reuse Erlang's magic cookie concept for any access sourced remotely.  If I
> can, by default, access an admin party database remotely by adding a "magic
> cookie" (that the server generated) to the URL header in place of a login;
> and I can only get that cookie by querying the database from the same local
> machine the server is running, and the server/database must be in admin
> party mode.  That's A) pretty easy to look up and get the copy/paste
> instructions to do for a default; B) a clearly placed magic cookie can be
> retrieved (because it got added to the default server/database json
> response) by any appropriately authorized user; and C) is not easy for an
> automated scanner to exploit unless it's already on the same host.
>
> A different token would be generated for each server mode; or these magic
> cookies would be purely an "Admin Party" mode thing.
>
> Thoughts?
>
> Mike
>
> A hosted service would need to have a way to communicate the magic cookies
> of new databases to their users, or require authentication; but
>
> Embedding my server's "Admin Party"  on a client command line
> On Apr 18, 2016 8:01 AM, "Nolan Lawson"  wrote:
>
>> I do think that there's a tension between the needs of first-timers and
>> production users. First-timers are already stymied by the lack of CORS by
>> default, and if we remove the Admin party from the default installation,
>> it's