Re: [Ironpython-users] Restrict referencing of assemblies in hosted environment

2012-10-18 Thread Markus Schaber
Hi, Jeff,

> Von: Jeff Hardy [mailto:jdha...@gmail.com]
> On Wed, Oct 17, 2012 at 3:08 AM, Markus Schaber  software.com> wrote:
> > We're using IronPython as a hosted script engine in our application.
> 
> > Now, we want to restrict the assemblies a user can reference from its
> > python script,
> >
> > Currently, we just forbid "import clr", by wrapping the import()
> > method, but this is a bit harsh, and the side-effects are a little bit
> to strong (e. G.
> > it causes "import minidom.py" to fail...)
> >
> 
> I'm pretty sure that importing of CLR classes also goes through
> __import__(). So you should be able to blacklist/whitelist whatever
> classes you want that way. This doesn't prevent loading the assemblies,
> but it does make the classes more difficult to access.
> 
> If whatever hook you're using to block `import clr` doesn't fire for
> `import System` as well, file an issue. And patch, preferably :).

It also fires for "import System".

However, this is a different granularity - our "natural" granularity in our 
existing framework is assemblies, and __import__() works on python modules and 
.net namespaces, and sometimes a namespace contains members from different 
assemblies.

I think I'll go with wrapping all the import methods on the clr module then.

Best regards

Markus Schaber
-- 
___
We software Automation.

3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax 
+49-831-54031-50

Email: m.scha...@3s-software.com | Web: http://www.3s-software.com 
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: 
http://www.3s-software.com/index.shtml?sample_projects

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade 
register: Kempten HRB 6186 | Tax ID No.: DE 167014915 
___
Ironpython-users mailing list
Ironpython-users@python.org
http://mail.python.org/mailman/listinfo/ironpython-users


Re: [Ironpython-users] Restrict referencing of assemblies in hosted environment

2012-10-18 Thread Markus Schaber
Hi, Keith,

Von: Keith Rome [mailto:r...@wintellect.com] 
> Take a look at the PlatformAdaptationLayer class. You can create your own and 
> plug it in to the runtime. This might provide the hooks you are looking for.

> In particular, you should be able to override the LoadAssembly() and 
> LoadAssemblyFromPath() methods to block anything that isn't whitelisted for 
> your host environment.

I did think about that method, but as far as I can see, I won't be able to 
prevent an AddReference("AssemblyName") for an assembly which is already loaded 
in the current AppDomain.

I'd be happy to be proved wrong on this, however. :-)

Keith Rome
Senior Consultant and Architect
MCPD-EAD, MCSD, MCDBA, MCTS-WPF, MCTS-TFS, MCTS-WSS
Wintellect | 770.617.4016 | kr...@wintellect.com
www.wintellect.com

From: Ironpython-users 
[mailto:ironpython-users-bounces+rome=wintellect@python.org] On Behalf Of 
Markus Schaber
Sent: Wednesday, October 17, 2012 6:09 AM
To: Discussion of IronPython
Subject: [Ironpython-users] Restrict referencing of assemblies in hosted 
environment

Hello,

We're using IronPython as a hosted script engine in our application.

Now, we want to restrict the assemblies a user can reference from its python 
script, 

Currently, we just forbid "import clr", by wrapping the import() method, but 
this is a bit harsh, and the side-effects are a little bit to strong (e. G. it 
causes "import minidom.py" to fail...)

However, there seems to be no event or other hook available for AddReference 
which I could use. It may be possible to add an AssemblyLoading event to the 
ScriptDomainManager in Microsoft.Scripting.Runtime, which allows to cancel the 
assembly loading by throwing an exception. Would such a patch be accepted 
upstream?

An alternative (not-so-elegant) idea is that I just wrap all the AddReference() 
& Co calls inside the clr module, but there may be a more elegant way.

Isolating Ironpython in its own AppDomain is not an option, as this would 
require major rework of our Scripting API implementation, and also break 
backwards compatibility for 3rd party plugins which contribute API for the 
scripts.

(We don't need a 100% waterproof method -  we know that the user can use 
cTypes, System.Reflection, or whatever to circumvent everything - we just want 
to restrict the obvious ways to access some APIs we consider to be internal.)

Best regards

Markus Schaber
-- 
___
We software Automation.

3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax 
+49-831-54031-50

