Martin Aspeli wrote:
> Chris McDonough wrote:
>> Creating parallel "adapter", "utility" and "subscriber" handlers is really 
>> how I
>> should have started things out, but I didn't, and given that there are people
>> using the system in the wild that this would cause problems for in a new
>> release, I wanted to ask for comments.
> This seems like a fairly silly way to make repoze.bfg more of an island 
> than it already is. What is the real-world cost of those dependencies? I 
> know there are a few problems - running on GAE, detailed security 
> audits, that kind of thing - but I'm not convinced it's an issue for 
> most people.
> Why can't we instead try to work with the Zope 3 project to untangle the 
> dependencies there? It's definitely a desirable goal in that project 
> too, but one that hasn't happened for lack of the type of analysis 
> you've done here.

Note that the reasons aren't only to get rid of dependencies for the sake of
getting rid of them.  And note that the dependency graph is not as fucked as it
might appear, given the requirements of the existing directives.  There are more
practical reasons to create a different set of core directive handlers, and
there are reasons the dependency graph is the way it is now, which I should have

- Zope wants the concept of "trusted" adapters and utilities.  From
  the docstring of the "trusted" attribute of IAdapterDirective:
  "Trusted adapters have unfettered access to the objects they adapt.
  If asked to adapt security-proxied objects, then, rather than
  getting an unproxied adapter of security-proxied objects, you
  get a security-proxied adapter of unproxied objects".

  If this doscstring description alone isn't enough to make you want
  to rip that particular code out, please consider that BFG has no
  concept of "untrusted" code.  If folks use the "trusted" flag on
  an adapter declaration in ZCML within BFG, I have absolutely no clue
  what will happen. Its usage would be a bug in a BFG app.

  Note that this feature requires "".

- Zope wants to gate access to adapters, utilities and subscriptions
  based on a permission.  The concept of permission it uses has no
  bearing on bfg applications; utility usage is never
  security-protected in bfg apps.  Like "trusted", the usage of
  the "permission" attribute on an adapter or utility declaration
  in BFG would be a bug.

  Note that this feature requires "".

- The "interface" directive mutates the global CA registry directly.
  BFG apps don't use the global registry; they keep a CA registry
  per-app.  The usage of the global registry in a BFG app would be
  a bug.

In summary, the directives that Zope uses to make adapter, utility, interface
and subscriber registrations are far down the road of 1) encouraging the use of
"untrusted" code, 2) gating access to utility and adapter lookups based on a
concept of permission that only Zope itself has and 3) depending on the global
registry.  All of these things are either not useful for bfg or actively 

Maybe there's some potential to create a set of core ZCML registration handlers
for utility, adapter, subscriber, and interace that are not actually part of
BFG, but on which BFG and other non-Zope apps could depend.  I suspect this is
the only realistic way to go forward: I don't think it's reasonable to tell the
people who have Zope apps in production which use these declarations that they
won't be able to use untrusted code or permission declarations, or the global

- C

Repoze-dev mailing list

Reply via email to