Log of the #fcrepo channel on chat.freenode.net

Using timezone: Eastern Standard Time
* terrellt leaves06:55
* terrellt joins07:04
* dwilcox joins07:41
* awead leaves08:32
* awead joins08:33
* awead leaves08:41
* esm_ joins08:43
* acoburn joins09:01
* awead joins09:04
* jgpawletko leaves09:49
<acoburn>awoods: for the new webacl module, should it be called "fcrepo-module-auth-webacl"? or is the "-module" part unnecessary?
<awoods>acoburn: let
acoburn: let's keep the "module" in for consistency.09:50
<acoburn>awoods: ok, any objection to me creating that in -labs?
* github-ff joins09:51
[fcrepo4-vagrant] ruebot closed pull request #7: Move Fuseki install from stand alone server to deployable war. FCREPO-14... (master...FCREPO-1467) http://git.io/vsXtU
* github-ff leaves
<acoburn>awoods: and should it be webac or webacl?09:54
<awoods>acoburn: webac09:55
<acoburn>awoods: https://github.com/fcrepo4-labs/fcrepo-module-auth-webac09:56
<awoods>acoburn: thanks09:57
* whikloj joins
* jgpawletko joins10:01
* awead leaves10:13
* awead joins10:29
* whikloj leaves10:41
* whikloj joins10:42
* ajs6f joins10:46
<f4jenkins>Project fcrepo4-T2 build #334: UNSTABLE in 5 min 9 sec: http://jenkins.fcrepo.org/job/fcrepo4-T2/334/10:53
<acoburn>whikloj: congratulations!10:59
<whikloj>acoburn: thanks, though my understanding is this just means more work. Not more glamour.11:00
<ajs6f>whikloj: https://i.ytimg.com/vi/QXk_oSMYTBE/maxresdefault.jpg11:01
<whikloj>ajs6f: I knew you wouldn't steer me wrong
<awoods>whikloj: https://plus.google.com/hangouts/_/event/c1glu6soq43r1rr6ou17qtobug8
<ajs6f>whikloj: You can't see me in that photo: I'm the one standing on the bank of the pit, laughing hysterically.
<whikloj>ajs6f: Oh, I thought you were standing on my shoulders with your hand sticking out?11:05
<ajs6f>whikloj: I will be, after one of the other committers pushes me in.11:06
* acoburn1 joins11:30
* acoburn leaves
<ruebot>whikloj++ #hella congrats!11:32
<acoburn1>awoods: I can do the testing work
<awoods>acoburn1: whikloj has volunteered
<acoburn1>awoods: sorry, my internet connection is being really flaky right now
awoods: whikloj volunteered for the testing work?11:33
<whikloj>acoburn1: no no, I was just holding your spot ;)
ruebot: thanks, sorry for my delay11:42
<dwilcox>awoods / acoburn1 : I took some notes during the meeting. I can post them to the wiki if you like11:46
<acoburn1>dwilcox: that would be great.11:47
<dwilcox>acoburn1: Ok, I'll set up a couple pages on the wiki for sprint notes11:48
<acoburn1>dwilcox: perfect, thanks
* MohamedAR joins11:51
<whikloj>acoburn1: to confirm (or correct) my understanding, our ACLs are going to be RDF resources, correct?11:52
<awoods>whikloj: vs. binaries?11:53
<ajs6f>If not, it will be impossible to rely solely on LDP to impl it.
<whikloj>awoods: yes, just looking at the XACML planning document and it says they are referenceable fcr:datastream resources
<awoods>whikloj: yes, xacml is not RDF11:54
whikloj: but webacs will be RDF, yes.
<whikloj>awoods++
* ajs6f leaves11:55
* escowles joins12:16
<ruebot>it looks like the fuseki binaries can only be downloaded from mirrors now, is there a preferred mirror to use? (this is for vagrant)12:18
<awoods>ruebot: not that I know of
<ruebot>awoods: is it fine if i just pick one? http://jena.apache.org/download/index.cgi12:19
<awoods>ruebot: sure12:20
* acoburn1 leaves12:23
<whikloj>awoods: From a general policy standpoint, do we need to maintain the removed use cases from the WebAC document?12:29
<awoods>whikloj: I do not think we should delete use cases provided by the community. What do you have in mind?12:30
<whikloj>awoods: alternatively, I would create a section for Removed use cases and provide reasons for the removal of the use cases. You only have 3 and one is actually just changed.12:31
<awoods>whikloj: that could work, thanks.12:32
* ajs6f joins12:33
* MohamedAR1 joins12:45
* MohamedAR leaves12:47
* acoburn joins13:09
* peichman joins13:18
* peichman leaves13:19
* peichman joins
re: the WebAC access control delegate, what version of fcrepo should I be basing the POM off of?13:22
<whikloj>peichman/acoburn: I'd say 4.3.1-SNAPSHOT13:24
<acoburn>peichman: yes, 4.3.113:25
peichman: 4.3.1-SNAPSHOT13:26
peichman: for the most part, you can base the pom file on the existing xacml pom
<peichman>cool, I was going from the RBACL POM and modifying it accordingly13:28
<acoburn>that will work, too. Thanks13:29
<whikloj>awoods/acoburn: I don't recall a discussion about conflicting policies, so I am assuming we are still going with most permissive wins. Agreed?14:19
<acoburn>whikloj: in a meeting14:20
<awoods>whikloj: do you have an example?
whikloj: does the top section of the google-doc not cover the cases? https://docs.google.com/document/d/1R3rHE38Kvp5npqahAEEwU8Nmoyh3R2MJ2GGhVqSBq28/edit#14:21
<whikloj>awoods: if there are two ACLs which both refer to /rest/test1, then there are two inbound references to test1 to follow. Which wins?
awoods: or did we deal with this and I fell asleep?14:22
<awoods>whikloj: Note, if multiple ACLs apply to a given target resource based on the target having multiple rdf:type properties, the first ACL found non-deterministically is used.
whikloj: maybe that does not apply in this case...14:23
<whikloj>awoods: right but because the acl can reference multiple objects, we could have two ACLs that both refer to a single resource
awoods: I can try to write triples but that might confuse me more than anyone14:24
<awoods>whikloj: so, if we have one policy that says for a given resource, whikloj=read. and another policy for that same resource that says whikloj=read/write... yes, we should use the most permissive.
<whikloj>awoods++14:25
* acoburn leaves14:27
* acoburn joins14:29
awoods/whikloj: access controls based on a non-deterministic algorithm sounds like a mess14:43
<whikloj>awoods/acoburn: and yet that is what we decided for multiple accessToClass14:44
<awoods>acoburn: agreed
<whikloj>awoods/acoburn: most permissive for it as well?
awoods/acoburn: I think that decision was to avoid having to search the entire repo for any acl that might reference the class, no?14:45
<acoburn>whikloj: yes, it would need to be most permissive
whikloj: we also can't search the entire repo, but if the class-based ACLs are in a known location, that _can_ be searched14:46
<whikloj>acoburn: so we will never have an acl with accessToClass unless it is in this known location? That sounds like we are parsing any updates prior to applying them.14:47
awoods/acoburn: in which case should we change our minds on "the system MUST check that the ACL modification request does contain only valid ACL information."14:48
<acoburn>whikloj: speaking only about the accessToClass ACLs, unless modeshape has a way to index particular resources based on a certain property (in this case rdf:type), we will need those ACLs in a well-defined location14:51
whikloj: by validating modification requests are you talking about making sure any accessToClass acls are in that pre-configured location?14:53
<whikloj>acoburn: yes
<acoburn>whikloj: and how do you handle the scenario in which someone adds ACLs and _then_ adds the webac module?14:54
whikoj: presumably, all bets are off w/r/t validation when the module isn't present
<whikloj>acoburn: right, could we do some sort of "start up" procedure. Setting up our "known location" but also checking for acl:acl before that to test/parse/etc existing acls?14:55
<acoburn>whikloj: I'm thinking of a system property like fcrepo.auth.webac.location (or something like that)14:56
<awoods>whikloj: users can put accessToClass ACLs wherever they want... but only the ones in the known location will be searched. no?
<whikloj>awoods: so we just tell them not to mix accessTo and accessToClass14:57
acoburn: that is easier but then your question of existing acls.
<awoods>whikloj: are you looking at the google-doc?14:58
<whikloj>awoods: yes
<awoods>whikloj: if there is a mix of accessTo and accessToClass, then that ACL will be found and used.
<whikloj>awoods: we don't say that the accessToClass statements have to refer to the rdf:type that the accessTo resource is.14:59
awoods/acoburn: I am fine saying that any accessToClass statements in ACLs NOT in the predefined location are ignored.15:00
<awoods>whikloj: I'm fine with that.
<acoburn>whikloj: I'm also fine with that
<whikloj>done and done
<acoburn>whikloj: presumably, the simple accessTo ACLs can live anywhere. correct?15:01
<whikloj>acoburn: yes, I'm assuming we just follow the inbound references to find them and do the check for most permissive
<acoburn>whikoj: yes, that's my understanding15:02
whikloj: and did we decide that, if one or more ACLs call out a specific resource (accessTo), then there is no need to scan the accessToClass ACLs?15:03
<whikloj>acoburn: yes
acoburn: accessTo first, then accessToClass, then deny
* peichman leaves15:04
<whikloj>acoburn: actually we have to check parents before deny
<acoburn>whikloj: right15:05
whikloj: otherwise, the chain you describe is similar to how it handles users and groups:
whikloj: user first, then group, then deny
<whikloj>acoburn: right
* github-ff joins15:19
[fcrepo4-vagrant] ruebot opened pull request #18: Move Fuseki install from stand alone server to deployable war. Addres… (master...FCREPO-1467) http://git.io/vsMH3
* github-ff leaves
* peichman joins15:25
* jgpawletko leaves15:27
* dwilcox leaves15:35
<whikloj>awoods/acoburn/peichman/MohamedAR1: https://wiki.duraspace.org/display/FF/Design+-+WebAccessControl+Authorization+Delegate15:49
^^^ I'm going a little buggy, so have a look and send me any questions, points for clarification, flat-out mistakes.
* jgpawletko joins
<awoods>thanks, whikloj. will do.
* jgpawletko leaves15:52
* jgpawletko joins15:53
* jgpawletko leaves
* esm_ leaves16:14
<awoods>whikloj: please update this page when you have a moment: https://wiki.duraspace.org/display/FF/Fedora+Committers16:30
<whikloj>awoods: done16:33
<awoods>whikloj: thanks.
* github-ff joins
[fcrepo-webapp-plus] awoods tagged 4.3.1-SNAPSHOT at master: http://git.io/vsDnE
* github-ff leaves
* github-ff joins16:34
[fcrepo4] awoods tagged 4.3.1-SNAPSHOT at master: http://git.io/vsDnx
* github-ff leaves
<MohamedAR1>whikloj: Question on 4.b of Proposed Requirements section - My understanding is that we first check ACL pointed by the resource, then its Parent, and only when these two does not specify any rules of the requesting agent/agentClass, we search for accessToClass acls. I can't think of a scenario where we will be looking at two ACLs for the same resource. Though many ACLs with accessTo same resource can exist in the repo, we will only be loo16:39
* travis-ci joins
fcrepo4-exts/fcrepo-webapp-plus#68 (4.3.1-SNAPSHOT - 81fd433 : Benjamin Armintor): The build passed.
Change view : https://github.com/fcrepo4-exts/fcrepo-webapp-plus/compare/4.3.1-SNAPSHOT
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-webapp-plus/builds/77052005
* travis-ci leaves
<whikloj>MohamedAR1: My understanding is that all accessToClass ACLs will be stored in a pre-configured location to enable us to check them easily and reduce duplication.16:41
MohamedAR1: However as a single ACL can reference multiple resources it is possible to have multiple ACLs linked to a resource. This is when a conflict could occur.16:43
MohamedAR1: We would check all the inbound references on a resource and find there are 2+ ACLs.16:44
MohamedAR1: This would occur in step 1 of https://wiki.duraspace.org/display/FF/Design+-+WebAccessControl+Authorization+Delegate#Design-WebAccessControlAuthorizationDelegate-FindingtheeffectiveACL16:45
<MohamedAR1>whikloj: Thanks! Now I get it. I thought a resource will only point to single ACL.16:46
<acoburn>MohamedAR1: part of the issue is that resources don't _point_ to ACLs; the ACLs point to resources16:47
<whikloj>MohamedAR1: no it appears as if ACLs actually point to the resources, we just follow the inbound reference back out.
acoburn++
<MohamedAR1>whikloj++16:48
acoburn++
* travis-ci joins16:52
fcrepo4/fcrepo4#3981 (4.3.1-SNAPSHOT - 59defcb : Aaron Coburn): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/4.3.1-SNAPSHOT
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/77052220
* travis-ci leaves
<peichman>@acoburn PR for the WebAC AD skeleton is up https://github.com/fcrepo4-labs/fcrepo-module-auth-webac/pull/116:55
<acoburn>peichman: thanks! looking it over now
<whikloj>awoods++16:59
<acoburn>awoods: I'll let you comment, since we're just saying the same things :-)17:00
<awoods>acoburn: done
<whikloj>awoods/acoburn: I just realized I have a dr. appt tomorrow at 11 ET. I am so sorry, totally slipped my mind.17:02
<acoburn>whikloj: could you add a standup report in IRC before then?17:03
<whikloj>acoburn: yes
<acoburn>whikloj: thanks!
<peichman>@awoods/@acoburn: I will address the PR issues tomorrow morning, hope to have them resolved by the 11am meeting17:06
<acoburn>peichman: great! thanks
* peichman leaves17:08
* dwilcox joins17:23
* acoburn leaves17:26
* github-ff joins17:37
[fcrepo-webapp-plus] awoods tagged fcrepo-webapp-plus-4.3.1-SNAPSHOT at master: http://git.io/vsDip
* github-ff leaves
* dwilcox leaves17:38
* whikloj leaves17:43
* github-ff joins17:51
[fcrepo-camel-toolbox] awoods tagged fcrepo-camel-toolbox-4.3.1-SNAPSHOT at master: http://git.io/vsDDl
* github-ff leaves
* travis-ci joins18:03
fcrepo4-exts/fcrepo-camel-toolbox#141 (fcrepo-camel-toolbox-4.3.1-SNAPSHOT - 2075359 : Andrew Woods): The build passed.
Change view : https://github.com/fcrepo4-exts/fcrepo-camel-toolbox/compare/fcrepo-camel-toolbox-4.3.1-SNAPSHOT
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-camel-toolbox/builds/77065050
* travis-ci leaves
* MohamedAR1 leaves18:04
* github-ff joins18:17
[fcrepo4] awoods tagged fcrepo-4.3.1-SNAPSHOT at master: http://git.io/vsDdx
* github-ff leaves
* github-ff joins18:18
[fcrepo4-vagrant] awoods opened pull request #19: Update for 4.3.1-SNAPSHOT (master...fcrepo-1658) http://git.io/vsDFI
* github-ff leaves
* travis-ci joins18:34
fcrepo4/fcrepo4#3982 (fcrepo-4.3.1-SNAPSHOT - 59defcb : Aaron Coburn): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/fcrepo-4.3.1-SNAPSHOT
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/77068919
* travis-ci leaves
* ksclarke leaves18:37
* dwilcox joins19:19
* dwilcox leaves19:24
* the_mgt_ joins19:26
* the_mgt leaves19:29
* ksclarke joins20:21
* dhlamb joins21:39
* dhlamb leaves21:52
* dhlamb joins21:53
* dhlamb leaves21:57