kpriv/pkgsrc
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
pkgsrc/net/py-foolscap/PLIST

325 lines
13 KiB
Text
Raw Normal View History

Updated py-foolscap to 0.12.5. * Release 0.12.5 (07-Dec-2016) ** Connection Status Reporting This release adds an object named `ConnectionInfo`, which encapsulates information about a connection (both progress while being established, and the outcome once connected). This includes which connection hint was successful, what happened with the other hints, which handlers were used for each, and when the connection was made or lost. To get one of these, use `tub.getConnectionInfoForFURL(furl)` any time after `getReference()` is called, or `rref.getConnectionInfo()` after it resolves. #267 It also adds `ReconnectionInfo`, a similar object for Reconnectors. These capture the state of reconnection process (trying, established, waiting), and will provide a `ConnectionInfo` for the most recent (possibly successful) connection attempt. The API is `reconnector.getReconnectionInfo()`. #268 For details, see "Connection Progress/Status" and "Reconnector Status" in `doc/using-foolscap.rst`. ** Connection Handler API Changes To support `ConnectionInfo`, the Connection Handler API was changed. The one backwards-incompatible change was that the `hint_to_endpoint()` method now takes a third argument, to update the status as the handler makes progress. External handler functions will need to be modified to accept this new argument, and applications which use them should declare a dependency upon the latest Foolscap version, to avoid runtime breakage. Several backwards-compatible changes were made too: handlers can provide a `describe()` method (which feeds `ConnectionInfo.connectionHandlers`), and they can now set a special attribute on any exception they raise, to further influence the status string. In addition, the `tor.control_endpoint_maker()` handler now accepts an optional second argument, which causes the maker function to be called with a additional `update_status` argument. This backwards-compatible change allows the maker function to influence the `ConnectionInfo` status too. The Tor connection handler was enhanced to report distinct statuses for the different phases of connection: launching a new copy of Tor, connecting to an existing Tor daemon, etc. ** Minor Fixes Foolscap-0.12.0 broke `flappserver create`, causing the command to hang rather than exiting cleanly (although the flappserver directory itself was probably created properly). This release finally fixes it. #271
2016-12-12 15:27:39 +01:00
@comment $NetBSD: PLIST,v 1.10 2016/12/12 14:27:39 wiz Exp $
Import py26-foolscap-0.5.1 as net/py-foolscap. This is a ground-up rewrite of Perspective Broker, which itself is Twisted's native RPC/RMI protocol (Remote Procedure Call / Remote Method Invocation). If you have control of both ends of the wire, and are thus not constrained to use some other protocol like HTTP/XMLRPC/CORBA/etc, you might consider using Foolscap. Fundamentally, Foolscap allows you to make a python object in one process available to code in other processes, which means you can invoke its methods remotely. This includes a data serialization layer to convey the object graphs for the arguments and the eventual response, and an object reference system to keep track of which objects you are connecting to. It uses a capability-based security model, such that once you create a non-public object, it is only accessible to clients to whom you've given the (unguessable) FURL. You can of course publish world-visible objects that have well-known FURLs.
2010-07-23 23:45:52 +02:00
bin/flappclient
bin/flappserver
bin/flogtool
${PYSITELIB}/${EGG_INFODIR}/PKG-INFO
${PYSITELIB}/${EGG_INFODIR}/SOURCES.txt
${PYSITELIB}/${EGG_INFODIR}/dependency_links.txt
Update py-foolscap to 0.11.0. * Release 0.11.0 (23-Mar-2016) ** Packaging Fixes Foolscap now declares a dependency on "twisted[tls]" instead of just "twisted": the "[tls]" extra means "we need Twisted and its TLS support". That's how we ask for Twisted to depend upon service_identity and other supporting packages. By using "[tls]", we no longer need to manually depend upon service_identity ourselves. If Twisted switches to some other scheme for TLS support, this will correctly ask for that to be included. (#249) Note that we still depend on pyOpenSSL ourselves, because we need its code to control certificate validation (if Twisted actually moved away from pyOpenSSL for TLS, Foolscap might break altogether). The Twisted dependency was updated to >=16.0.0 (the current version), to get an important HostnameEndpoint fix (#155). The "flogtool", "flappserver", and "flappclient" executables are now provided as "entry_points" on all platforms, not just windows. The old bin/* scripts have been removed. The "flogtool" entrypoint was fixed (a one-character typo in the setup.py specification): apparently it was always broken on windows and nobody noticed. We now use "tox" to run tests, instead of "trial foolscap", although the latter is still fine when run in a virtualenv into which Foolscap has been installed (and is what "tox" does under the hood). This release also moves all source code from "foolscap/" to "src/foolscap/", which should avoid some confusion as to which code is being tested. Developers who work from a git checkout should manually "rm -rf foolscap" after pulling this change, because otherwise the leftover .pyc files are likely to cause spurious test failures. (#250, #251) ** partial IPv6 support Foolscap's outbound connections now use HostnameEndpoint, which means that connection hints which contain DNS names which map to AAAA (and maybe A6) records should successfully connect to those IPv6 addresses. There is not yet any support to *listen* on IPv6 ports, so this probably does not enable IPv6 completely. But a client running this release may be able to connect to server running some future IPv6-capable release and advertising v6-based hostnames. (#155)
2016-04-13 20:19:49 +02:00
${PYSITELIB}/${EGG_INFODIR}/entry_points.txt
Import py26-foolscap-0.5.1 as net/py-foolscap. This is a ground-up rewrite of Perspective Broker, which itself is Twisted's native RPC/RMI protocol (Remote Procedure Call / Remote Method Invocation). If you have control of both ends of the wire, and are thus not constrained to use some other protocol like HTTP/XMLRPC/CORBA/etc, you might consider using Foolscap. Fundamentally, Foolscap allows you to make a python object in one process available to code in other processes, which means you can invoke its methods remotely. This includes a data serialization layer to convey the object graphs for the arguments and the eventual response, and an object reference system to keep track of which objects you are connecting to. It uses a capability-based security model, such that once you create a non-public object, it is only accessible to clients to whom you've given the (unguessable) FURL. You can of course publish world-visible objects that have well-known FURLs.
2010-07-23 23:45:52 +02:00
${PYSITELIB}/${EGG_INFODIR}/requires.txt
${PYSITELIB}/${EGG_INFODIR}/top_level.txt
${PYSITELIB}/foolscap/__init__.py
${PYSITELIB}/foolscap/__init__.pyc
${PYSITELIB}/foolscap/__init__.pyo
${PYSITELIB}/foolscap/_version.py
${PYSITELIB}/foolscap/_version.pyc
${PYSITELIB}/foolscap/_version.pyo
${PYSITELIB}/foolscap/api.py
${PYSITELIB}/foolscap/api.pyc
${PYSITELIB}/foolscap/api.pyo
${PYSITELIB}/foolscap/appserver/__init__.py
${PYSITELIB}/foolscap/appserver/__init__.pyc
${PYSITELIB}/foolscap/appserver/__init__.pyo
${PYSITELIB}/foolscap/appserver/cli.py
${PYSITELIB}/foolscap/appserver/cli.pyc
${PYSITELIB}/foolscap/appserver/cli.pyo
${PYSITELIB}/foolscap/appserver/client.py
${PYSITELIB}/foolscap/appserver/client.pyc
${PYSITELIB}/foolscap/appserver/client.pyo
${PYSITELIB}/foolscap/appserver/server.py
${PYSITELIB}/foolscap/appserver/server.pyc
${PYSITELIB}/foolscap/appserver/server.pyo
${PYSITELIB}/foolscap/appserver/services.py
${PYSITELIB}/foolscap/appserver/services.pyc
${PYSITELIB}/foolscap/appserver/services.pyo
${PYSITELIB}/foolscap/banana.py
${PYSITELIB}/foolscap/banana.pyc
${PYSITELIB}/foolscap/banana.pyo
${PYSITELIB}/foolscap/base32.py
${PYSITELIB}/foolscap/base32.pyc
${PYSITELIB}/foolscap/base32.pyo
${PYSITELIB}/foolscap/broker.py
${PYSITELIB}/foolscap/broker.pyc
${PYSITELIB}/foolscap/broker.pyo
${PYSITELIB}/foolscap/call.py
${PYSITELIB}/foolscap/call.pyc
${PYSITELIB}/foolscap/call.pyo
Update to 0.9.1: * Release 0.9.1 (21-Sep-2015) Point release to deal with PyPI upload problems. No code changes. * Release 0.9.0 (21-Sep-2015) ** Plugins for Connection Handlers (#236) New types of connection hints can now be used, by installing a suitable connection handler into the Tub. These hints could point to I2P servers or Tor hidden-service (.onion) addresses. The built-in TCP handler can be replaced entirely to protect a client's IP address by routing all connections through Tor. Implementation of these plugins are left as exercise for the reader: Foolscap only provides the built-in "DefaultTCP" handler. See doc/connection-handlers.rst for details. ** Shared Listeners are removed (#239) Until this version, it was possible to create a single Listener that serviced multiple Tubs (by passing the Listener returned from `l=tubA.listenOn(where)` into `tubB.listenOn(l)`). This seemed useful a long time ago, but in fact was not, and the implementation caused irreparable problems that were exposed while testing the new connection handlers. So support for shared Listeners has been removed: Tubs can still use multiple Listeners, but each Listener now services at most one Tub. In particular, `Tub.listenOn()` now only accepts a string, not a Listener instance. Note that relays and redirects are still on the roadmap, but neither feature requires sharing a Listener between multiple local Tubs. ** Extended-Form Connection Hints are removed Support for extended-form connection hints has been removed. These were hints with explicit key names like "tcp:host=example.org:port=12345", or "tcp:example.org:timeout=30". They were added in the 0.7.0 release, but since then we've realized that this is power that should not be granted to external FURL providers. The parser now only accepts "tcp:example.org:12345" and "example.org:12345". Foolscap has never particularly encouraged applications to call Tub.setLocation() with anything other than these two forms, so we do not expect any compatibility problems. ** Option to Disable Gifts (#126) "Gifts", more precisely known as "third-party reference introductions", occur when one Tub sends you a message that includes a reference to some object on a third Tub. This allows references to be passed around transparently, without regard to which Tub they live on (yours, mine, or theirs), but allows other Tubs to cause you to create network connections to hosts and ports of their choosing. If this bothers you, the new `tub.setOption("accept-gifts", False)` option instructs your Tub to reject these third-party references, causing the calls that used them to signal a Violation error instead. ** Unreachable Tubs now fully supported (#208) Unreachable "client-only" Tubs can be created by simply not calling either `tub.listenOn()` nor `tub.setLocation()`. These Tubs can make outbound connections, but will not accept inbound ones. `tub.registerReference()` will throw an error, and Gifts delivered to third parties will not work. Previous versions suggested using `tub.setLocation("")`: this is no longer recommended. ** new util.allocate_tcp_port() function To support a future deprecation of `Tub.listenOn("tcp:0")`, the new allocate_tcp_port() function was added to return (synchronously) a currently-unused TCP port integer. This can be used during app configuration to decide on a listening port, which can then be passed into `Tub.listenOn("tcp:%d" % portnum)`. This may allow Tub.setLocation() to be called *before* the reactor is started, simplifying application startup code (this also requires a suitable hostname or IP address, which is a separate issue). ** Packaging/Dependency Changes Foolscap now requires Twisted 10.1.0 or newer, to use Endpoints and connection handler plugins. Foolscap's logging system (specifically the twisted-to-foolscap bridge) is now compatible with Twisted-15.2.0. The previous version had problems with the new contents of twisted.logger's "eventDict" objects. (#235)
2015-09-30 21:24:35 +02:00
${PYSITELIB}/foolscap/connection.py
${PYSITELIB}/foolscap/connection.pyc
${PYSITELIB}/foolscap/connection.pyo
Updated py-foolscap to 0.12.2. * Release 0.12.2 (28-Aug-2016) ** Improved Tor Connection Handler The `tor.control_endpoint` connection handler now properly handles the config.SocksPort response provided by the debian Tor daemon (and possibly others), which included a confusing unix-domain socket in its response. The `tor.socks_port` handler was changed to accept both hostname and port number. Using anything but "localhost" or "127.0.0.1" is highly discouraged, as it would reveal your IP address to (possibly hostile) external hosts. This change was made to support applications (e.g. Tahoe-LAFS) which accept endpoint strings to configure socks_port, but then parse them and reject anything but TCP endpoints (to match Foolscap's current limitations). Such applications ought to warn their users to use only localhost. * Release 0.12.1 (20-Aug-2016) ** Connection Handlers for SOCKS, Tor, I2P Foolscap now includes importable connection handlers for SOCKS(5a), Tor, and I2P. #242, #246, #261 These handlers require additional supporting libraries, so they must be imported separately, and a setuptools "extra feature" declaration must be used to ask for the supporting libs. For example, applications which want to use `tor:` hints (on a host with a Tor daemon running) should have a setup.py with: install_requires=["foolscap[tor]"], and the Tub setup code should do: from foolscap.connections import tor tub.addConnectionHintHandler("tor", tor.default_socks()) Full examples and docs are available in docs/connection-handlers.rst. The default connection-negotiation timeout was increased from 60s to 120s, to accomodate tor/i2p daemon startup times. * Release 0.12.0 (20-Jul-2016) ** API changes: no more automatic configuration Foolscap has moved from automatic listener configuration (randomly-allocated TCP ports, automatically-determined IP address) to using more predictable manual configuration. In our experience, the automatic configuration only worked on hosts which had external IP addresses, which (sadly) is not the case for most computers attached to the modern internet. #252 Applications must now explicitly provide Foolscap with port numbers (for Tub.listenOn) and hostnames (for Tub.setLocation). Applications are encouraged to give users configuration controls to teach Foolscap what hostname and port number it should advertise to external hosts in the FURLs it creates. See https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2773 for ideas. The specific API changes were: - Tub.setLocationAutomatically() has been deprecated - Listener.getPortnum() has been deprecated - calling Tub.listenOn("tcp:0") is also deprecated: callers should allocate a port themselves (the foolscap.util.allocate_tcp_port utility function, which does not block, has been added for this purpose). Foolscap tools like "flappserver create" and "flogtool create-gatherer" will no longer try to deduce their external IP address in an attempt to build externally-reachable FURLs, and will no longer accept "tcp:0" as a listening port (they now default to specific port numbers). Instead, they have --location= and --port arguments. The user must provide '--location' with a connection-hint string like 'tcp:hostname.example.org:3117' (which is put into the server's FURLs). This must match the corresponding '--port' argument, if provided. - for all tools, if '--port' is provided, it must not be tcp:0 - 'flappserver create' now requires --location, and '--port' defaults to tcp:3116 - 'flogtool create-gatherer' requires --location, default port is tcp:3117 - 'flogtool create-incident-gatherer' does too, default is tcp:3118 For backwards-compatibility, old flappservers will have "tcp:0" written into their "BASEDIR/port" file, and an empty string in "BASEDIR/location": these must then be edited to allow the flappserver to start. For example, write "tcp:12345" into "BASEDIR/port" to assign a portnumber, and "tcp:HOSTNAME:12345" into "BASEDIR/location" to expose it in the generated FURL. ** Other API changes Tub.listenOn() now takes a string or an Endpoint (something that implements twisted.internet.interfaces.IStreamServerEndpoint). This makes it possible to listen on non-IPv4 sockets (e.g. IPv6-only sockets, or unix-domain sockets, or more exotic endpoints), as long as Tub.setLocation() is set to something which the other end's connection handlers can deal with. #203 #243 The "DefaultTCP" handler (which manages normal "tcp:HOST:PORT" connection hints) has been moved to foolscap.connections.tcp . This makes room for new Tor/I2P/SOCKS handlers to live in e.g. foolscap.connections.tor . #260 Connection handlers are now allowed to return a Deferred from hint_to_endpoint(), which should make some handlers easier to write. #262 Note that RemoteReference.notifyOnDisconnect() will be deprecated in the next release (once all internal uses have been removed from Foolscap). Applications should stop using it as soon as possible. #42 #140 #207 ** Compatibility Changes This release removes support for the old (py2.4) "sets" module. This was retained to support applications which were trying to maintain py2.4 compatibility, but it's been so long since this was necessary, it's time to remove it. ** Other Changes The internal `allocate_tcp_port()` function was fixed: unexpected kernel behavior meant that sometimes it would return a port that was actually in use. This caused unit tests to fail randomly about 5% of the time. #258 IPv6 support is nearly complete: listening on a plain TCP port will typically accept connections via both IPv4 and IPv6, and the DefaultTCP handler will do a hostname lookup that can use both A and AAAA records. So as long as your server has a DNS entry that points at its IPv6 address, and you provide the hostname to Tub.setLocation(), Foolscap will connect over IPv6. There is one piece missing for complete support: the DefaultTCP connection handler must be modified to accept square-bracketed numeric IPv6 addresses, for rare situations where the host has a known (stable) IPv6 address, but no DNS name.
2016-09-01 18:54:32 +02:00
${PYSITELIB}/foolscap/connections/__init__.py
${PYSITELIB}/foolscap/connections/__init__.pyc
${PYSITELIB}/foolscap/connections/__init__.pyo
${PYSITELIB}/foolscap/connections/i2p.py
${PYSITELIB}/foolscap/connections/i2p.pyc
${PYSITELIB}/foolscap/connections/i2p.pyo
${PYSITELIB}/foolscap/connections/socks.py
${PYSITELIB}/foolscap/connections/socks.pyc
${PYSITELIB}/foolscap/connections/socks.pyo
${PYSITELIB}/foolscap/connections/tcp.py
${PYSITELIB}/foolscap/connections/tcp.pyc
${PYSITELIB}/foolscap/connections/tcp.pyo
${PYSITELIB}/foolscap/connections/tor.py
${PYSITELIB}/foolscap/connections/tor.pyc
${PYSITELIB}/foolscap/connections/tor.pyo
Import py26-foolscap-0.5.1 as net/py-foolscap. This is a ground-up rewrite of Perspective Broker, which itself is Twisted's native RPC/RMI protocol (Remote Procedure Call / Remote Method Invocation). If you have control of both ends of the wire, and are thus not constrained to use some other protocol like HTTP/XMLRPC/CORBA/etc, you might consider using Foolscap. Fundamentally, Foolscap allows you to make a python object in one process available to code in other processes, which means you can invoke its methods remotely. This includes a data serialization layer to convey the object graphs for the arguments and the eventual response, and an object reference system to keep track of which objects you are connecting to. It uses a capability-based security model, such that once you create a non-public object, it is only accessible to clients to whom you've given the (unguessable) FURL. You can of course publish world-visible objects that have well-known FURLs.
2010-07-23 23:45:52 +02:00
${PYSITELIB}/foolscap/constraint.py
${PYSITELIB}/foolscap/constraint.pyc
${PYSITELIB}/foolscap/constraint.pyo
${PYSITELIB}/foolscap/copyable.py
${PYSITELIB}/foolscap/copyable.pyc
${PYSITELIB}/foolscap/copyable.pyo
${PYSITELIB}/foolscap/crypto.py
${PYSITELIB}/foolscap/crypto.pyc
${PYSITELIB}/foolscap/crypto.pyo
${PYSITELIB}/foolscap/eventual.py
${PYSITELIB}/foolscap/eventual.pyc
${PYSITELIB}/foolscap/eventual.pyo
Update to 0.9.1: * Release 0.9.1 (21-Sep-2015) Point release to deal with PyPI upload problems. No code changes. * Release 0.9.0 (21-Sep-2015) ** Plugins for Connection Handlers (#236) New types of connection hints can now be used, by installing a suitable connection handler into the Tub. These hints could point to I2P servers or Tor hidden-service (.onion) addresses. The built-in TCP handler can be replaced entirely to protect a client's IP address by routing all connections through Tor. Implementation of these plugins are left as exercise for the reader: Foolscap only provides the built-in "DefaultTCP" handler. See doc/connection-handlers.rst for details. ** Shared Listeners are removed (#239) Until this version, it was possible to create a single Listener that serviced multiple Tubs (by passing the Listener returned from `l=tubA.listenOn(where)` into `tubB.listenOn(l)`). This seemed useful a long time ago, but in fact was not, and the implementation caused irreparable problems that were exposed while testing the new connection handlers. So support for shared Listeners has been removed: Tubs can still use multiple Listeners, but each Listener now services at most one Tub. In particular, `Tub.listenOn()` now only accepts a string, not a Listener instance. Note that relays and redirects are still on the roadmap, but neither feature requires sharing a Listener between multiple local Tubs. ** Extended-Form Connection Hints are removed Support for extended-form connection hints has been removed. These were hints with explicit key names like "tcp:host=example.org:port=12345", or "tcp:example.org:timeout=30". They were added in the 0.7.0 release, but since then we've realized that this is power that should not be granted to external FURL providers. The parser now only accepts "tcp:example.org:12345" and "example.org:12345". Foolscap has never particularly encouraged applications to call Tub.setLocation() with anything other than these two forms, so we do not expect any compatibility problems. ** Option to Disable Gifts (#126) "Gifts", more precisely known as "third-party reference introductions", occur when one Tub sends you a message that includes a reference to some object on a third Tub. This allows references to be passed around transparently, without regard to which Tub they live on (yours, mine, or theirs), but allows other Tubs to cause you to create network connections to hosts and ports of their choosing. If this bothers you, the new `tub.setOption("accept-gifts", False)` option instructs your Tub to reject these third-party references, causing the calls that used them to signal a Violation error instead. ** Unreachable Tubs now fully supported (#208) Unreachable "client-only" Tubs can be created by simply not calling either `tub.listenOn()` nor `tub.setLocation()`. These Tubs can make outbound connections, but will not accept inbound ones. `tub.registerReference()` will throw an error, and Gifts delivered to third parties will not work. Previous versions suggested using `tub.setLocation("")`: this is no longer recommended. ** new util.allocate_tcp_port() function To support a future deprecation of `Tub.listenOn("tcp:0")`, the new allocate_tcp_port() function was added to return (synchronously) a currently-unused TCP port integer. This can be used during app configuration to decide on a listening port, which can then be passed into `Tub.listenOn("tcp:%d" % portnum)`. This may allow Tub.setLocation() to be called *before* the reactor is started, simplifying application startup code (this also requires a suitable hostname or IP address, which is a separate issue). ** Packaging/Dependency Changes Foolscap now requires Twisted 10.1.0 or newer, to use Endpoints and connection handler plugins. Foolscap's logging system (specifically the twisted-to-foolscap bridge) is now compatible with Twisted-15.2.0. The previous version had problems with the new contents of twisted.logger's "eventDict" objects. (#235)
2015-09-30 21:24:35 +02:00
${PYSITELIB}/foolscap/furl.py
${PYSITELIB}/foolscap/furl.pyc
${PYSITELIB}/foolscap/furl.pyo
Updated py-foolscap to 0.12.5. * Release 0.12.5 (07-Dec-2016) ** Connection Status Reporting This release adds an object named `ConnectionInfo`, which encapsulates information about a connection (both progress while being established, and the outcome once connected). This includes which connection hint was successful, what happened with the other hints, which handlers were used for each, and when the connection was made or lost. To get one of these, use `tub.getConnectionInfoForFURL(furl)` any time after `getReference()` is called, or `rref.getConnectionInfo()` after it resolves. #267 It also adds `ReconnectionInfo`, a similar object for Reconnectors. These capture the state of reconnection process (trying, established, waiting), and will provide a `ConnectionInfo` for the most recent (possibly successful) connection attempt. The API is `reconnector.getReconnectionInfo()`. #268 For details, see "Connection Progress/Status" and "Reconnector Status" in `doc/using-foolscap.rst`. ** Connection Handler API Changes To support `ConnectionInfo`, the Connection Handler API was changed. The one backwards-incompatible change was that the `hint_to_endpoint()` method now takes a third argument, to update the status as the handler makes progress. External handler functions will need to be modified to accept this new argument, and applications which use them should declare a dependency upon the latest Foolscap version, to avoid runtime breakage. Several backwards-compatible changes were made too: handlers can provide a `describe()` method (which feeds `ConnectionInfo.connectionHandlers`), and they can now set a special attribute on any exception they raise, to further influence the status string. In addition, the `tor.control_endpoint_maker()` handler now accepts an optional second argument, which causes the maker function to be called with a additional `update_status` argument. This backwards-compatible change allows the maker function to influence the `ConnectionInfo` status too. The Tor connection handler was enhanced to report distinct statuses for the different phases of connection: launching a new copy of Tor, connecting to an existing Tor daemon, etc. ** Minor Fixes Foolscap-0.12.0 broke `flappserver create`, causing the command to hang rather than exiting cleanly (although the flappserver directory itself was probably created properly). This release finally fixes it. #271
2016-12-12 15:27:39 +01:00
${PYSITELIB}/foolscap/info.py
${PYSITELIB}/foolscap/info.pyc
${PYSITELIB}/foolscap/info.pyo
Import py26-foolscap-0.5.1 as net/py-foolscap. This is a ground-up rewrite of Perspective Broker, which itself is Twisted's native RPC/RMI protocol (Remote Procedure Call / Remote Method Invocation). If you have control of both ends of the wire, and are thus not constrained to use some other protocol like HTTP/XMLRPC/CORBA/etc, you might consider using Foolscap. Fundamentally, Foolscap allows you to make a python object in one process available to code in other processes, which means you can invoke its methods remotely. This includes a data serialization layer to convey the object graphs for the arguments and the eventual response, and an object reference system to keep track of which objects you are connecting to. It uses a capability-based security model, such that once you create a non-public object, it is only accessible to clients to whom you've given the (unguessable) FURL. You can of course publish world-visible objects that have well-known FURLs.
2010-07-23 23:45:52 +02:00
${PYSITELIB}/foolscap/ipb.py
${PYSITELIB}/foolscap/ipb.pyc
${PYSITELIB}/foolscap/ipb.pyo
${PYSITELIB}/foolscap/logging/__init__.py
${PYSITELIB}/foolscap/logging/__init__.pyc
${PYSITELIB}/foolscap/logging/__init__.pyo
${PYSITELIB}/foolscap/logging/app_versions.py
${PYSITELIB}/foolscap/logging/app_versions.pyc
${PYSITELIB}/foolscap/logging/app_versions.pyo
${PYSITELIB}/foolscap/logging/cli.py
${PYSITELIB}/foolscap/logging/cli.pyc
${PYSITELIB}/foolscap/logging/cli.pyo
${PYSITELIB}/foolscap/logging/dumper.py
${PYSITELIB}/foolscap/logging/dumper.pyc
${PYSITELIB}/foolscap/logging/dumper.pyo
${PYSITELIB}/foolscap/logging/filter.py
${PYSITELIB}/foolscap/logging/filter.pyc
${PYSITELIB}/foolscap/logging/filter.pyo
Update py-foolscap to 0.10.0: * Release 0.10.0 (15-Jan-2015) ** Compatibility Fixes This release is compatible with Twisted-15.3.0 through 15.5.0. A change in 15.3.0 triggered a bug in Foolscap which produced a somewhat-infinite series of log messages when run under `twistd`. This release fixes that bug, and slightly changes the semantics of calling `log.msg()` with additional parameters. (#244) Foolscap no longer claims compatibility with python-2.6.x . Twisted-15.5.0 was the last release to offer 2.6 support, and subsequent releases actively throw errors when run against 2.6, so we've turned off Foolscap's automated testing for 2.6. It may remain compatible by accident for a while. (#245)
2016-01-19 00:03:03 +01:00
${PYSITELIB}/foolscap/logging/flogfile.py
${PYSITELIB}/foolscap/logging/flogfile.pyc
${PYSITELIB}/foolscap/logging/flogfile.pyo
Import py26-foolscap-0.5.1 as net/py-foolscap. This is a ground-up rewrite of Perspective Broker, which itself is Twisted's native RPC/RMI protocol (Remote Procedure Call / Remote Method Invocation). If you have control of both ends of the wire, and are thus not constrained to use some other protocol like HTTP/XMLRPC/CORBA/etc, you might consider using Foolscap. Fundamentally, Foolscap allows you to make a python object in one process available to code in other processes, which means you can invoke its methods remotely. This includes a data serialization layer to convey the object graphs for the arguments and the eventual response, and an object reference system to keep track of which objects you are connecting to. It uses a capability-based security model, such that once you create a non-public object, it is only accessible to clients to whom you've given the (unguessable) FURL. You can of course publish world-visible objects that have well-known FURLs.
2010-07-23 23:45:52 +02:00
${PYSITELIB}/foolscap/logging/gatherer.py
${PYSITELIB}/foolscap/logging/gatherer.pyc
${PYSITELIB}/foolscap/logging/gatherer.pyo
${PYSITELIB}/foolscap/logging/incident.py
${PYSITELIB}/foolscap/logging/incident.pyc
${PYSITELIB}/foolscap/logging/incident.pyo
${PYSITELIB}/foolscap/logging/interfaces.py
${PYSITELIB}/foolscap/logging/interfaces.pyc
${PYSITELIB}/foolscap/logging/interfaces.pyo
${PYSITELIB}/foolscap/logging/levels.py
${PYSITELIB}/foolscap/logging/levels.pyc
${PYSITELIB}/foolscap/logging/levels.pyo
${PYSITELIB}/foolscap/logging/log.py
${PYSITELIB}/foolscap/logging/log.pyc
${PYSITELIB}/foolscap/logging/log.pyo
${PYSITELIB}/foolscap/logging/publish.py
${PYSITELIB}/foolscap/logging/publish.pyc
${PYSITELIB}/foolscap/logging/publish.pyo
${PYSITELIB}/foolscap/logging/tail.py
${PYSITELIB}/foolscap/logging/tail.pyc
${PYSITELIB}/foolscap/logging/tail.pyo
${PYSITELIB}/foolscap/logging/web.py
${PYSITELIB}/foolscap/logging/web.pyc
${PYSITELIB}/foolscap/logging/web.pyo
${PYSITELIB}/foolscap/negotiate.py
${PYSITELIB}/foolscap/negotiate.pyc
${PYSITELIB}/foolscap/negotiate.pyo
${PYSITELIB}/foolscap/observer.py
${PYSITELIB}/foolscap/observer.pyc
${PYSITELIB}/foolscap/observer.pyo
${PYSITELIB}/foolscap/pb.py
${PYSITELIB}/foolscap/pb.pyc
${PYSITELIB}/foolscap/pb.pyo
${PYSITELIB}/foolscap/promise.py
${PYSITELIB}/foolscap/promise.pyc
${PYSITELIB}/foolscap/promise.pyo
${PYSITELIB}/foolscap/reconnector.py
${PYSITELIB}/foolscap/reconnector.pyc
${PYSITELIB}/foolscap/reconnector.pyo
${PYSITELIB}/foolscap/referenceable.py
${PYSITELIB}/foolscap/referenceable.pyc
${PYSITELIB}/foolscap/referenceable.pyo
${PYSITELIB}/foolscap/remoteinterface.py
${PYSITELIB}/foolscap/remoteinterface.pyc
${PYSITELIB}/foolscap/remoteinterface.pyo
${PYSITELIB}/foolscap/schema.py
${PYSITELIB}/foolscap/schema.pyc
${PYSITELIB}/foolscap/schema.pyo
${PYSITELIB}/foolscap/slicer.py
${PYSITELIB}/foolscap/slicer.pyc
${PYSITELIB}/foolscap/slicer.pyo
${PYSITELIB}/foolscap/slicers/__init__.py
${PYSITELIB}/foolscap/slicers/__init__.pyc
${PYSITELIB}/foolscap/slicers/__init__.pyo
${PYSITELIB}/foolscap/slicers/allslicers.py
${PYSITELIB}/foolscap/slicers/allslicers.pyc
${PYSITELIB}/foolscap/slicers/allslicers.pyo
${PYSITELIB}/foolscap/slicers/bool.py
${PYSITELIB}/foolscap/slicers/bool.pyc
${PYSITELIB}/foolscap/slicers/bool.pyo
${PYSITELIB}/foolscap/slicers/decimal_slicer.py
${PYSITELIB}/foolscap/slicers/decimal_slicer.pyc
${PYSITELIB}/foolscap/slicers/decimal_slicer.pyo
${PYSITELIB}/foolscap/slicers/dict.py
${PYSITELIB}/foolscap/slicers/dict.pyc
${PYSITELIB}/foolscap/slicers/dict.pyo
${PYSITELIB}/foolscap/slicers/list.py
${PYSITELIB}/foolscap/slicers/list.pyc
${PYSITELIB}/foolscap/slicers/list.pyo
${PYSITELIB}/foolscap/slicers/none.py
${PYSITELIB}/foolscap/slicers/none.pyc
${PYSITELIB}/foolscap/slicers/none.pyo
${PYSITELIB}/foolscap/slicers/root.py
${PYSITELIB}/foolscap/slicers/root.pyc
${PYSITELIB}/foolscap/slicers/root.pyo
${PYSITELIB}/foolscap/slicers/set.py
${PYSITELIB}/foolscap/slicers/set.pyc
${PYSITELIB}/foolscap/slicers/set.pyo
${PYSITELIB}/foolscap/slicers/tuple.py
${PYSITELIB}/foolscap/slicers/tuple.pyc
${PYSITELIB}/foolscap/slicers/tuple.pyo
${PYSITELIB}/foolscap/slicers/unicode.py
${PYSITELIB}/foolscap/slicers/unicode.pyc
${PYSITELIB}/foolscap/slicers/unicode.pyo
${PYSITELIB}/foolscap/slicers/vocab.py
${PYSITELIB}/foolscap/slicers/vocab.pyc
${PYSITELIB}/foolscap/slicers/vocab.pyo
${PYSITELIB}/foolscap/storage.py
${PYSITELIB}/foolscap/storage.pyc
${PYSITELIB}/foolscap/storage.pyo
${PYSITELIB}/foolscap/stringchain.py
${PYSITELIB}/foolscap/stringchain.pyc
${PYSITELIB}/foolscap/stringchain.pyo
${PYSITELIB}/foolscap/test/__init__.py
${PYSITELIB}/foolscap/test/__init__.pyc
${PYSITELIB}/foolscap/test/__init__.pyo
Update to 0.6.3. Note that 0.6.1 really does not work with Twisted in pkgsrc. * Release 0.6.3 (05-Jan-2012) ** Compatibility Fixes This release really is compatible with Twisted-11.1.0 . The previous Foolscap release (0.6.2), despite the changes described below, suffered mild incompatibilites with the new TLS code in the final Twisted-11.1.0 release. The most common symptom is a DirtyReactorError in unit tests that use Tub.stopService() in their tearDown() method (to coordinate shutdown and cleanup). Another symptom is tests overlapping with one another, causing port-already-in-use errors. This incompatibility did not generally affect normal operation, but only impacted unit tests. ** Other Changes The Debian packaging tools in misc/ were removed, as they were pretty stale. These days, both Debian and Ubuntu make their own Foolscap packages. * Release 0.6.2 (15-Oct-2011) ** Compatibility Fixes Foolscap-0.6.2 will be compatible with future versions of Twisted (>11.0.0). The 0.6.1 release will not: a TLS change went into Twisted trunk recently (after the 11.0.0 release) which broke Foolscap 0.6.1 and earlier. This release also fixes a minor incompatibility with newer versions of OpenSSL (0.9.8o was ok, 1.0.0d was not), which caused errors in the test suite (but normal runtime operation) on e.g. Ubuntu 11.10 "Oneiric". ** Git-Over-Foolscap Tools The doc/examples/ directory contains two executables (git-foolscap and git-remote-pb) which, when placed in your $PATH, make it easy to use Foolscap to access a Git repository. These use the flappserver/flappclient tools and let you build a FURL that provides read-only or read-write access to a single repository. This is somewhat like providing SSH access to a repo, but with a much smaller scope: the client will only be able to manipulate the one repository, and gets no other authority on the target system. See the tool's inline comments for usage instructions. ** Minor Fixes Using 'flappserver upload-file FILE1 FILE2 FILE3..' (with three or more files) now correctly uploads all files: previously it only managed to upload the first and last. 'flappserver' argument handling was improved slightly. A workaround was added to handle a Twisted stdio-closing bug which affected flappserver's run-command function and broke the git-foolscap tool. Several changes were made for the benefit of Windows: log filenames all use hyphens (not colons), log filtering tools tolerate the lack of atomic-rename filesystem operations, and some unixisms in the test suite were removed. The Tub.setLogGathererFURL() method can now accept a list (iterable) of log gatherer FURLs, not just a single one.
2012-05-25 13:22:58 +02:00
${PYSITELIB}/foolscap/test/apphelper.py
${PYSITELIB}/foolscap/test/apphelper.pyc
${PYSITELIB}/foolscap/test/apphelper.pyo
Import py26-foolscap-0.5.1 as net/py-foolscap. This is a ground-up rewrite of Perspective Broker, which itself is Twisted's native RPC/RMI protocol (Remote Procedure Call / Remote Method Invocation). If you have control of both ends of the wire, and are thus not constrained to use some other protocol like HTTP/XMLRPC/CORBA/etc, you might consider using Foolscap. Fundamentally, Foolscap allows you to make a python object in one process available to code in other processes, which means you can invoke its methods remotely. This includes a data serialization layer to convey the object graphs for the arguments and the eventual response, and an object reference system to keep track of which objects you are connecting to. It uses a capability-based security model, such that once you create a non-public object, it is only accessible to clients to whom you've given the (unguessable) FURL. You can of course publish world-visible objects that have well-known FURLs.
2010-07-23 23:45:52 +02:00
${PYSITELIB}/foolscap/test/bench_banana.py
${PYSITELIB}/foolscap/test/bench_banana.pyc
${PYSITELIB}/foolscap/test/bench_banana.pyo
Updated py-foolscap to 0.12.2. * Release 0.12.2 (28-Aug-2016) ** Improved Tor Connection Handler The `tor.control_endpoint` connection handler now properly handles the config.SocksPort response provided by the debian Tor daemon (and possibly others), which included a confusing unix-domain socket in its response. The `tor.socks_port` handler was changed to accept both hostname and port number. Using anything but "localhost" or "127.0.0.1" is highly discouraged, as it would reveal your IP address to (possibly hostile) external hosts. This change was made to support applications (e.g. Tahoe-LAFS) which accept endpoint strings to configure socks_port, but then parse them and reject anything but TCP endpoints (to match Foolscap's current limitations). Such applications ought to warn their users to use only localhost. * Release 0.12.1 (20-Aug-2016) ** Connection Handlers for SOCKS, Tor, I2P Foolscap now includes importable connection handlers for SOCKS(5a), Tor, and I2P. #242, #246, #261 These handlers require additional supporting libraries, so they must be imported separately, and a setuptools "extra feature" declaration must be used to ask for the supporting libs. For example, applications which want to use `tor:` hints (on a host with a Tor daemon running) should have a setup.py with: install_requires=["foolscap[tor]"], and the Tub setup code should do: from foolscap.connections import tor tub.addConnectionHintHandler("tor", tor.default_socks()) Full examples and docs are available in docs/connection-handlers.rst. The default connection-negotiation timeout was increased from 60s to 120s, to accomodate tor/i2p daemon startup times. * Release 0.12.0 (20-Jul-2016) ** API changes: no more automatic configuration Foolscap has moved from automatic listener configuration (randomly-allocated TCP ports, automatically-determined IP address) to using more predictable manual configuration. In our experience, the automatic configuration only worked on hosts which had external IP addresses, which (sadly) is not the case for most computers attached to the modern internet. #252 Applications must now explicitly provide Foolscap with port numbers (for Tub.listenOn) and hostnames (for Tub.setLocation). Applications are encouraged to give users configuration controls to teach Foolscap what hostname and port number it should advertise to external hosts in the FURLs it creates. See https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2773 for ideas. The specific API changes were: - Tub.setLocationAutomatically() has been deprecated - Listener.getPortnum() has been deprecated - calling Tub.listenOn("tcp:0") is also deprecated: callers should allocate a port themselves (the foolscap.util.allocate_tcp_port utility function, which does not block, has been added for this purpose). Foolscap tools like "flappserver create" and "flogtool create-gatherer" will no longer try to deduce their external IP address in an attempt to build externally-reachable FURLs, and will no longer accept "tcp:0" as a listening port (they now default to specific port numbers). Instead, they have --location= and --port arguments. The user must provide '--location' with a connection-hint string like 'tcp:hostname.example.org:3117' (which is put into the server's FURLs). This must match the corresponding '--port' argument, if provided. - for all tools, if '--port' is provided, it must not be tcp:0 - 'flappserver create' now requires --location, and '--port' defaults to tcp:3116 - 'flogtool create-gatherer' requires --location, default port is tcp:3117 - 'flogtool create-incident-gatherer' does too, default is tcp:3118 For backwards-compatibility, old flappservers will have "tcp:0" written into their "BASEDIR/port" file, and an empty string in "BASEDIR/location": these must then be edited to allow the flappserver to start. For example, write "tcp:12345" into "BASEDIR/port" to assign a portnumber, and "tcp:HOSTNAME:12345" into "BASEDIR/location" to expose it in the generated FURL. ** Other API changes Tub.listenOn() now takes a string or an Endpoint (something that implements twisted.internet.interfaces.IStreamServerEndpoint). This makes it possible to listen on non-IPv4 sockets (e.g. IPv6-only sockets, or unix-domain sockets, or more exotic endpoints), as long as Tub.setLocation() is set to something which the other end's connection handlers can deal with. #203 #243 The "DefaultTCP" handler (which manages normal "tcp:HOST:PORT" connection hints) has been moved to foolscap.connections.tcp . This makes room for new Tor/I2P/SOCKS handlers to live in e.g. foolscap.connections.tor . #260 Connection handlers are now allowed to return a Deferred from hint_to_endpoint(), which should make some handlers easier to write. #262 Note that RemoteReference.notifyOnDisconnect() will be deprecated in the next release (once all internal uses have been removed from Foolscap). Applications should stop using it as soon as possible. #42 #140 #207 ** Compatibility Changes This release removes support for the old (py2.4) "sets" module. This was retained to support applications which were trying to maintain py2.4 compatibility, but it's been so long since this was necessary, it's time to remove it. ** Other Changes The internal `allocate_tcp_port()` function was fixed: unexpected kernel behavior meant that sometimes it would return a port that was actually in use. This caused unit tests to fail randomly about 5% of the time. #258 IPv6 support is nearly complete: listening on a plain TCP port will typically accept connections via both IPv4 and IPv6, and the DefaultTCP handler will do a hostname lookup that can use both A and AAAA records. So as long as your server has a DNS entry that points at its IPv6 address, and you provide the hostname to Tub.setLocation(), Foolscap will connect over IPv6. There is one piece missing for complete support: the DefaultTCP connection handler must be modified to accept square-bracketed numeric IPv6 addresses, for rare situations where the host has a known (stable) IPv6 address, but no DNS name.
2016-09-01 18:54:32 +02:00
${PYSITELIB}/foolscap/test/check-connections-client.py
${PYSITELIB}/foolscap/test/check-connections-client.pyc
${PYSITELIB}/foolscap/test/check-connections-client.pyo
${PYSITELIB}/foolscap/test/check-connections-server.py
${PYSITELIB}/foolscap/test/check-connections-server.pyc
${PYSITELIB}/foolscap/test/check-connections-server.pyo
Import py26-foolscap-0.5.1 as net/py-foolscap. This is a ground-up rewrite of Perspective Broker, which itself is Twisted's native RPC/RMI protocol (Remote Procedure Call / Remote Method Invocation). If you have control of both ends of the wire, and are thus not constrained to use some other protocol like HTTP/XMLRPC/CORBA/etc, you might consider using Foolscap. Fundamentally, Foolscap allows you to make a python object in one process available to code in other processes, which means you can invoke its methods remotely. This includes a data serialization layer to convey the object graphs for the arguments and the eventual response, and an object reference system to keep track of which objects you are connecting to. It uses a capability-based security model, such that once you create a non-public object, it is only accessible to clients to whom you've given the (unguessable) FURL. You can of course publish world-visible objects that have well-known FURLs.
2010-07-23 23:45:52 +02:00
${PYSITELIB}/foolscap/test/common.py
${PYSITELIB}/foolscap/test/common.pyc
${PYSITELIB}/foolscap/test/common.pyo
Updated py-foolscap to 0.12.2. * Release 0.12.2 (28-Aug-2016) ** Improved Tor Connection Handler The `tor.control_endpoint` connection handler now properly handles the config.SocksPort response provided by the debian Tor daemon (and possibly others), which included a confusing unix-domain socket in its response. The `tor.socks_port` handler was changed to accept both hostname and port number. Using anything but "localhost" or "127.0.0.1" is highly discouraged, as it would reveal your IP address to (possibly hostile) external hosts. This change was made to support applications (e.g. Tahoe-LAFS) which accept endpoint strings to configure socks_port, but then parse them and reject anything but TCP endpoints (to match Foolscap's current limitations). Such applications ought to warn their users to use only localhost. * Release 0.12.1 (20-Aug-2016) ** Connection Handlers for SOCKS, Tor, I2P Foolscap now includes importable connection handlers for SOCKS(5a), Tor, and I2P. #242, #246, #261 These handlers require additional supporting libraries, so they must be imported separately, and a setuptools "extra feature" declaration must be used to ask for the supporting libs. For example, applications which want to use `tor:` hints (on a host with a Tor daemon running) should have a setup.py with: install_requires=["foolscap[tor]"], and the Tub setup code should do: from foolscap.connections import tor tub.addConnectionHintHandler("tor", tor.default_socks()) Full examples and docs are available in docs/connection-handlers.rst. The default connection-negotiation timeout was increased from 60s to 120s, to accomodate tor/i2p daemon startup times. * Release 0.12.0 (20-Jul-2016) ** API changes: no more automatic configuration Foolscap has moved from automatic listener configuration (randomly-allocated TCP ports, automatically-determined IP address) to using more predictable manual configuration. In our experience, the automatic configuration only worked on hosts which had external IP addresses, which (sadly) is not the case for most computers attached to the modern internet. #252 Applications must now explicitly provide Foolscap with port numbers (for Tub.listenOn) and hostnames (for Tub.setLocation). Applications are encouraged to give users configuration controls to teach Foolscap what hostname and port number it should advertise to external hosts in the FURLs it creates. See https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2773 for ideas. The specific API changes were: - Tub.setLocationAutomatically() has been deprecated - Listener.getPortnum() has been deprecated - calling Tub.listenOn("tcp:0") is also deprecated: callers should allocate a port themselves (the foolscap.util.allocate_tcp_port utility function, which does not block, has been added for this purpose). Foolscap tools like "flappserver create" and "flogtool create-gatherer" will no longer try to deduce their external IP address in an attempt to build externally-reachable FURLs, and will no longer accept "tcp:0" as a listening port (they now default to specific port numbers). Instead, they have --location= and --port arguments. The user must provide '--location' with a connection-hint string like 'tcp:hostname.example.org:3117' (which is put into the server's FURLs). This must match the corresponding '--port' argument, if provided. - for all tools, if '--port' is provided, it must not be tcp:0 - 'flappserver create' now requires --location, and '--port' defaults to tcp:3116 - 'flogtool create-gatherer' requires --location, default port is tcp:3117 - 'flogtool create-incident-gatherer' does too, default is tcp:3118 For backwards-compatibility, old flappservers will have "tcp:0" written into their "BASEDIR/port" file, and an empty string in "BASEDIR/location": these must then be edited to allow the flappserver to start. For example, write "tcp:12345" into "BASEDIR/port" to assign a portnumber, and "tcp:HOSTNAME:12345" into "BASEDIR/location" to expose it in the generated FURL. ** Other API changes Tub.listenOn() now takes a string or an Endpoint (something that implements twisted.internet.interfaces.IStreamServerEndpoint). This makes it possible to listen on non-IPv4 sockets (e.g. IPv6-only sockets, or unix-domain sockets, or more exotic endpoints), as long as Tub.setLocation() is set to something which the other end's connection handlers can deal with. #203 #243 The "DefaultTCP" handler (which manages normal "tcp:HOST:PORT" connection hints) has been moved to foolscap.connections.tcp . This makes room for new Tor/I2P/SOCKS handlers to live in e.g. foolscap.connections.tor . #260 Connection handlers are now allowed to return a Deferred from hint_to_endpoint(), which should make some handlers easier to write. #262 Note that RemoteReference.notifyOnDisconnect() will be deprecated in the next release (once all internal uses have been removed from Foolscap). Applications should stop using it as soon as possible. #42 #140 #207 ** Compatibility Changes This release removes support for the old (py2.4) "sets" module. This was retained to support applications which were trying to maintain py2.4 compatibility, but it's been so long since this was necessary, it's time to remove it. ** Other Changes The internal `allocate_tcp_port()` function was fixed: unexpected kernel behavior meant that sometimes it would return a port that was actually in use. This caused unit tests to fail randomly about 5% of the time. #258 IPv6 support is nearly complete: listening on a plain TCP port will typically accept connections via both IPv4 and IPv6, and the DefaultTCP handler will do a hostname lookup that can use both A and AAAA records. So as long as your server has a DNS entry that points at its IPv6 address, and you provide the hostname to Tub.setLocation(), Foolscap will connect over IPv6. There is one piece missing for complete support: the DefaultTCP connection handler must be modified to accept square-bracketed numeric IPv6 addresses, for rare situations where the host has a known (stable) IPv6 address, but no DNS name.
2016-09-01 18:54:32 +02:00
${PYSITELIB}/foolscap/test/run_trial.py
${PYSITELIB}/foolscap/test/run_trial.pyc
${PYSITELIB}/foolscap/test/run_trial.pyo
Import py26-foolscap-0.5.1 as net/py-foolscap. This is a ground-up rewrite of Perspective Broker, which itself is Twisted's native RPC/RMI protocol (Remote Procedure Call / Remote Method Invocation). If you have control of both ends of the wire, and are thus not constrained to use some other protocol like HTTP/XMLRPC/CORBA/etc, you might consider using Foolscap. Fundamentally, Foolscap allows you to make a python object in one process available to code in other processes, which means you can invoke its methods remotely. This includes a data serialization layer to convey the object graphs for the arguments and the eventual response, and an object reference system to keep track of which objects you are connecting to. It uses a capability-based security model, such that once you create a non-public object, it is only accessible to clients to whom you've given the (unguessable) FURL. You can of course publish world-visible objects that have well-known FURLs.
2010-07-23 23:45:52 +02:00
${PYSITELIB}/foolscap/test/test__versions.py
${PYSITELIB}/foolscap/test/test__versions.pyc
${PYSITELIB}/foolscap/test/test__versions.pyo
${PYSITELIB}/foolscap/test/test_appserver.py
${PYSITELIB}/foolscap/test/test_appserver.pyc
${PYSITELIB}/foolscap/test/test_appserver.pyo
${PYSITELIB}/foolscap/test/test_banana.py
${PYSITELIB}/foolscap/test/test_banana.pyc
${PYSITELIB}/foolscap/test/test_banana.pyo
${PYSITELIB}/foolscap/test/test_call.py
${PYSITELIB}/foolscap/test/test_call.pyc
${PYSITELIB}/foolscap/test/test_call.pyo
Update to 0.9.1: * Release 0.9.1 (21-Sep-2015) Point release to deal with PyPI upload problems. No code changes. * Release 0.9.0 (21-Sep-2015) ** Plugins for Connection Handlers (#236) New types of connection hints can now be used, by installing a suitable connection handler into the Tub. These hints could point to I2P servers or Tor hidden-service (.onion) addresses. The built-in TCP handler can be replaced entirely to protect a client's IP address by routing all connections through Tor. Implementation of these plugins are left as exercise for the reader: Foolscap only provides the built-in "DefaultTCP" handler. See doc/connection-handlers.rst for details. ** Shared Listeners are removed (#239) Until this version, it was possible to create a single Listener that serviced multiple Tubs (by passing the Listener returned from `l=tubA.listenOn(where)` into `tubB.listenOn(l)`). This seemed useful a long time ago, but in fact was not, and the implementation caused irreparable problems that were exposed while testing the new connection handlers. So support for shared Listeners has been removed: Tubs can still use multiple Listeners, but each Listener now services at most one Tub. In particular, `Tub.listenOn()` now only accepts a string, not a Listener instance. Note that relays and redirects are still on the roadmap, but neither feature requires sharing a Listener between multiple local Tubs. ** Extended-Form Connection Hints are removed Support for extended-form connection hints has been removed. These were hints with explicit key names like "tcp:host=example.org:port=12345", or "tcp:example.org:timeout=30". They were added in the 0.7.0 release, but since then we've realized that this is power that should not be granted to external FURL providers. The parser now only accepts "tcp:example.org:12345" and "example.org:12345". Foolscap has never particularly encouraged applications to call Tub.setLocation() with anything other than these two forms, so we do not expect any compatibility problems. ** Option to Disable Gifts (#126) "Gifts", more precisely known as "third-party reference introductions", occur when one Tub sends you a message that includes a reference to some object on a third Tub. This allows references to be passed around transparently, without regard to which Tub they live on (yours, mine, or theirs), but allows other Tubs to cause you to create network connections to hosts and ports of their choosing. If this bothers you, the new `tub.setOption("accept-gifts", False)` option instructs your Tub to reject these third-party references, causing the calls that used them to signal a Violation error instead. ** Unreachable Tubs now fully supported (#208) Unreachable "client-only" Tubs can be created by simply not calling either `tub.listenOn()` nor `tub.setLocation()`. These Tubs can make outbound connections, but will not accept inbound ones. `tub.registerReference()` will throw an error, and Gifts delivered to third parties will not work. Previous versions suggested using `tub.setLocation("")`: this is no longer recommended. ** new util.allocate_tcp_port() function To support a future deprecation of `Tub.listenOn("tcp:0")`, the new allocate_tcp_port() function was added to return (synchronously) a currently-unused TCP port integer. This can be used during app configuration to decide on a listening port, which can then be passed into `Tub.listenOn("tcp:%d" % portnum)`. This may allow Tub.setLocation() to be called *before* the reactor is started, simplifying application startup code (this also requires a suitable hostname or IP address, which is a separate issue). ** Packaging/Dependency Changes Foolscap now requires Twisted 10.1.0 or newer, to use Endpoints and connection handler plugins. Foolscap's logging system (specifically the twisted-to-foolscap bridge) is now compatible with Twisted-15.2.0. The previous version had problems with the new contents of twisted.logger's "eventDict" objects. (#235)
2015-09-30 21:24:35 +02:00
${PYSITELIB}/foolscap/test/test_connection.py
${PYSITELIB}/foolscap/test/test_connection.pyc
${PYSITELIB}/foolscap/test/test_connection.pyo
Import py26-foolscap-0.5.1 as net/py-foolscap. This is a ground-up rewrite of Perspective Broker, which itself is Twisted's native RPC/RMI protocol (Remote Procedure Call / Remote Method Invocation). If you have control of both ends of the wire, and are thus not constrained to use some other protocol like HTTP/XMLRPC/CORBA/etc, you might consider using Foolscap. Fundamentally, Foolscap allows you to make a python object in one process available to code in other processes, which means you can invoke its methods remotely. This includes a data serialization layer to convey the object graphs for the arguments and the eventual response, and an object reference system to keep track of which objects you are connecting to. It uses a capability-based security model, such that once you create a non-public object, it is only accessible to clients to whom you've given the (unguessable) FURL. You can of course publish world-visible objects that have well-known FURLs.
2010-07-23 23:45:52 +02:00
${PYSITELIB}/foolscap/test/test_copyable.py
${PYSITELIB}/foolscap/test/test_copyable.pyc
${PYSITELIB}/foolscap/test/test_copyable.pyo
${PYSITELIB}/foolscap/test/test_crypto.py
${PYSITELIB}/foolscap/test/test_crypto.pyc
${PYSITELIB}/foolscap/test/test_crypto.pyo
${PYSITELIB}/foolscap/test/test_eventual.py
${PYSITELIB}/foolscap/test/test_eventual.pyc
${PYSITELIB}/foolscap/test/test_eventual.pyo
${PYSITELIB}/foolscap/test/test_gifts.py
${PYSITELIB}/foolscap/test/test_gifts.pyc
${PYSITELIB}/foolscap/test/test_gifts.pyo
Updated py-foolscap to 0.12.5. * Release 0.12.5 (07-Dec-2016) ** Connection Status Reporting This release adds an object named `ConnectionInfo`, which encapsulates information about a connection (both progress while being established, and the outcome once connected). This includes which connection hint was successful, what happened with the other hints, which handlers were used for each, and when the connection was made or lost. To get one of these, use `tub.getConnectionInfoForFURL(furl)` any time after `getReference()` is called, or `rref.getConnectionInfo()` after it resolves. #267 It also adds `ReconnectionInfo`, a similar object for Reconnectors. These capture the state of reconnection process (trying, established, waiting), and will provide a `ConnectionInfo` for the most recent (possibly successful) connection attempt. The API is `reconnector.getReconnectionInfo()`. #268 For details, see "Connection Progress/Status" and "Reconnector Status" in `doc/using-foolscap.rst`. ** Connection Handler API Changes To support `ConnectionInfo`, the Connection Handler API was changed. The one backwards-incompatible change was that the `hint_to_endpoint()` method now takes a third argument, to update the status as the handler makes progress. External handler functions will need to be modified to accept this new argument, and applications which use them should declare a dependency upon the latest Foolscap version, to avoid runtime breakage. Several backwards-compatible changes were made too: handlers can provide a `describe()` method (which feeds `ConnectionInfo.connectionHandlers`), and they can now set a special attribute on any exception they raise, to further influence the status string. In addition, the `tor.control_endpoint_maker()` handler now accepts an optional second argument, which causes the maker function to be called with a additional `update_status` argument. This backwards-compatible change allows the maker function to influence the `ConnectionInfo` status too. The Tor connection handler was enhanced to report distinct statuses for the different phases of connection: launching a new copy of Tor, connecting to an existing Tor daemon, etc. ** Minor Fixes Foolscap-0.12.0 broke `flappserver create`, causing the command to hang rather than exiting cleanly (although the flappserver directory itself was probably created properly). This release finally fixes it. #271
2016-12-12 15:27:39 +01:00
${PYSITELIB}/foolscap/test/test_info.py
${PYSITELIB}/foolscap/test/test_info.pyc
${PYSITELIB}/foolscap/test/test_info.pyo
Import py26-foolscap-0.5.1 as net/py-foolscap. This is a ground-up rewrite of Perspective Broker, which itself is Twisted's native RPC/RMI protocol (Remote Procedure Call / Remote Method Invocation). If you have control of both ends of the wire, and are thus not constrained to use some other protocol like HTTP/XMLRPC/CORBA/etc, you might consider using Foolscap. Fundamentally, Foolscap allows you to make a python object in one process available to code in other processes, which means you can invoke its methods remotely. This includes a data serialization layer to convey the object graphs for the arguments and the eventual response, and an object reference system to keep track of which objects you are connecting to. It uses a capability-based security model, such that once you create a non-public object, it is only accessible to clients to whom you've given the (unguessable) FURL. You can of course publish world-visible objects that have well-known FURLs.
2010-07-23 23:45:52 +02:00
${PYSITELIB}/foolscap/test/test_interfaces.py
${PYSITELIB}/foolscap/test/test_interfaces.pyc
${PYSITELIB}/foolscap/test/test_interfaces.pyo
${PYSITELIB}/foolscap/test/test_keepalive.py
${PYSITELIB}/foolscap/test/test_keepalive.pyc
${PYSITELIB}/foolscap/test/test_keepalive.pyo
Updated py-foolscap to 0.12.2. * Release 0.12.2 (28-Aug-2016) ** Improved Tor Connection Handler The `tor.control_endpoint` connection handler now properly handles the config.SocksPort response provided by the debian Tor daemon (and possibly others), which included a confusing unix-domain socket in its response. The `tor.socks_port` handler was changed to accept both hostname and port number. Using anything but "localhost" or "127.0.0.1" is highly discouraged, as it would reveal your IP address to (possibly hostile) external hosts. This change was made to support applications (e.g. Tahoe-LAFS) which accept endpoint strings to configure socks_port, but then parse them and reject anything but TCP endpoints (to match Foolscap's current limitations). Such applications ought to warn their users to use only localhost. * Release 0.12.1 (20-Aug-2016) ** Connection Handlers for SOCKS, Tor, I2P Foolscap now includes importable connection handlers for SOCKS(5a), Tor, and I2P. #242, #246, #261 These handlers require additional supporting libraries, so they must be imported separately, and a setuptools "extra feature" declaration must be used to ask for the supporting libs. For example, applications which want to use `tor:` hints (on a host with a Tor daemon running) should have a setup.py with: install_requires=["foolscap[tor]"], and the Tub setup code should do: from foolscap.connections import tor tub.addConnectionHintHandler("tor", tor.default_socks()) Full examples and docs are available in docs/connection-handlers.rst. The default connection-negotiation timeout was increased from 60s to 120s, to accomodate tor/i2p daemon startup times. * Release 0.12.0 (20-Jul-2016) ** API changes: no more automatic configuration Foolscap has moved from automatic listener configuration (randomly-allocated TCP ports, automatically-determined IP address) to using more predictable manual configuration. In our experience, the automatic configuration only worked on hosts which had external IP addresses, which (sadly) is not the case for most computers attached to the modern internet. #252 Applications must now explicitly provide Foolscap with port numbers (for Tub.listenOn) and hostnames (for Tub.setLocation). Applications are encouraged to give users configuration controls to teach Foolscap what hostname and port number it should advertise to external hosts in the FURLs it creates. See https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2773 for ideas. The specific API changes were: - Tub.setLocationAutomatically() has been deprecated - Listener.getPortnum() has been deprecated - calling Tub.listenOn("tcp:0") is also deprecated: callers should allocate a port themselves (the foolscap.util.allocate_tcp_port utility function, which does not block, has been added for this purpose). Foolscap tools like "flappserver create" and "flogtool create-gatherer" will no longer try to deduce their external IP address in an attempt to build externally-reachable FURLs, and will no longer accept "tcp:0" as a listening port (they now default to specific port numbers). Instead, they have --location= and --port arguments. The user must provide '--location' with a connection-hint string like 'tcp:hostname.example.org:3117' (which is put into the server's FURLs). This must match the corresponding '--port' argument, if provided. - for all tools, if '--port' is provided, it must not be tcp:0 - 'flappserver create' now requires --location, and '--port' defaults to tcp:3116 - 'flogtool create-gatherer' requires --location, default port is tcp:3117 - 'flogtool create-incident-gatherer' does too, default is tcp:3118 For backwards-compatibility, old flappservers will have "tcp:0" written into their "BASEDIR/port" file, and an empty string in "BASEDIR/location": these must then be edited to allow the flappserver to start. For example, write "tcp:12345" into "BASEDIR/port" to assign a portnumber, and "tcp:HOSTNAME:12345" into "BASEDIR/location" to expose it in the generated FURL. ** Other API changes Tub.listenOn() now takes a string or an Endpoint (something that implements twisted.internet.interfaces.IStreamServerEndpoint). This makes it possible to listen on non-IPv4 sockets (e.g. IPv6-only sockets, or unix-domain sockets, or more exotic endpoints), as long as Tub.setLocation() is set to something which the other end's connection handlers can deal with. #203 #243 The "DefaultTCP" handler (which manages normal "tcp:HOST:PORT" connection hints) has been moved to foolscap.connections.tcp . This makes room for new Tor/I2P/SOCKS handlers to live in e.g. foolscap.connections.tor . #260 Connection handlers are now allowed to return a Deferred from hint_to_endpoint(), which should make some handlers easier to write. #262 Note that RemoteReference.notifyOnDisconnect() will be deprecated in the next release (once all internal uses have been removed from Foolscap). Applications should stop using it as soon as possible. #42 #140 #207 ** Compatibility Changes This release removes support for the old (py2.4) "sets" module. This was retained to support applications which were trying to maintain py2.4 compatibility, but it's been so long since this was necessary, it's time to remove it. ** Other Changes The internal `allocate_tcp_port()` function was fixed: unexpected kernel behavior meant that sometimes it would return a port that was actually in use. This caused unit tests to fail randomly about 5% of the time. #258 IPv6 support is nearly complete: listening on a plain TCP port will typically accept connections via both IPv4 and IPv6, and the DefaultTCP handler will do a hostname lookup that can use both A and AAAA records. So as long as your server has a DNS entry that points at its IPv6 address, and you provide the hostname to Tub.setLocation(), Foolscap will connect over IPv6. There is one piece missing for complete support: the DefaultTCP connection handler must be modified to accept square-bracketed numeric IPv6 addresses, for rare situations where the host has a known (stable) IPv6 address, but no DNS name.
2016-09-01 18:54:32 +02:00
${PYSITELIB}/foolscap/test/test_listener.py
${PYSITELIB}/foolscap/test/test_listener.pyc
${PYSITELIB}/foolscap/test/test_listener.pyo
Import py26-foolscap-0.5.1 as net/py-foolscap. This is a ground-up rewrite of Perspective Broker, which itself is Twisted's native RPC/RMI protocol (Remote Procedure Call / Remote Method Invocation). If you have control of both ends of the wire, and are thus not constrained to use some other protocol like HTTP/XMLRPC/CORBA/etc, you might consider using Foolscap. Fundamentally, Foolscap allows you to make a python object in one process available to code in other processes, which means you can invoke its methods remotely. This includes a data serialization layer to convey the object graphs for the arguments and the eventual response, and an object reference system to keep track of which objects you are connecting to. It uses a capability-based security model, such that once you create a non-public object, it is only accessible to clients to whom you've given the (unguessable) FURL. You can of course publish world-visible objects that have well-known FURLs.
2010-07-23 23:45:52 +02:00
${PYSITELIB}/foolscap/test/test_logging.py
${PYSITELIB}/foolscap/test/test_logging.pyc
${PYSITELIB}/foolscap/test/test_logging.pyo
${PYSITELIB}/foolscap/test/test_loopback.py
${PYSITELIB}/foolscap/test/test_loopback.pyc
${PYSITELIB}/foolscap/test/test_loopback.pyo
${PYSITELIB}/foolscap/test/test_negotiate.py
${PYSITELIB}/foolscap/test/test_negotiate.pyc
${PYSITELIB}/foolscap/test/test_negotiate.pyo
${PYSITELIB}/foolscap/test/test_observer.py
${PYSITELIB}/foolscap/test/test_observer.pyc
${PYSITELIB}/foolscap/test/test_observer.pyo
${PYSITELIB}/foolscap/test/test_pb.py
${PYSITELIB}/foolscap/test/test_pb.pyc
${PYSITELIB}/foolscap/test/test_pb.pyo
${PYSITELIB}/foolscap/test/test_promise.py
${PYSITELIB}/foolscap/test/test_promise.pyc
${PYSITELIB}/foolscap/test/test_promise.pyo
${PYSITELIB}/foolscap/test/test_reconnector.py
${PYSITELIB}/foolscap/test/test_reconnector.pyc
${PYSITELIB}/foolscap/test/test_reconnector.pyo
${PYSITELIB}/foolscap/test/test_reference.py
${PYSITELIB}/foolscap/test/test_reference.pyc
${PYSITELIB}/foolscap/test/test_reference.pyo
${PYSITELIB}/foolscap/test/test_registration.py
${PYSITELIB}/foolscap/test/test_registration.pyc
${PYSITELIB}/foolscap/test/test_registration.pyo
${PYSITELIB}/foolscap/test/test_schema.py
${PYSITELIB}/foolscap/test/test_schema.pyc
${PYSITELIB}/foolscap/test/test_schema.pyo
${PYSITELIB}/foolscap/test/test_serialize.py
${PYSITELIB}/foolscap/test/test_serialize.pyc
${PYSITELIB}/foolscap/test/test_serialize.pyo
${PYSITELIB}/foolscap/test/test_stringchain.py
${PYSITELIB}/foolscap/test/test_stringchain.pyc
${PYSITELIB}/foolscap/test/test_stringchain.pyo
${PYSITELIB}/foolscap/test/test_sturdyref.py
${PYSITELIB}/foolscap/test/test_sturdyref.pyc
${PYSITELIB}/foolscap/test/test_sturdyref.pyo
${PYSITELIB}/foolscap/test/test_tub.py
${PYSITELIB}/foolscap/test/test_tub.pyc
${PYSITELIB}/foolscap/test/test_tub.pyo
Update to 0.9.1: * Release 0.9.1 (21-Sep-2015) Point release to deal with PyPI upload problems. No code changes. * Release 0.9.0 (21-Sep-2015) ** Plugins for Connection Handlers (#236) New types of connection hints can now be used, by installing a suitable connection handler into the Tub. These hints could point to I2P servers or Tor hidden-service (.onion) addresses. The built-in TCP handler can be replaced entirely to protect a client's IP address by routing all connections through Tor. Implementation of these plugins are left as exercise for the reader: Foolscap only provides the built-in "DefaultTCP" handler. See doc/connection-handlers.rst for details. ** Shared Listeners are removed (#239) Until this version, it was possible to create a single Listener that serviced multiple Tubs (by passing the Listener returned from `l=tubA.listenOn(where)` into `tubB.listenOn(l)`). This seemed useful a long time ago, but in fact was not, and the implementation caused irreparable problems that were exposed while testing the new connection handlers. So support for shared Listeners has been removed: Tubs can still use multiple Listeners, but each Listener now services at most one Tub. In particular, `Tub.listenOn()` now only accepts a string, not a Listener instance. Note that relays and redirects are still on the roadmap, but neither feature requires sharing a Listener between multiple local Tubs. ** Extended-Form Connection Hints are removed Support for extended-form connection hints has been removed. These were hints with explicit key names like "tcp:host=example.org:port=12345", or "tcp:example.org:timeout=30". They were added in the 0.7.0 release, but since then we've realized that this is power that should not be granted to external FURL providers. The parser now only accepts "tcp:example.org:12345" and "example.org:12345". Foolscap has never particularly encouraged applications to call Tub.setLocation() with anything other than these two forms, so we do not expect any compatibility problems. ** Option to Disable Gifts (#126) "Gifts", more precisely known as "third-party reference introductions", occur when one Tub sends you a message that includes a reference to some object on a third Tub. This allows references to be passed around transparently, without regard to which Tub they live on (yours, mine, or theirs), but allows other Tubs to cause you to create network connections to hosts and ports of their choosing. If this bothers you, the new `tub.setOption("accept-gifts", False)` option instructs your Tub to reject these third-party references, causing the calls that used them to signal a Violation error instead. ** Unreachable Tubs now fully supported (#208) Unreachable "client-only" Tubs can be created by simply not calling either `tub.listenOn()` nor `tub.setLocation()`. These Tubs can make outbound connections, but will not accept inbound ones. `tub.registerReference()` will throw an error, and Gifts delivered to third parties will not work. Previous versions suggested using `tub.setLocation("")`: this is no longer recommended. ** new util.allocate_tcp_port() function To support a future deprecation of `Tub.listenOn("tcp:0")`, the new allocate_tcp_port() function was added to return (synchronously) a currently-unused TCP port integer. This can be used during app configuration to decide on a listening port, which can then be passed into `Tub.listenOn("tcp:%d" % portnum)`. This may allow Tub.setLocation() to be called *before* the reactor is started, simplifying application startup code (this also requires a suitable hostname or IP address, which is a separate issue). ** Packaging/Dependency Changes Foolscap now requires Twisted 10.1.0 or newer, to use Endpoints and connection handler plugins. Foolscap's logging system (specifically the twisted-to-foolscap bridge) is now compatible with Twisted-15.2.0. The previous version had problems with the new contents of twisted.logger's "eventDict" objects. (#235)
2015-09-30 21:24:35 +02:00
${PYSITELIB}/foolscap/test/test_unreachable.py
${PYSITELIB}/foolscap/test/test_unreachable.pyc
${PYSITELIB}/foolscap/test/test_unreachable.pyo
Import py26-foolscap-0.5.1 as net/py-foolscap. This is a ground-up rewrite of Perspective Broker, which itself is Twisted's native RPC/RMI protocol (Remote Procedure Call / Remote Method Invocation). If you have control of both ends of the wire, and are thus not constrained to use some other protocol like HTTP/XMLRPC/CORBA/etc, you might consider using Foolscap. Fundamentally, Foolscap allows you to make a python object in one process available to code in other processes, which means you can invoke its methods remotely. This includes a data serialization layer to convey the object graphs for the arguments and the eventual response, and an object reference system to keep track of which objects you are connecting to. It uses a capability-based security model, such that once you create a non-public object, it is only accessible to clients to whom you've given the (unguessable) FURL. You can of course publish world-visible objects that have well-known FURLs.
2010-07-23 23:45:52 +02:00
${PYSITELIB}/foolscap/test/test_util.py
${PYSITELIB}/foolscap/test/test_util.pyc
${PYSITELIB}/foolscap/test/test_util.pyo
${PYSITELIB}/foolscap/tokens.py
${PYSITELIB}/foolscap/tokens.pyc
${PYSITELIB}/foolscap/tokens.pyo
${PYSITELIB}/foolscap/util.py
${PYSITELIB}/foolscap/util.pyc
${PYSITELIB}/foolscap/util.pyo
${PYSITELIB}/foolscap/vocab.py
${PYSITELIB}/foolscap/vocab.pyc
${PYSITELIB}/foolscap/vocab.pyo
Update to 0.9.1: * Release 0.9.1 (21-Sep-2015) Point release to deal with PyPI upload problems. No code changes. * Release 0.9.0 (21-Sep-2015) ** Plugins for Connection Handlers (#236) New types of connection hints can now be used, by installing a suitable connection handler into the Tub. These hints could point to I2P servers or Tor hidden-service (.onion) addresses. The built-in TCP handler can be replaced entirely to protect a client's IP address by routing all connections through Tor. Implementation of these plugins are left as exercise for the reader: Foolscap only provides the built-in "DefaultTCP" handler. See doc/connection-handlers.rst for details. ** Shared Listeners are removed (#239) Until this version, it was possible to create a single Listener that serviced multiple Tubs (by passing the Listener returned from `l=tubA.listenOn(where)` into `tubB.listenOn(l)`). This seemed useful a long time ago, but in fact was not, and the implementation caused irreparable problems that were exposed while testing the new connection handlers. So support for shared Listeners has been removed: Tubs can still use multiple Listeners, but each Listener now services at most one Tub. In particular, `Tub.listenOn()` now only accepts a string, not a Listener instance. Note that relays and redirects are still on the roadmap, but neither feature requires sharing a Listener between multiple local Tubs. ** Extended-Form Connection Hints are removed Support for extended-form connection hints has been removed. These were hints with explicit key names like "tcp:host=example.org:port=12345", or "tcp:example.org:timeout=30". They were added in the 0.7.0 release, but since then we've realized that this is power that should not be granted to external FURL providers. The parser now only accepts "tcp:example.org:12345" and "example.org:12345". Foolscap has never particularly encouraged applications to call Tub.setLocation() with anything other than these two forms, so we do not expect any compatibility problems. ** Option to Disable Gifts (#126) "Gifts", more precisely known as "third-party reference introductions", occur when one Tub sends you a message that includes a reference to some object on a third Tub. This allows references to be passed around transparently, without regard to which Tub they live on (yours, mine, or theirs), but allows other Tubs to cause you to create network connections to hosts and ports of their choosing. If this bothers you, the new `tub.setOption("accept-gifts", False)` option instructs your Tub to reject these third-party references, causing the calls that used them to signal a Violation error instead. ** Unreachable Tubs now fully supported (#208) Unreachable "client-only" Tubs can be created by simply not calling either `tub.listenOn()` nor `tub.setLocation()`. These Tubs can make outbound connections, but will not accept inbound ones. `tub.registerReference()` will throw an error, and Gifts delivered to third parties will not work. Previous versions suggested using `tub.setLocation("")`: this is no longer recommended. ** new util.allocate_tcp_port() function To support a future deprecation of `Tub.listenOn("tcp:0")`, the new allocate_tcp_port() function was added to return (synchronously) a currently-unused TCP port integer. This can be used during app configuration to decide on a listening port, which can then be passed into `Tub.listenOn("tcp:%d" % portnum)`. This may allow Tub.setLocation() to be called *before* the reactor is started, simplifying application startup code (this also requires a suitable hostname or IP address, which is a separate issue). ** Packaging/Dependency Changes Foolscap now requires Twisted 10.1.0 or newer, to use Endpoints and connection handler plugins. Foolscap's logging system (specifically the twisted-to-foolscap bridge) is now compatible with Twisted-15.2.0. The previous version had problems with the new contents of twisted.logger's "eventDict" objects. (#235)
2015-09-30 21:24:35 +02:00
share/doc/py-foolscap/connection-handlers.rst
Update to 0.7.0: * Release 0.7.0 (23-Sep-2014) ** Security Fixes The "flappserver" feature was found to have a vulnerability in the service-lookup code which, when combined with an attacker who has the ability to write files to a location where the flappserver process could read them, would allow that attacker to obtain control of the flappserver process. Users who run flappservers should upgrade to 0.7.0, where this was fixed as part of #226. Each flappserver runs from a "base directory", and uses multiple files within the basedir to track the services that have been configured. The format of these files has changed. The flappserver tool in 0.7.0 remains capable of reading the old format (safely), but will upgrade the basedir to the new format when you use "flappserver add" to add a new service. Brand new servers, created with "flappserver create", will use the new format. The flappserver tool in 0.6.5 (or earlier) cannot handle this new format, and will believe that no services have been configured. Therefore downgrading to an older version of Foolscap will require manual reconstruction of the configured services. ** Major Changes UnauthenticatedTub has been deprecated, and will be removed in the next release (0.8.0). This seldom-used feature provides Foolscap's RPC semantics without any of the security, and was included to enable the use of Foolscap without depending upon the (challenging-to-install) PyOpenSSL library. However, in practice, the lack of a solid dependency on PyOpenSSL has made installation more difficult for applications that *do* want the security, and UnauthenticatedTub is a footgun waiting to go off. Foolscap's code and packaging will be simpler without it. (#67) ** Minor Changes The "git-foolscap" tools, which make it possible to publish and clone Git repositories over a Foolscap (flappserver) connection, have been moved from their hiding place in doc/examples/ into their own project, hosted at https://github.com/warner/git-foolscap . They will also be published on PyPI, to enable "pip install git-foolscap". The documentation was converted from Lore to ReStructuredText (.rst). Thanks to Koblaid for the patient work. (#148) The connection-hint parser in 0.7.0 has been changed to handle all TCP forms of Twisted's "Client Endpoint Descriptor" syntax, including the short "tcp:127.0.0.1:9999" variant. A future version should handle arbitrary endpoint descriptors (including Tor and i2p, see #203), but this small step should improve forward compatibility. (#216, #217)
2014-10-01 13:43:27 +02:00
share/doc/py-foolscap/copyable.rst
share/doc/py-foolscap/failures.rst
share/doc/py-foolscap/flappserver.rst
Import py26-foolscap-0.5.1 as net/py-foolscap. This is a ground-up rewrite of Perspective Broker, which itself is Twisted's native RPC/RMI protocol (Remote Procedure Call / Remote Method Invocation). If you have control of both ends of the wire, and are thus not constrained to use some other protocol like HTTP/XMLRPC/CORBA/etc, you might consider using Foolscap. Fundamentally, Foolscap allows you to make a python object in one process available to code in other processes, which means you can invoke its methods remotely. This includes a data serialization layer to convey the object graphs for the arguments and the eventual response, and an object reference system to keep track of which objects you are connecting to. It uses a capability-based security model, such that once you create a non-public object, it is only accessible to clients to whom you've given the (unguessable) FURL. You can of course publish world-visible objects that have well-known FURLs.
2010-07-23 23:45:52 +02:00
share/doc/py-foolscap/jobs.txt
Update to 0.7.0: * Release 0.7.0 (23-Sep-2014) ** Security Fixes The "flappserver" feature was found to have a vulnerability in the service-lookup code which, when combined with an attacker who has the ability to write files to a location where the flappserver process could read them, would allow that attacker to obtain control of the flappserver process. Users who run flappservers should upgrade to 0.7.0, where this was fixed as part of #226. Each flappserver runs from a "base directory", and uses multiple files within the basedir to track the services that have been configured. The format of these files has changed. The flappserver tool in 0.7.0 remains capable of reading the old format (safely), but will upgrade the basedir to the new format when you use "flappserver add" to add a new service. Brand new servers, created with "flappserver create", will use the new format. The flappserver tool in 0.6.5 (or earlier) cannot handle this new format, and will believe that no services have been configured. Therefore downgrading to an older version of Foolscap will require manual reconstruction of the configured services. ** Major Changes UnauthenticatedTub has been deprecated, and will be removed in the next release (0.8.0). This seldom-used feature provides Foolscap's RPC semantics without any of the security, and was included to enable the use of Foolscap without depending upon the (challenging-to-install) PyOpenSSL library. However, in practice, the lack of a solid dependency on PyOpenSSL has made installation more difficult for applications that *do* want the security, and UnauthenticatedTub is a footgun waiting to go off. Foolscap's code and packaging will be simpler without it. (#67) ** Minor Changes The "git-foolscap" tools, which make it possible to publish and clone Git repositories over a Foolscap (flappserver) connection, have been moved from their hiding place in doc/examples/ into their own project, hosted at https://github.com/warner/git-foolscap . They will also be published on PyPI, to enable "pip install git-foolscap". The documentation was converted from Lore to ReStructuredText (.rst). Thanks to Koblaid for the patient work. (#148) The connection-hint parser in 0.7.0 has been changed to handle all TCP forms of Twisted's "Client Endpoint Descriptor" syntax, including the short "tcp:127.0.0.1:9999" variant. A future version should handle arbitrary endpoint descriptors (including Tor and i2p, see #203), but this small step should improve forward compatibility. (#216, #217)
2014-10-01 13:43:27 +02:00
share/doc/py-foolscap/logging.rst
share/doc/py-foolscap/schema.rst
share/doc/py-foolscap/serializing.rst
Import py26-foolscap-0.5.1 as net/py-foolscap. This is a ground-up rewrite of Perspective Broker, which itself is Twisted's native RPC/RMI protocol (Remote Procedure Call / Remote Method Invocation). If you have control of both ends of the wire, and are thus not constrained to use some other protocol like HTTP/XMLRPC/CORBA/etc, you might consider using Foolscap. Fundamentally, Foolscap allows you to make a python object in one process available to code in other processes, which means you can invoke its methods remotely. This includes a data serialization layer to convey the object graphs for the arguments and the eventual response, and an object reference system to keep track of which objects you are connecting to. It uses a capability-based security model, such that once you create a non-public object, it is only accessible to clients to whom you've given the (unguessable) FURL. You can of course publish world-visible objects that have well-known FURLs.
2010-07-23 23:45:52 +02:00
share/doc/py-foolscap/todo.txt
share/doc/py-foolscap/use-cases.txt
Update to 0.7.0: * Release 0.7.0 (23-Sep-2014) ** Security Fixes The "flappserver" feature was found to have a vulnerability in the service-lookup code which, when combined with an attacker who has the ability to write files to a location where the flappserver process could read them, would allow that attacker to obtain control of the flappserver process. Users who run flappservers should upgrade to 0.7.0, where this was fixed as part of #226. Each flappserver runs from a "base directory", and uses multiple files within the basedir to track the services that have been configured. The format of these files has changed. The flappserver tool in 0.7.0 remains capable of reading the old format (safely), but will upgrade the basedir to the new format when you use "flappserver add" to add a new service. Brand new servers, created with "flappserver create", will use the new format. The flappserver tool in 0.6.5 (or earlier) cannot handle this new format, and will believe that no services have been configured. Therefore downgrading to an older version of Foolscap will require manual reconstruction of the configured services. ** Major Changes UnauthenticatedTub has been deprecated, and will be removed in the next release (0.8.0). This seldom-used feature provides Foolscap's RPC semantics without any of the security, and was included to enable the use of Foolscap without depending upon the (challenging-to-install) PyOpenSSL library. However, in practice, the lack of a solid dependency on PyOpenSSL has made installation more difficult for applications that *do* want the security, and UnauthenticatedTub is a footgun waiting to go off. Foolscap's code and packaging will be simpler without it. (#67) ** Minor Changes The "git-foolscap" tools, which make it possible to publish and clone Git repositories over a Foolscap (flappserver) connection, have been moved from their hiding place in doc/examples/ into their own project, hosted at https://github.com/warner/git-foolscap . They will also be published on PyPI, to enable "pip install git-foolscap". The documentation was converted from Lore to ReStructuredText (.rst). Thanks to Koblaid for the patient work. (#148) The connection-hint parser in 0.7.0 has been changed to handle all TCP forms of Twisted's "Client Endpoint Descriptor" syntax, including the short "tcp:127.0.0.1:9999" variant. A future version should handle arbitrary endpoint descriptors (including Tor and i2p, see #203), but this small step should improve forward compatibility. (#216, #217)
2014-10-01 13:43:27 +02:00
share/doc/py-foolscap/using-foolscap.rst
Reference in a new issue Copy permalink