This was a pretty lame response.  After re-looking at it, I remember  
some other specifics about why I didn't choose

- Lots of its code is to allow you to create "untrusted"
   code, and it creates proxies for this purpose.
   repoze.bfg has no concept of untrusted code.

- Its security policies mak assumptions about "interactions" and
   "participants", which are zope publisher concepts (misguided ones,  
   that do not exist in repoze.bfg.

All that said, it should be trivial to create a *new* repoze.bfg  
security policy that used hooked up principals to permissions in such  
a way that it might emulate the concepts in Zope security that folks  
are used to (essentially replacing the ACL model).  Note that  
permissions in bfg don't need to be predefined currently as in Zope  
(you don't need <zope:permission....>), so I'm not sure there's much  
of anything in *itself* that's useful to bfg.  There  
may be stuff in that's more appropriate, but  
there's no way bfg itself can depend on that package, as it pulls in  
"the world" (even ZODB!).

- C

On Aug 28, 2008, at 9:39 AM, Chris McDonough wrote:

> On Aug 26, 2008, at 9:01 AM, Malthe Borch wrote:
>> David Pratt, Tim TerlegÄrd and I had a brief conversation about the
>> decision to implement a new security policy in repoze.bfg based on
>> ACL.
>> Worries:
>> 1) This does away with ````, which was the de-facto
>> security model for Zope and one most developers are intimately
>> familiar with. Is it possible to support a setup where this security
>> model would be used instead of the new ACL-based policy?
> I'm not certain. is pretty complicated (IMO,
> needlessly) and I'm not personally particularly hot on roles.  But I
> don't think it's impossible.
>> 2) The syntax for the ACL policy is quite crude in my view; it uses
>> tuple-notation and strings where I would've considered a scheme that
>> was less error-prone (on both accounts: a tuple notation is often
>> difficult because the ordering is so random, and strings could  
>> lead to
>> hard-to-catch typos).
> I haven't added any API for setting it, as I couldn't think of a way
> that didn't involve passing the three arguments to a function, which
> turns into the same thing, although I suppose it could do error
> checking.
> - C
> _______________________________________________
> Repoze-dev mailing list

Repoze-dev mailing list

Reply via email to