| | 2 | |
|---|
| | 3 | * Release 0.3.0 (04 Aug 2008) |
|---|
| | 4 | |
|---|
| | 5 | ** Compatibility: same as 0.2.6 |
|---|
| | 6 | |
|---|
| | 7 | The wire-level protocol remains the same as other recent releases. |
|---|
| | 8 | |
|---|
| | 9 | The new incident-gatherer will only work with applications that use Foolscap |
|---|
| | 10 | 0.3.0 or later. |
|---|
| | 11 | |
|---|
| | 12 | ** logging improvements |
|---|
| | 13 | |
|---|
| | 14 | The "incident gatherer" has finally been implemented. This is a service, like |
|---|
| | 15 | the log-gatherer, which subscribes to an application's logport and collects |
|---|
| | 16 | incident reports: each is a dump of accumulated log messages, triggered by |
|---|
| | 17 | some special event (such as those above a certain severity threshold). The |
|---|
| | 18 | "flogtool create-incident-gatherer" command is used to create one, and twistd |
|---|
| | 19 | is used to start it. Please see doc/logging.xhtml for more details. |
|---|
| | 20 | |
|---|
| | 21 | The incident publishing API was changed to support the incident-gatherer. The |
|---|
| | 22 | incident-gatherer will only work with logports using foolscap 0.3.0 or newer. |
|---|
| | 23 | |
|---|
| | 24 | The log-publishing API was changed slightly, to encourage the use of |
|---|
| | 25 | subscription.unsubscribe() rather than publisher.unsubscribe(subscription). |
|---|
| | 26 | The old API remains in place for backwards compatibility with log-gatherers |
|---|
| | 27 | running foolscap 0.2.9 or earlier. |
|---|
| | 28 | |
|---|
| | 29 | The Tub.setOption("log-gatherer-furlfile") can accept a file with multiple |
|---|
| | 30 | FURLs, one per line, instead of just a single FURL. This makes the |
|---|
| | 31 | application contact multiple log gatherers, offering its logport to each |
|---|
| | 32 | independently, e.g. to connect to both a log-gatherer and an |
|---|
| | 33 | incident-gatherer. |
|---|
| | 34 | |
|---|
| | 35 | ** API Additions |
|---|
| | 36 | |
|---|
| | 37 | RemoteReferences now have a getRemoteTubID() method, which returns a string |
|---|
| | 38 | (base32-encoded) representing the secure Tub ID of the remote end of the |
|---|
| | 39 | connection. For any given Tub ID, only the possessor of the matching private |
|---|
| | 40 | key should be able to provide a RemoteReference for which getRemoteTubID() |
|---|
| | 41 | will return that value. I'm not yet sure if getRemoteTubID() is a good idea |
|---|
| | 42 | or not (the traditional object-capability model discourages making |
|---|
| | 43 | access-control decisions on the basis of "who", instead these decisions |
|---|
| | 44 | should be controlled by "what": what objects do they have access to). This |
|---|
| | 45 | method is intended for use by application code that needs to use TubIDs as an |
|---|
| | 46 | index into a table of some sort. It is used by Tahoe to securely compute |
|---|
| | 47 | shared cryptographic secrets for each remote server (by hashing the TubID |
|---|
| | 48 | together with some other string). |
|---|
| | 49 | |
|---|
| | 50 | Note that the rref.getSturdyRef() call (which has been present in Foolscap |
|---|
| | 51 | since forever) is *not* secure: the remote application controls all parts of |
|---|
| | 52 | the sturdy ref FURL, including the tubid. A future version of foolscap may |
|---|
| | 53 | remedy this. |
|---|
| | 54 | |
|---|
| | 55 | ** Bug fixes |
|---|
| | 56 | |
|---|
| | 57 | The log-gatherer FURL can now be set before Tub.setLocation (the connection |
|---|
| | 58 | request will be deferred until setLocation is called), and |
|---|
| | 59 | getLogPort/getLogPortFURL cannot be called until after setLocation. These two |
|---|
| | 60 | changes, in combination, resolve a problem (#55) in which the gatherer |
|---|
| | 61 | connection could be made before the logport was ready, causing the |
|---|
| | 62 | log-gatherer to fail to subscribe to receive log events. |
|---|
| | 63 | |
|---|
| | 64 | ** Dependent Libraries |
|---|
| | 65 | |
|---|
| | 66 | Foolscap uses PyOpenSSL for all of its cryptographic routines. A bug (#62) |
|---|
| | 67 | has been found in which the current version of Twisted (8.1.0) and the |
|---|
| | 68 | current version of PyOpenSSL (0.7) interact badly, causing Foolscap's unit |
|---|
| | 69 | tests to fail. This problem will affect application code as well |
|---|
| | 70 | (specifically, Tub.stopService will hang forever). The problem only appears |
|---|
| | 71 | to affect the selectreactor, so the current recommended workaround is to run |
|---|
| | 72 | unit tests (and applications that need to shut down Tubs) with --reactor=poll |
|---|
| | 73 | (or whatever other reactor is appropriate for the platform, perhaps iocp). A |
|---|
| | 74 | less-desireable workaround is to downgrade PyOpenSSL to 0.6, or Twisted to |
|---|
| | 75 | something older. The Twisted maintainers are aware of the problem and intend |
|---|
| | 76 | to fix it in an upcoming Twisted release. |
|---|
| | 77 | |
|---|
