`dylink` should use introspection instead of hardcoded RepyV2 API call names

[aaaaalbert]

Note: This was previously filed as SeattleTestbed/repy_v2#70, but is not a problem of Repy. I slightly update / summarize the description here.

---

Calls can be added to the RepyV2 API by editing namespace.py. Unfortunately, libraries that are dylinked in do not get immediate access to new API calls unless dylink.r2py is also modified so that its understanding of STOCK_API includes the added call's name. Otherwise, a NameError is raised.

# Assume that your Repy API defines the call below.
# Importing this program as a library in another 
# program causes a NameError.
new_repy_api_function_that_is_not_in_dylink_stock_api()

To confuse matters, the NameError is only present when that code is dylinked in from another program. You can directly run it just fine, and it's also fine to run it as the main program under dylink, i.e. repy.py restrictionsfile dylink.r2py that_code.r2py.

Instead of requiring manual changes triggered by peculiar-to-obscure error conditions, we can change dylink to just introspect its execution context (_context) and recreate STOCK_API from all the objects of type 'instancemethod'.

The reason for this seemingly weird type is that the Repy API functions are not visible as Python function types, but bound methods NamespaceAPIFunctionWrapper.wrapped_function. A template method for comparison may be created like so:

class A():
  def b():
    pass

a = A()
type(a.b)   # <type 'instancemethod'>

[JustinCappos]

This would make API functions implicitly callable when provided by the
lower security layer. Can you discuss what implications you think this has
for security?

On Tue, Aug 16, 2016 at 10:46 AM, aaaaalbert notifications@github.com
wrote:

*Note: This was previously filed as SeattleTestbed/repy_v2#70
SeattleTestbed/repy_v2#70, but is not a problem

of Repy. I slightly update / summarize the description here.*

Calls can be added to the RepyV2 API by editing namespace.py.
Unfortunately, libraries that are dylinked in do not get immediate access
to new API calls unless dylink.r2py is also modified so that its
understanding of STOCK_API includes the added call's name. Otherwise, a
NameError is raised.

Assume that your Repy API defines the call below.# Importing this program as a library in another # program causes a NameError.

new_repy_api_function_that_is_not_in_dylink_stock_api()

To confuse matters, the NameError is only present when that code is dylinked
in from another program. You can directly run it just fine, and it's also
fine to run it as the main program under dylink, i.e. repy.py
restrictionsfile dylink.r2py that_code.r2py.

Instead of requiring manual changes triggered by peculiar-to-obscure error
conditions, we can change dylink to just introspect its execution context
(_context) and recreate STOCK_API from all the objects of type
'instancemethod'.

The reason for this seemingly weird type is that the Repy API functions
are not visible as Python function types, but bound methods
NamespaceAPIFunctionWrapper.wrapped_function. A template method for
comparison may be created like so:

class A():
def b():
pass

a = A()type(a.b) # <type 'instancemethod'>

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#184, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AA0XD9uTwtqtxrPT_31dmRaUSneubgtFks5qgc0-gaJpZM4JlfXD
.