2017-01-18 21:46:34 by Thomas Klausner | Files touched by this commit (2) |
Log message:
Updated py-foolscap to 0.12.6.
* Release 0.12.6 (12-Jan-2017)
This is a minor release to improve compatibility with Twisted and I2P.
In this release, the Foolscap test suite no longer uses several deprecated
and/or internal Twisted attributes, so it should pass cleanly on the next
release of Twisted (which will probably be named Twisted-17.0.0).
In addition, the I2P connection handler was enhanced to let applications pass
arbitrary kwargs through to the underlying "SAM" API.
Finally connection-status error messages should be slightly cleaner and
provide more useful information in the face of unrecogized exceptions.
|
2017-01-01 15:44:09 by Thomas Klausner | Files touched by this commit (577) |
Log message:
Add python-3.6 to incompatible versions.
|
2016-12-12 15:27:39 by Thomas Klausner | Files touched by this commit (3) | ![Package updated](https://pkgsrc.se/images/update.gif) |
Log message:
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-10-19 14:54:04 by Thomas Klausner | Files touched by this commit (2) |
Log message:
Updated py-foolscap to 0.12.4.
* Release 0.12.4 (27-Sep-2016)
** Improvements
The TCP connection-hint handler can now accept square-bracket-wrapped IPv6
addresses in colon-hex format. You can produce FURLs with such hints by doing
this:
tub.setLocation("tcp:[2001:0DB8:f00e:eb00::1]:9900")
Foolscap Tubs have been using the IPv6-capable `HostnameEndpoint` since
0.11.0, so this completes the IPv6 support. Note that there are no provisions
for automatically detecting the host's IPv6 addresses: applications that wish
to use addresses (instead of hostnames) must discover those addresses on
their own. #155
A new `tor.control_endpoint_maker()` handler function was added, which is
just like `tor.control_endpoint()` but accepts a callable function, which
will be invoked only when a `tor:` hint is encountered. The function can
return a Deferred which yields the control endpoint. This allows lazy
launching of a Tor daemon, which can also be shared with other application
needs, such as listening on an Onion service. #270
|
2016-09-04 11:28:18 by Thomas Klausner | Files touched by this commit (2) |
Log message:
Updated py-foolscap to 0.12.3.
* Release 0.12.3 (01-Sep-2016)
** Improvements
The `tor.socks_port()` handler was replaced by `tor.socks_endpoint()`, which
takes an Endpoint object (just like `tor.control_endpoint()` does). This
enables applications to speak SOCKS to the Tor daemon over e.g. a Unix-domain
socket. The `tor.socks_port()` API was removed, so applications using it must
upgrade. #265
The `allocate_tcp_port()` utility function would occasionally return ports
that were in use by other applications, when those applications bound their
own port to the loopback interface (127.0.0.1). allocate_tcp_port should no
longer do this.
|
2016-09-01 18:54:32 by Thomas Klausner | Files touched by this commit (3) |
Log message:
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-07-09 15:04:18 by Thomas Klausner | Files touched by this commit (599) |
Log message:
Remove python33: adapt all packages that refer to it.
|
2016-06-08 19:43:49 by Thomas Klausner | Files touched by this commit (356) |
Log message:
Switch to MASTER_SITES_PYPI.
|
2016-04-13 20:19:49 by Thomas Klausner | Files touched by this commit (3) | ![Package updated](https://pkgsrc.se/images/update.gif) |
Log message:
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-02-01 12:58:19 by Thomas Klausner | Files touched by this commit (2) |
Log message:
Update to 0.10.1:
* Release 0.10.1 (21-Jan-2015)
** Packaging Fixes
This release fixes a version-string management failure when the "log
publisher" feature was used in a tree built from a release tarball (rather
than from a git checkout). This caused a unit test failure, as well as
operational failures when using `flogtool tail`. Thanks to Ramakrishnan
Muthukrishnan (vu3rdd) for the catch and the patch. (#248)
|