i should have removed these changes files during 0.2.3.20 release

2012-08-27 14:25:08 -04:00 · 2012-08-27 14:25:08 -04:00 · 1acaba478e
parent e0d5dec3e2
commit 1acaba478e
6 changed files with 0 additions and 36 deletions
--- a/changes/bug6043
+++ b/changes/bug6043
@ -1,6 +0,0 @@
-  o Packaging (RPM):
-    - Our default RPM spec files have been updated to work with mock
-      and rpmbuild on RHEL/Fedora. They have an updated set of
-      dependencies and conflicts, a fix for an ancient typo when creating
-      the "_tor" user, and better instructions. Thanks to Ondrej
-      Mikle for the patch series; fix for bug 6043.
--- a/changes/bug6480
+++ b/changes/bug6480
@ -1,5 +0,0 @@
-  o Major bugfixes:
-    - Avoid read-from-freed-RAM bug and related double-free bug that
-      could occur when a DNS request fails while launching it.  Fixes
-      bug 6480; bugfix on 0.2.0.1-alpha.
-
--- a/changes/bug6490
+++ b/changes/bug6490
@ -1,4 +0,0 @@
-  o Minor features:
-    - Warn when Tor is configured to use accounting in a way that will
-      link a hidden service to some other hidden service or public
-      address. Fix for bug 6490.
--- a/changes/bug6500
+++ b/changes/bug6500
@ -1,2 +0,0 @@
-  o Minor bugfixes:
-    - Fix some typos in the manpages. Patch from A. Costa. Fixes bug 6500.
--- a/changes/bug6530
+++ b/changes/bug6530
@ -1,5 +0,0 @@
-  o Major security fixes:
-    - Avoid a read of uninitializd RAM when reading a vote or consensus
-      document with an unrecognized flavor name. This could lead to a
-      remote crash bug. Fixes bug 6530; bugfix on 0.2.2.6-alpha.
-      
--- a/changes/pathsel-BUGGY-a
+++ b/changes/pathsel-BUGGY-a
@ -1,14 +0,0 @@
-  o Security fixes:
-
-    - Try to leak less information about what relays a client is
-      choosing to a side-channel attacker.  Previously, a Tor client
-      would stop iterating through the list of available relays as
-      soon as it had chosen one, thus finishing a little earlier
-      when it picked a router earlier in the list.  If an attacker
-      can recover this timing information (nontrivial but not
-      proven to be impossible), they could learn some coarse-
-      grained information about which relays a client was picking
-      (middle nodes in particular are likelier to be affected than
-      exits).  The timing attack might be mitigated by other factors
-      (see bug #6537 for some discussion), but it's best not to
-      take chances.  Fixes bug 6537; bugfix on 0.0.8rc1.