+Changes in version 0.2.3.4-alpha - 2011-09-??
+ o Major bugfixes:
+ - Avoid an assertion failure when reloading a configuration with
+ TrackExitHosts changes. Found and fixed by 'laruldan'. Fixes bug
+ 3923; bugfix on 0.2.2.25-alpha.
+
+ o Major features:
+ - Relays now try regenerating and uploading their descriptor more
+ frequently if they are not listed in the consensus, or if the
+ version of their descriptor listed in the consensus is too
+ old. This fix should prevent situations where a server declines
+ to re-publish itself because it has done so too recently, even
+ though the authorities decided not to list its recent-enough
+ descriptor. Fix for bug 3327.
+
+ o Minor features (security):
+ - Check for replays of the public-key encrypted portion of an
+ INTRODUCE1 cell, in addition to the current check for replays of
+ the g^x value. This prevents a possible class of active attacks
+ by an attacker who controls both an introduction point and a
+ rendezvous point, and who uses the malleability of AES-CTR to
+ alter the encrypted g^x portion of the INTRODUCE1 cell. We think
+ that these attacks is infeasible (requiring the attacker to send
+ on the order of zettabytes of altered cells in a short interval),
+ but we'd rather block them off in case there are any classes of
+ this attack that we missed. Reported by Willem Pinckaers.
+
+ o Minor features:
+ - Add a VoteOnHidServDirectoriesV2 configuration option to allow
+ directory authorities to abstain from voting on assignment of
+ the HSDir consensus flag. Related to bug 2649.
+ - Relays now include a reason for regenerating their descriptors
+ an HTTP header when uploading to the authorities. This will
+ make it easier to debug descriptor-upload issues in the future.
+ - When starting as root and then changing our UID via the User
+ control option, if we are running with ControlSocket, make sure
+ that the ControlSocket is owned by the same account that Tor will
+ run under. Implements ticket 3421; fix by Jérémy Bobbio.
+
+ o Minor bugfixes:
+ - Change the default required uptime for a relay to be accepted as
+ a HSDir from 24 hours to 25 hours. Bugfix on 0.2.0.10-alpha;
+ fixes bug 2649.
+ - Abort if tor_vasprintf fails in connection_printf_to_buf (a
+ utility function used in the control-port code). This shouldn't
+ ever happen unless Tor is completely out of memory, but if it
+ did happen and Tor somehow recovered from it, Tor could have
+ sent a log message to a control port in the middle of a reply to
+ a controller command. Fixes part of bug 3428.
+ - Make 'FetchUselessDescriptors' cause all descriptor types and
+ all consensus types to get fetched. Fixes bug 3851; bugfix on
+ 0.2.3.1-alpha.
+
+ o Build fixes:
+ - Clean up some code issues that prevented Tor from building on older
+ BSDs. Fixes bug 3894; reported by "grarpamp".
+ - Search for a platform-specific version of "ar" when cross-compiling.
+ Should fix builds on iOS. Found by Marco Bonetti.
+
+ o Code refactoring:
+ - Make a new "entry connection" struct as an internal subtype of "edge
+ connection", to simplify the code and make exit connections smaller.
+
+
Changes in version 0.2.3.3-alpha - 2011-09-01
Tor 0.2.3.3-alpha adds a new "stream isolation" feature to improve Tor's
security, and provides client-side support for the microdescriptor
+++ /dev/null
- o Major features:
- - Relays now try regenerating and uploading their descriptor more
- frequently if they are not listed in the consensus, or if the
- version of their descriptor listed in the consensus is too
- old. This fix should prevent situations where a server declines
- to re-publish itself because it has done so too recently, even
- though the authorities decided not to list its recent-enough
- descriptor. Fix for bug 3327.
-
- o Minor features:
- - Relays now include a reason for regenerating their descriptors
- an HTTP header when uploading to the authorities. This will
- make it easier to debug descriptor-upload issues in the future.
-
+++ /dev/null
- o Minor features (security):
-
- - Check for replays of the public-key encrypted portion of an
- INTRODUCE1 cell, in addition to the current check for replays of
- the g^x value. This prevents a possible class of active attacks
- by an attacker who controls both an introduction point and a
- rendezvous point, and who uses the malleability of AES-CTR to
- alter the encrypted g^x portion of the INTRODUCE1 cell. We
- think that these attacks is infeasible (requiring the attacker
- to send on the order of zettabytes of altered cells in a short
- interval), but we'd rather block them off in case there are any
- classes of this attack that we missed. Reported by dvorak.
-
projects / thirdparty / tor.git / commitdiff
