vidalia (0.2.21-3) unstable; urgency=medium

  UPnP support is now disabled: it relies on a very old embedded version
  of the miniupnpc library, that causes build failures on Hurd.

  Upstream being essentially dead these days, we can neither support
  this code as Vidalia maintainers in Debian, nor can we afford
  porting Vidalia to the up-to-date system version of that library.

 -- intrigeri <intrigeri@debian.org>  Mon, 24 Feb 2014 11:48:47 +0100

vidalia (0.2.19-1) unstable; urgency=low

  From this version on, we now include two great security enhancement
  features, both coming by stock (no user changes required):
  - Code compiler hardening enhancements
  - AppArmor shield profile
  .
  Please refer to /usr/share/doc/vidalia/README.Debian.gz for more
  information, section "Debian Security Enhancements"
  .
  Many thanks to intrigeri for providing this great patches!

 -- Ulises Vitulli <dererk@debian.org>  Fri, 22 Jun 2012 07:18:44 -0300

vidalia (0.2.17-1) unstable; urgency=low

  A known bug has been introduced at this release point (in fact it was on 
  0.2.16, see below), which produces a little undesired effect on very 
  particular configuration sets. 
  .
  Bug description:
  If you use Vidalia to control Tor and change Tor's config but Vidalia's 
  saveconf attempt fails (e.g. because Vidalia is controlling the system Tor
  and it can't write to /etc/tor/torrc, which is default), then Vidalia will 
  tell Tor to quit reloading its torrc on hup.
  .
  This is a feature by its own, because now the changes Vidalia made won't be
  silently overwritten at daily's Tor logrotation, but it's a bug too, because
  if you logrotate before hupping, Tor won't open any new logs.
  .
  /As a resume/, this translates into an undesired effect on Tor's logging
  capacity, but it's highly unlikely this will affect any of your privacy 
  properties at any point.
  .
  See upstreams's bug report at:
  https://trac.torproject.org/projects/tor/ticket/5095
  .
  For the curious, there was indeed a 0.2.16 upstrem release, which differs
  from the version you're now at by just a little policy change on Vidalia's 
  user interface translations.

 -- Ulises Vitulli <dererk@debian.org>  Sat, 11 Feb 2012 22:26:58 -0300

vidalia (0.2.14-2) unstable; urgency=low

  As #552556 got solved up through the years, really great news come up today
  .
  Having "Control Socket" enabled by default on Tor package lets us to 
  turn to almost zero configuration required for Vidalia users to run Tor
  .
  This means we are be able to speak, through a local Unix socket, with Tor
  directly with no extra authentication required
  .
  Although this could appear to be frightening, basic POSIX permissions 
  are still required to access this socket, which, except in the case 
  you screw up your system, is pretty fair
  . 
  To put things into perspective, most of all services on your system, even
  the more sensible ones, have been secured this way over many decades, 
  so don't get stressed out! :-)
  . 
  Kudos to Weasel&&everyone involved in this awesome goal.

 -- Ulises Vitulli <dererk@debian.org>  Sat, 03 Sep 2011 15:47:23 -0300