Email: m.scha...@3s-software.com | Web: http://www.3s-software.com 
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: 
http://www.3s-software.com/index.shtml?sample_projects

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade 
register: Kempten HRB 6186 | Tax ID No.: DE 167014915 

___
Ironpython-users mailing list
Ironpython-users@python.org
http://mail.python.org/mailman/listinfo/ironpython-users


[Ironpython-users] IronPython, Daily Digest 10/17/2012

2012-10-18 Thread no_reply
Hi ironpython,

Here's your Daily Digest of new issues for project "IronPython".

In today's digest:ISSUES

1. [New comment] bool value conversion malfunctions with Iron python libraries

--

ISSUES

1. [New comment] bool value conversion malfunctions with Iron python libraries
http://ironpython.codeplex.com/workitem/33181
User bhadra has commented on the issue:

"

is compares identity. None is not identical to True or False. So "ip_bool is 
not True" will evaluate to True and "ip_bool is not False" will evaluate to 
True. the standard Python function bool evaluates a Boolean expression.

[Reference: http://stackoverflow.com/questions/5119709/python-true-false]

So bool value conversion does not malfunction in IronPython.

I suggest that you close the issue.
"
--



--
You are receiving this email because you subscribed to notifications on 
CodePlex.

To report a bug, request a feature, or add a comment, visit IronPython Issue 
Tracker. You can unsubscribe or change your issue notification settings on 
CodePlex.com.___
Ironpython-users mailing list
Ironpython-users@python.org
http://mail.python.org/mailman/listinfo/ironpython-users


Re: [Ironpython-users] Restrict referencing of assemblies in hosted environment

2012-10-18 Thread Jeff Hardy
On Thu, Oct 18, 2012 at 12:53 AM, Markus Schaber
 wrote:
> Hi, Keith,
>
> Von: Keith Rome [mailto:r...@wintellect.com]
>> Take a look at the PlatformAdaptationLayer class. You can create your own 
>> and plug it in to the runtime. This might provide the hooks you are looking 
>> for.
>
>> In particular, you should be able to override the LoadAssembly() and 
>> LoadAssemblyFromPath() methods to block anything that isn't whitelisted for 
>> your host environment.
>
> I did think about that method, but as far as I can see, I won't be able to 
> prevent an AddReference("AssemblyName") for an assembly which is already 
> loaded in the current AppDomain.
>
> I'd be happy to be proved wrong on this, however. :-)

I'm pretty sure you're right. I don't have a particular issue with
adding an assembly whitelist/blacklist option, but I don't really have
a use case and thus don't have a feel for what it should look like. If
you have some ideas, please open an issue and jot down your thoughts
on what you'd like the API to look like.

- Jeff
___
Ironpython-users mailing list
Ironpython-users@python.org
http://mail.python.org/mailman/listinfo/ironpython-users


[Ironpython-users] Commercial Support / Bugfixes for Ironpython

2012-10-18 Thread Markus Schaber
Hi,

Is it possible to hire some of the IronPython Core developers for bugfixes, or 
is there commercial support available?

Especially http://ironpython.codeplex.com/workitem/31764 is a major issue for 
some of our users, they fight with Out of Memory exceptions during automated 
test runs which fire hundreds of IronPython scripts.

For us, it might be cheaper and faster to pay an expert for this task, than 
trying to solve it on our own.

Best regards

Markus Schaber
--
___
We software Automation.

3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax 
+49-831-54031-50

Email: m.scha...@3s-software.com | Web: 
http://www.3s-software.com 
CoDeSys internet forum: 
http://forum.3s-software.com
Download CoDeSys sample projects: 
http://www.3s-software.com/index.shtml?sample_projects

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade 
register: Kempten HRB 6186 | Tax ID No.: DE 167014915

___
Ironpython-users mailing list
Ironpython-users@python.org
http://mail.python.org/mailman/listinfo/ironpython-users


Re: [Ironpython-users] Commercial Support / Bugfixes for Ironpython

2012-10-18 Thread Curt Hagenlocher
This doesn't directly address your question, but as I recall,
DefineDynamicAssembly is only used under very particular circumstances. It
can be avoided most of the time in non-debug usage of IronPython. The only
way to release some of the memory usage forced by DefineDynamicAssembly is
to tear down the AppDomain and create a new one. This is a CLR issue.

Disclaimer: I haven't worked on this code in about three years.

On Thu, Oct 18, 2012 at 8:52 AM, Markus Schaber
wrote:

>  Hi,
>
> ** **
>
> Is it possible to hire some of the IronPython Core developers for
> bugfixes, or is there commercial support available?
>
> ** **
>
> Especially http://ironpython.codeplex.com/workitem/31764 is a major issue
> for some of our users, they fight with Out of Memory exceptions during
> automated test runs which fire hundreds of IronPython scripts.
>
> ** **
>
> For us, it might be cheaper and faster to pay an expert for this task,
> than trying to solve it on our own.
>
> ** **
>
> Best regards
>
> Markus Schaber
> --
> ___
>
> We software Automation.
>
> 3S-Smart Software Solutions GmbH
> Markus Schaber | Developer
> Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax
> +49-831-54031-50
>
> Email: *m.scha...@3s-software.com* | Web: http://www.3s-software.com
> CoDeSys internet forum: 
> http://forum.3s-software.com
> Download CoDeSys sample projects:
> http://www.3s-software.com/index.shtml?sample_projects
>
> *Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner* | *Trade
> register: Kempten HRB 6186* | *Tax ID No.: DE 167014915** *
>
> ** **
>
> ___
> Ironpython-users mailing list
> Ironpython-users@python.org
> http://mail.python.org/mailman/listinfo/ironpython-users
>
>
___
Ironpython-users mailing list
Ironpython-users@python.org
http://mail.python.org/mailman/listinfo/ironpython-users


Re: [Ironpython-users] Commercial Support / Bugfixes for Ironpython

2012-10-18 Thread Markus Schaber
Hi, Curt,

Thank you for your answer. Maybe it is possible to utlilise the Collectible 
Assemblies introduced with .NET 4.0 
(http://msdn.microsoft.com/en-us/library/dd554932%28v=vs.100%29.aspx) - they 
should be fully GC-able...

We can also live with an explicit "Dispose()"-Method to clean up artifacts of 
old scripts, if that helps further...

Best regards

Markus Schaber
--
___
We software Automation.

3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax 
+49-831-54031-50

Email: m.scha...@3s-software.com | Web: 
http://www.3s-software.com 
CoDeSys internet forum: 
http://forum.3s-software.com
Download CoDeSys sample projects: 
http://www.3s-software.com/index.shtml?sample_projects

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade 
register: Kempten HRB 6186 | Tax ID No.: DE 167014915

Von: Curt Hagenlocher [mailto:c...@hagenlocher.org]
Gesendet: Donnerstag, 18. Oktober 2012 18:01
An: Markus Schaber
Cc: Discussion of IronPython
Betreff: Re: [Ironpython-users] Commercial Support / Bugfixes for Ironpython

This doesn't directly address your question, but as I recall, 
DefineDynamicAssembly is only used under very particular circumstances. It can 
be avoided most of the time in non-debug usage of IronPython. The only way to 
release some of the memory usage forced by DefineDynamicAssembly is to tear 
down the AppDomain and create a new one. This is a CLR issue.

Disclaimer: I haven't worked on this code in about three years.
On Thu, Oct 18, 2012 at 8:52 AM, Markus Schaber 
mailto:m.scha...@3s-software.com>> wrote:
Hi,

Is it possible to hire some of the IronPython Core developers for bugfixes, or 
is there commercial support available?

Especially http://ironpython.codeplex.com/workitem/31764 is a major issue for 
some of our users, they fight with Out of Memory exceptions during automated 
test runs which fire hundreds of IronPython scripts.

For us, it might be cheaper and faster to pay an expert for this task, than 
trying to solve it on our own.

Best regards

Markus Schaber
--
___
We software Automation.

3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. 
+49-831-54031-0 | Fax 
+49-831-54031-50

Email: m.scha...@3s-software.com | Web: 
http://www.3s-software.com 
CoDeSys internet forum: 
http://forum.3s-software.com
Download CoDeSys sample projects: 
http://www.3s-software.com/index.shtml?sample_projects

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade 
register: Kempten HRB 6186 | Tax ID No.: DE 167014915


___
Ironpython-users mailing list
Ironpython-users@python.org
http://mail.python.org/mailman/listinfo/ironpython-users

___
Ironpython-users mailing list
Ironpython-users@python.org
http://mail.python.org/mailman/listinfo/ironpython-users


Re: [Ironpython-users] Commercial Support / Bugfixes for Ironpython

2012-10-18 Thread Curt Hagenlocher
I don't want to make it sound like I know more than I do; the discussion on
work item 20399 makes it clear that I don't accurately remember all of the
specifics around this issue. But I do recall that we looked at using
collectible assemblies and decided against it. We were still committed to
supporting .NET 2.0 at the time, so that was one factor. But the real
problem is having a realistic idea of when to stop emitting methods into
assembly 1 and start emitting them into assembly 2. Having small
granularity -- too many assemblies -- is a bad thing (for reasons I no
longer remember). But putting too many methods into a single assembly
increases the chance that the assembly will never be collected because one
of its types are still in use.

Running each independent script in its own AppDomain is painful and may
have performance consequences. But ultimately, it gives you the best
control over resource management.
On Thu, Oct 18, 2012 at 9:16 AM, Markus Schaber
wrote:

>  Hi, Curt,
>
> ** **
>
> Thank you for your answer. Maybe it is possible to utlilise the
> Collectible Assemblies introduced with .NET 4.0 (
> http://msdn.microsoft.com/en-us/library/dd554932%28v=vs.100%29.aspx) –
> they should be fully GC-able…
>
> ** **
>
> We can also live with an explicit “Dispose()”-Method to clean up artifacts
> of old scripts, if that helps further…
>
> ** **
>
> Best regards
>
> Markus Schaber
> --
> ___
>
> We software Automation.
>
> 3S-Smart Software Solutions GmbH
> Markus Schaber | Developer
> Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax
> +49-831-54031-50
>
> Email: *m.scha...@3s-software.com* | Web: http://www.3s-software.com
> CoDeSys internet forum: 
> http://forum.3s-software.com
> Download CoDeSys sample projects:
> http://www.3s-software.com/index.shtml?sample_projects
>
> *Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner* | *Trade
> register: Kempten HRB 6186* | *Tax ID No.: DE 167014915** *
>
> ** **
>
> *Von:* Curt Hagenlocher [mailto:c...@hagenlocher.org]
> *Gesendet:* Donnerstag, 18. Oktober 2012 18:01
> *An:* Markus Schaber
> *Cc:* Discussion of IronPython
> *Betreff:* Re: [Ironpython-users] Commercial Support / Bugfixes for
> Ironpython
>
> ** **
>
> This doesn't directly address your question, but as I recall,
> DefineDynamicAssembly is only used under very particular circumstances. It
> can be avoided most of the time in non-debug usage of IronPython. The only
> way to release some of the memory usage forced by DefineDynamicAssembly is
> to tear down the AppDomain and create a new one. This is a CLR issue.
>
>  
>
> Disclaimer: I haven't worked on this code in about three years.
>
> On Thu, Oct 18, 2012 at 8:52 AM, Markus Schaber 
> wrote:
>
> Hi,
>
>  
>
> Is it possible to hire some of the IronPython Core developers for
> bugfixes, or is there commercial support available?
>
>  
>
> Especially http://ironpython.codeplex.com/workitem/31764 is a major issue
> for some of our users, they fight with Out of Memory exceptions during
> automated test runs which fire hundreds of IronPython scripts.
>
>  
>
> For us, it might be cheaper and faster to pay an expert for this task,
> than trying to solve it on our own.
>
>  
>
> Best regards
>
> Markus Schaber
> --
> ___
>
> We software Automation.
>
> 3S-Smart Software Solutions GmbH
> Markus Schaber | Developer
> Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax
> +49-831-54031-50
>
> Email: *m.scha...@3s-software.com* | Web: http://www.3s-software.com
> CoDeSys internet forum: 
> http://forum.3s-software.com
> Download CoDeSys sample projects:
> http://www.3s-software.com/index.shtml?sample_projects
>
> *Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner* | *Trade
> register: Kempten HRB 6186* | *Tax ID No.: DE 167014915** *
>
>  
>
>
> ___
> Ironpython-users mailing list
> Ironpython-users@python.org
> http://mail.python.org/mailman/listinfo/ironpython-users
>
> ** **
>
> ___
> Ironpython-users mailing list
> Ironpython-users@python.org
> http://mail.python.org/mailman/listinfo/ironpython-users
>
>
___
Ironpython-users mailing list
Ironpython-users@python.org
http://mail.python.org/mailman/listinfo/ironpython-users