[jira] [Commented] (COUCHDB-1475) _users design documents access
[
https://issues.apache.org/jira/browse/COUCHDB-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13630336#comment-13630336
]
Jean-Pierre Fiset commented on COUCHDB-1475:
I agree that this needs to be revisited. I wish that the _users database was
consistent with other databases. Currently, I want some roles to be able to
manage other users, which requires access to some views. Yet, I do not wish to
give those roles the ability to change the design document.
It seems that the "members" section of the security document is useless in the
case of the _users database.
> _users design documents access
> --
>
> Key: COUCHDB-1475
> URL: https://issues.apache.org/jira/browse/COUCHDB-1475
> Project: CouchDB
> Issue Type: Question
> Components: Database Core
>Affects Versions: 1.2
> Environment: Debian/testing
>Reporter: Stéphane Alnet
>Priority: Minor
>
> Sorry I'm coming in late on this topic, I found this while testing my
> existing code against 1.2.0.
> The comments for commit e5503ffef957dc5e8784c7223e318738ae79b6df indicate for
> `after_doc_read`:
> If the doc is a design doc and the userCtx doesn't identify
> an admin or db-admin:
> -> 403 // Forbidden
> This breaks the (previously working) case where access to the _users database
> is restricted using a "members" security property, and authorized users could
> use a couchapp found in the _users database to manager user records.
> (These power-users would have, say, "user_manager_ro" and "user_manager_rw"
> roles assigned to them, with the ro/rw aspect handled by a specific
> validate_doc_udpate() which would be part of the couchapp; the roles were
> entered in the _users' database members.roles security field.)
> Pointing me back to a discussion explaining the background for this new
> behavior would be sufficient, if it is effectively a desirable side-effect
> and things will remain as they are. Otherwise it seems a finer-grained logic
> for after_doc_read() would be able to restore the desired result, along the
> lines of:
> If the doc is a design doc and (there are no security members.roles
> and no members.names) and (the userCtx doesn't identify
> an admin or db-admin)
> -> 403 // Forbidden
> Thanks,
> S.
> PS: Overall I'm surprised the changes in that commit used new Erlang code
> rather than suggesting best-practices using the exisiting security features.
> I don't understand how hiding the design documents enhances security
> ("security by obscurity"), but that's beyond what I'm asking here.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [DISCUSS] Archive Apache CouchDB 1.2.1
> On 12 April 2013 09:14, Noah Slater wrote: >> Thinking about this, we might want to clarify the difference between a >> release not being supported, and a release being archived. Obviously, it >> makes no sense to keep around two bugfix versions of the same minor release >> line. (In this case, 1.2.1 and 1.2.2.) But 1.2.1 was released in January, >> so I think we'll probably want to "support" it for 12 months, as we've >> previously discussed. I am not exactly sure what "support" means in this >> context. I guess when we talk about supporting releases, what we actually >> mean is that we support major/minor release lines. So, in this case, we >> "support" 1.2.x, in so much as we will continue to apply bugfixes to that >> branch. >> >> Do I have this right? (I will update the current release page and my email >> template if I get confirmation.) Sounds good to me. +1 for archiving it as well btw.
Re: [DISCUSS] Archive Apache CouchDB 1.2.1
+1 for clarifying. We're not dropping support for 1.2.1 yet, but (and obviously) the support will manifest as a fix in 1.2.3 (etc). B. On 12 April 2013 09:14, Noah Slater wrote: > Thinking about this, we might want to clarify the difference between a > release not being supported, and a release being archived. Obviously, it > makes no sense to keep around two bugfix versions of the same minor release > line. (In this case, 1.2.1 and 1.2.2.) But 1.2.1 was released in January, > so I think we'll probably want to "support" it for 12 months, as we've > previously discussed. I am not exactly sure what "support" means in this > context. I guess when we talk about supporting releases, what we actually > mean is that we support major/minor release lines. So, in this case, we > "support" 1.2.x, in so much as we will continue to apply bugfixes to that > branch. > > Do I have this right? (I will update the current release page and my email > template if I get confirmation.) > > > On 12 April 2013 13:58, Noah Slater wrote: > >> Dear community, >> >> I would like to archive Apache CouchDB 1.2.1 >> >> Reasons: >> >> * CouchDB 1.2.1 has been superseded by CouchDB 1.2.2 >> >> Archiving this release means that we no longer support it, and we will >> remove any references to it from our website and our wiki. However, the >> original files will still be available to anyone browsing the release >> archives. >> >> For more information, see: >> >> http://wiki.apache.org/couchdb/CurrentReleases#Archived_Releases >> >> You do not need to respond if you are in agreement. If there is no >> response in 72 hours, I will assume lazy consensus. >> >> If we reach consensus, I archive the release. >> >> Thanks, >> >> -- >> NS >> > > > > -- > NS
Re: [DISCUSS] Archive Apache CouchDB 1.2.1
Thinking about this, we might want to clarify the difference between a release not being supported, and a release being archived. Obviously, it makes no sense to keep around two bugfix versions of the same minor release line. (In this case, 1.2.1 and 1.2.2.) But 1.2.1 was released in January, so I think we'll probably want to "support" it for 12 months, as we've previously discussed. I am not exactly sure what "support" means in this context. I guess when we talk about supporting releases, what we actually mean is that we support major/minor release lines. So, in this case, we "support" 1.2.x, in so much as we will continue to apply bugfixes to that branch. Do I have this right? (I will update the current release page and my email template if I get confirmation.) On 12 April 2013 13:58, Noah Slater wrote: > Dear community, > > I would like to archive Apache CouchDB 1.2.1 > > Reasons: > > * CouchDB 1.2.1 has been superseded by CouchDB 1.2.2 > > Archiving this release means that we no longer support it, and we will > remove any references to it from our website and our wiki. However, the > original files will still be available to anyone browsing the release > archives. > > For more information, see: > > http://wiki.apache.org/couchdb/CurrentReleases#Archived_Releases > > You do not need to respond if you are in agreement. If there is no > response in 72 hours, I will assume lazy consensus. > > If we reach consensus, I archive the release. > > Thanks, > > -- > NS > -- NS
[1/2] git commit: Add discuss_archive.txt
Updated Branches: refs/heads/master 2322af2cc -> 052cdb5e0 Add discuss_archive.txt Project: http://git-wip-us.apache.org/repos/asf/couchdb-admin/repo Commit: http://git-wip-us.apache.org/repos/asf/couchdb-admin/commit/48f9cb18 Tree: http://git-wip-us.apache.org/repos/asf/couchdb-admin/tree/48f9cb18 Diff: http://git-wip-us.apache.org/repos/asf/couchdb-admin/diff/48f9cb18 Branch: refs/heads/master Commit: 48f9cb18de25b61b3f16bc601cc057947c23d61c Parents: 2322af2 Author: Noah Slater Authored: Fri Apr 12 13:59:37 2013 +0100 Committer: Noah Slater Committed: Fri Apr 12 13:59:37 2013 +0100 -- email/discuss_archive.txt | 24 1 files changed, 24 insertions(+), 0 deletions(-) -- http://git-wip-us.apache.org/repos/asf/couchdb-admin/blob/48f9cb18/email/discuss_archive.txt -- diff --git a/email/discuss_archive.txt b/email/discuss_archive.txt new file mode 100644 index 000..f3f2b78 --- /dev/null +++ b/email/discuss_archive.txt @@ -0,0 +1,24 @@ +From: %YOU% +To: dev@couchdb.apache.org +Subject: [DISCUSS] Archive Apache CouchDB 1.2.1 + + +Dear community, + +I would like to archive Apache CouchDB %VERSION%. + +Reasons: + + * %REASON% + +Archiving this release means that we no longer support it, and we will remove any references to it from our website and our wiki. However, the original files will still be available to anyone browsing the release archives. + +For more information, see: + +http://wiki.apache.org/couchdb/CurrentReleases#Archived_Releases + +You do not need to respond if you are in agreement. If there is no response in 72 hours, I will assume lazy consensus. + +If we reach consensus, I archive the release. + +Thanks,
[2/2] git commit: Add invitation to cast vote
Add invitation to cast vote Project: http://git-wip-us.apache.org/repos/asf/couchdb-admin/repo Commit: http://git-wip-us.apache.org/repos/asf/couchdb-admin/commit/052cdb5e Tree: http://git-wip-us.apache.org/repos/asf/couchdb-admin/tree/052cdb5e Diff: http://git-wip-us.apache.org/repos/asf/couchdb-admin/diff/052cdb5e Branch: refs/heads/master Commit: 052cdb5e0e71c0a63d5046c16a97d9af86d71bdb Parents: 48f9cb1 Author: Noah Slater Authored: Fri Apr 12 13:59:49 2013 +0100 Committer: Noah Slater Committed: Fri Apr 12 13:59:49 2013 +0100 -- email/vote_release.txt |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) -- http://git-wip-us.apache.org/repos/asf/couchdb-admin/blob/052cdb5e/email/vote_release.txt -- diff --git a/email/vote_release.txt b/email/vote_release.txt index 5d48418..e7821c6 100644 --- a/email/vote_release.txt +++ b/email/vote_release.txt @@ -5,7 +5,7 @@ Subject: [VOTE] Release Apache CouchDB %VERSION%-rc.%CANDIDATE% Dear community, -I would like to call a vote on Apache CouchDB %VERSION%-rc.%CANDIDATE%. +I would like to release Apache CouchDB %VERSION%-rc.%CANDIDATE%. Changes since last round: @@ -27,4 +27,6 @@ Please follow the test procedure here: Please remember that "rc.%CANDIDATE%" is an annotation. If the vote passes, these artefacts will be released as Apache CouchDB %VERSION%. +Please cast your votes now. + Thanks,
[DISCUSS] Archive Apache CouchDB 1.2.1
Dear community, I would like to archive Apache CouchDB 1.2.1 Reasons: * CouchDB 1.2.1 has been superseded by CouchDB 1.2.2 Archiving this release means that we no longer support it, and we will remove any references to it from our website and our wiki. However, the original files will still be available to anyone browsing the release archives. For more information, see: http://wiki.apache.org/couchdb/CurrentReleases#Archived_Releases You do not need to respond if you are in agreement. If there is no response in 72 hours, I will assume lazy consensus. If we reach consensus, I archive the release. Thanks, -- NS
Roadmap process and merge procedure
Devs, With 1.3.0 out, it is time we revisit these docs: http://wiki.apache.org/couchdb/Roadmap_Process http://wiki.apache.org/couchdb/Merge_Procedure Our next bugfix release target is 1st May. Our next feature release target is 1st July. What do we need to do *now* to prepare for these? Do we need to create release branches? If yes, can we do it, and can we document it, so I can bake it into the release procedure. Do we need to communicate how to merge in work for the releases? Remember we discussed (and sort of half documented in that second wiki page) that to merge in code for a release, you have to do a VOTE on a "merge request" to dev, and you have to include tests, and docs, and what have you, and we do lazy consensus on it. If we're serious about this release cadence (and I think we all are) then we need to sort this stuff out ASAP, and communicate it, and actually put it into practice. I need your help though, because I am still learning Git, etc. So I am hoping that a few of you can weigh in on the current state of the merge procedure proposal, and maybe fix it up. Then, once we're happy with it, I can do the DISCUSS/VOTE dance on dev@ and make this official. I am super excited about this. Thanks, -- NS
[jira] [Resolved] (COUCHDB-1702) Recv failure: Connection reset by peer in form_submit.js test
[
https://issues.apache.org/jira/browse/COUCHDB-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Lofts resolved COUCHDB-1702.
-
Resolution: Invalid
This issue is resolved with the recent changes to how the javascript tests are
run.
> Recv failure: Connection reset by peer in form_submit.js test
> -
>
> Key: COUCHDB-1702
> URL: https://issues.apache.org/jira/browse/COUCHDB-1702
> Project: CouchDB
> Issue Type: Bug
>Reporter: Adam Lofts
>
> On Ubuntu 12.10 the form_submit test case sometimes fails with:
> {code}
> not ok 1 form_submit
> Reason: Failed to execute HTTP request: Recv failure: Connection reset by peer
> Trace back (most recent call first):
>
> 37: /home/adam/dev/fp3/couchdb/test/javascript/couch_http.js
> ("{}")
> 425: /home/adam/dev/fp3/couchdb/share/www/script/couch.js
> ("POST","/test_suite_db/baz",[object Object])
> 20: /home/adam/dev/fp3/couchdb/share/www/script/test/form_submit.js
> ()
> 53: /home/adam/dev/fp3/couchdb/test/javascript/cli_runner.js
> runTestConsole(1,"form_submit",(function (debug) {var db = new CouchDB
> 72: /home/adam/dev/fp3/couchdb/test/javascript/cli_runner.js
> runAllTestsConsole()
> 85: /home/adam/dev/fp3/couchdb/test/javascript/cli_runner.js
> {code}
> By debugging the send() calls I see that couchdb is closing the socket before
> the response body gets sent. I.e. The data is getting discarded in the kernel
> buffer.
> There are a variety of references for this issue:
> http://stackoverflow.com/questions/8874021/close-socket-directly-after-send-unsafe
> http://ia600609.us.archive.org/22/items/TheUltimateSo_lingerPageOrWhyIsMyTcpNotReliable/the-ultimate-so_linger-page-or-why-is-my-tcp-not-reliable.html
> In my testing I have found that adding a shutdown() call before close() fixes
> this issue for me.
> A branch with the shutdown() call is available here:
> https://github.com/adamlofts/couchdb/tree/form-submit-test-failure
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
