[GitHub] [logging-log4net] fluffynuts commented on pull request #73: adds ActivatorProvider to allow custom type activation (Resolves LOG4NET-565)

[GitBox <gi...@apache.org>]

fluffynuts commented on pull request #73:
URL: https://github.com/apache/logging-log4net/pull/73#issuecomment-950939434


   Hi @tschettler 
   
   As discussed in #72, I still can't see the absolute necessity for providing externally-controlled DI (more like service-locator, to be honest) to log4net; indeed, it provides a mechanism for untrusted third-party code to inject it's own logic: once there is a statically-available method for overriding how plugins are created, one of your nuget libraries could use this mechanism to hijack control of your application, without your permission or knowledge. It is (imo) a security risk, at least on par with the XML entities security issue fixed some time back.
   
   Plugins you write are completely under your control - so provide a parameterless constructor and use your own DI mechanisms to call into the constructor expecting dependencies to be injected via parameter. It's about the same amount of work as configuring this method but doesn't expose a well-known point of configuration which can be manipulated against you.
   
   I also don't see the value in providing this mechanism for ADO.NET connections either - they are parameterless (unless there's one I'm missing? And even so, one could create one's own parameterless wrapper for a third-party ADO.NET connection type and configure that to be used within log4net). Exposing this functionality provides someone with a hook-point to read your database credentials!
   
   I'd need to see an exact use-case where missing this feature is a show-stopper. So far, I can't think of one, but that doesn't mean it doesn't exist. I'm very reticent to merge in anything which can potentially be used against consumers of this library.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org