Hey friends, i want to inform you that i am working on a complete new control tool for Tor. I know some people use Vidalia for it, but i never liked the program and the people i showed vidalia often got confused.
So i started to rewrite it from scratch and i am close to the release of the source code. (Currently i need to clean up some classes in there)
I had a few things on my feature list for the new control tool and i want to share/discuss it with you. Because maybe some of my ideas are bad or maybe you have some additional ideas for features.
A: "native work flow". Thats one of the main goals of my rewrite. The current Vidalia does things a little bit different than people are used to do it. So they get confused, because it does not behave "naturally". So instead of QT i used GTK and followed as always the GNOME HIG. (http://developer.gnome.org/hig-book/3.5/)
B: "Multi configuration setup". What do i mean by that? Well, in my case for example i use Tor on my laptop and i am often in different places where i need different settings for tor. For example, if i am at home i can give tor all the bandwith i have, because at home i don't care. In my company on the other hand i cant do that. I am allowed to run Tor in the company, but with a bandwith limit of 2000kbit/s. (Yes, my company allows this ... well, i am the technical directory, so it was my call :) )
But i need a different Tor configuration there. Or if i am giving a talk and only have mobile internet connections i need every bit of bandwith for checking my emails so i want no server, only Tor client support. Currently i have multiple torrc files for that and always move them arround. That works for command line junkies like me, but even i am anoyed to do this multiple times a day.
So i added the "multi configuration" support into the tool. This allows you to define multiple configurations and simply change them with a click from the gnome2 notification panel.
C: "GUI for config settings". Well, some users are simply not ready to modify config files on there own. So i provide a simple gui (tab based) for all config options i found in the normal torrc file. Always with an explonation (with needs spellchecking, because my spelling sucks in german and is even worse in english :) ) so the user can deside what an option would to.
D: "Notifications": My control tool uses the normal desktop notifications to inform the user about changes in the running tor application. For example if there is a problem building the circuit or something you get the notifyd message and can simply react to events without having the arm log open all the time.
Thats just a quick overview of what i am duing right now. The source code will be released soon and is of course 100% open source. If you have some addiional ideas, feedback, wishes, ... i would like to hear them.
Thanks and greetings Leo
PS: I am Germam and very sorry for every spelling error i did above.
This sounds really cool. I've found in my user studies that Vidalia can be confusing to users (since Vidalia and the TBB are two different application windows)
Is that an issue you're trying to solve in your rewrite?
(Reference, if you want some background: http://petsymposium.org/2012/papers/hotpets12-1-usability.pdf) -- Greg Norcie (greg@norcie.com) GPG key: 0x1B873635
On 2/20/13 2:37 PM, Leo Unglaub wrote:
Hey friends, i want to inform you that i am working on a complete new control tool for Tor. I know some people use Vidalia for it, but i never liked the program and the people i showed vidalia often got confused.
So i started to rewrite it from scratch and i am close to the release of the source code. (Currently i need to clean up some classes in there)
I had a few things on my feature list for the new control tool and i want to share/discuss it with you. Because maybe some of my ideas are bad or maybe you have some additional ideas for features.
A: "native work flow". Thats one of the main goals of my rewrite. The current Vidalia does things a little bit different than people are used to do it. So they get confused, because it does not behave "naturally". So instead of QT i used GTK and followed as always the GNOME HIG. (http://developer.gnome.org/hig-book/3.5/)
B: "Multi configuration setup". What do i mean by that? Well, in my case for example i use Tor on my laptop and i am often in different places where i need different settings for tor. For example, if i am at home i can give tor all the bandwith i have, because at home i don't care. In my company on the other hand i cant do that. I am allowed to run Tor in the company, but with a bandwith limit of 2000kbit/s. (Yes, my company allows this ... well, i am the technical directory, so it was my call :) )
But i need a different Tor configuration there. Or if i am giving a talk and only have mobile internet connections i need every bit of bandwith for checking my emails so i want no server, only Tor client support. Currently i have multiple torrc files for that and always move them arround. That works for command line junkies like me, but even i am anoyed to do this multiple times a day.
So i added the "multi configuration" support into the tool. This allows you to define multiple configurations and simply change them with a click from the gnome2 notification panel.
C: "GUI for config settings". Well, some users are simply not ready to modify config files on there own. So i provide a simple gui (tab based) for all config options i found in the normal torrc file. Always with an explonation (with needs spellchecking, because my spelling sucks in german and is even worse in english :) ) so the user can deside what an option would to.
D: "Notifications": My control tool uses the normal desktop notifications to inform the user about changes in the running tor application. For example if there is a problem building the circuit or something you get the notifyd message and can simply react to events without having the arm log open all the time.
Thats just a quick overview of what i am duing right now. The source code will be released soon and is of course 100% open source. If you have some addiional ideas, feedback, wishes, ... i would like to hear them.
Thanks and greetings Leo
PS: I am Germam and very sorry for every spelling error i did above.
Hey guys, thanks for all the feedback. I am happy there is an interest from your part in this project.
I am trying to answer to all of your questions below.
(since Vidalia and the TBB are two different application windows)
Is that an issue you're trying to solve in your rewrite?
I didn't address this problem specific, because my UI is complete different than the current one. So i hope this confusion will be fixed automatically.
I don't know very much about the Gnome architecture -- will this work for users who aren't using the Gnome desktop?
Yes, this will work for non-gnome users to. gnome-shell, mate, xfce, kde, lxde, windows, ... all are no problem. I never tryed it on a MAC but normally it should work there to.
Are you aiming for portability?
Yes, i am trying to support all plattforms. This is actually new to me, becuase normaly i develop only linux applications using vala. But i realize that people don't always have linux, so i am aiming to support them to. Hopefully with your help, because i don't have a mac to build dmg packages.
Also, what license are you thinking of going with?
All my projects are released under the GPL/LGPL. But if the Tor project requires a different open source licence, i have no problem with double licences as long as they are open source and allow the user to do whatever they want to do with it.
One other thing -- I'd suggest naming your program something other than Vidalia, so that people can tell which program is which.
Yes, i just wrote "vidalia 2.0" so you know what i mean. But we can pick every other name. Currently during development i refered to it as "coop" but thats just because it's the name of my dog. If you have ideas, i am happy to hear them. I normally just pick names from my favorite TV series. :)
That would be... quite a substantial project.
I am not quit sure of the meaning "substantial". Does this mean it's an important project or does this mean you think it's to large/huge to perform?
What language did you use?
I used Python. Normally i am a Vala/C user, but i always wanted to try Python because so much users recommended it and this project seamed like a good idea to try it. So to answer your Question, it's Python 2.7 / 3. I am aiming to support both versions. Also i am trying to support PyPy for more speed.
How long have you been working on this
I have spend the last 2 weeks on it. If you are used to Vala thats not a lot of time for a project, but with python development is so damn fast. So i am actually pretty far with my plans.
Currently i am working on the tor-control-specs implementation. Thats not 100% done yet. But most of the UI stuff is done and core functions like the param parsing, the config editors or some notification classes.
by 'release of the source code' to you mean a functional prototype?
The first release will not contain all of the planed features, but i always try to build programs so that i can easily extend them. So after the first version i am planing to simply add more features over time.
Personally I'd love to see a shiny, new Tor UI in python since that has our best language support in terms of controller libraries.
In this case you will be happy, because - in my opinion - the tool looks great and feels native. I like it :)
What is missing in Vidalia?
Well, some points of what is missing in my opinion i wrote in the first email. But thats just a list of things i like in a control tool. Maybe other people or the vidalia developers didn't want them in for a reasion. I don't know that. But i think thats also not important, because the best thing about the common control protocol is, that people can use whatever client they want.
Time for a rewrite or better improve the existing code base?
I spend some time to look at the existing codebase. It is possible to implement my features in there to, but that would take much longer for me. I am not the developer how loves to hack on other peoples source code. So for me it was the logical choice to write it myself new.
Before developing it, I'd make a list of requirements/features.
I did this in my first email. Please see the points in the email as a feature list. I also looked at the bug tracker. Most tickets in there are not features, there are bugs in the current implementation. So by starting from scratch most of those things should be solved automaticly.
I hope that answered all of your questions. Thanks for all the input from your part. It is really welcome and also thanks to Jacob and his talks on youtube, those are the reason i am writing this tool.
Greetings Leo
All my projects are released under the GPL/LGPL. But if the Tor project requires a different open source licence, i have no problem with double licences as long as they are open source and allow the user to do whatever they want to do with it.
Vidalia and arm are both GPL, Stem is LGPL, but Tor itself is BSD.
I am not quit sure of the meaning "substantial". Does this mean it's an important project or does this mean you think it's to large/huge to perform?
I just meant that making and maintaining a good replacement for Vidalia is no small task. :)
I used Python. Normally i am a Vala/C user, but i always wanted to try Python because so much users recommended it and this project seamed like a good idea to try it. So to answer your Question, it's Python 2.7 / 3. I am aiming to support both versions. Also i am trying to support PyPy for more speed.
Great!
Currently i am working on the tor-control-specs implementation. Thats not 100% done yet. But most of the UI stuff is done and core functions like the param parsing, the config editors or some notification classes.
Are you aware of Stem and Txtorcon? If not then they should make interacting with Tor far, far nicer...
https://stem.torproject.org/ https://txtorcon.readthedocs.org/
If you end up using stem then let me know if there's anything I can do to make it better suit your needs! It is now the backend for arm (http://www.atagar.com/arm/) so it should have everything you need for a Tor UI and if it doesn't I'd be glad to work with you to extend it.
Cheers! -Damian
On Thu, Feb 21, 2013 at 11:12 AM, Leo Unglaub leo@leo-unglaub.net wrote:
Hey guys, thanks for all the feedback. I am happy there is an interest from your part in this project.
I am trying to answer to all of your questions below.
[...]
I don't know very much about the Gnome architecture -- will this work for users who aren't using the Gnome desktop?
Yes, this will work for non-gnome users to. gnome-shell, mate, xfce, kde, lxde, windows, ... all are no problem. I never tryed it on a MAC but normally it should work there to.
Cool.
Are you aiming for portability?
Yes, i am trying to support all plattforms. This is actually new to me, becuase normaly i develop only linux applications using vala. But i realize that people don't always have linux, so i am aiming to support them to. Hopefully with your help, because i don't have a mac to build dmg packages.
Nice. Python and GTK should make that fairly straightforward, I'd hope.
Also, what license are you thinking of going with?
All my projects are released under the GPL/LGPL. But if the Tor project requires a different open source licence, i have no problem with double licences as long as they are open source and allow the user to do whatever they want to do with it.
Most of our stuff is 3-clause BSD, but Vidalia is IIRC GPL. For whatever it's worth,
[...]
That would be... quite a substantial project.
I am not quit sure of the meaning "substantial". Does this mean it's an important project or does this mean you think it's to large/huge to perform?
I think they mean "sounds like a lot of work!" Still IMO worthwhile.
What language did you use?
I used Python. Normally i am a Vala/C user, but i always wanted to try Python because so much users recommended it and this project seamed like a good idea to try it. So to answer your Question, it's Python 2.7 / 3. I am aiming to support both versions. Also i am trying to support PyPy for more speed.
Cool. Is speed an issue for this? I would have thought that there wouldn't be very many slow things to do.
How long have you been working on this
I have spend the last 2 weeks on it. If you are used to Vala thats not a lot of time for a project, but with python development is so damn fast. So i am actually pretty far with my plans.
Currently i am working on the tor-control-specs implementation. Thats not 100% done yet. But most of the UI stuff is done and core functions like the param parsing, the config editors or some notification classes.
You might really want to check out stem or txtorconn before you do another complete Python controller library implementation.
peace,
Thus spake Leo Unglaub (leo@leo-unglaub.net):
Hey guys, thanks for all the feedback. I am happy there is an interest from your part in this project.
I am trying to answer to all of your questions below.
(since Vidalia and the TBB are two different application windows)
Is that an issue you're trying to solve in your rewrite?
I didn't address this problem specific, because my UI is complete different than the current one. So i hope this confusion will be fixed automatically.
This is actually a pretty deep problem with many pieces. It might not be fixed automatically so long as the OS considers the Tor Controller a separate app.
Right now, users are currently confused in multiple ways by Vidalia being a separate app from the browser:
1. The appearance of the Vidalia window before the browser window causes many users believe that Vidalia is somehow routing *all* traffic through Tor, and that it is safe to use *any* browser once the Vidalia status bar has completed (and sometimes even before).
2. Another common source of confusion is the separate Vidalia Dock icon on Mac, Windows 7+, and Gnome/Unity desktops. This causes all manner of sub-problems:
2a). People sometimes dock the wrong app icon and later try to launch the Tor Browser directly without Vidalia.
2b). People get confused over which app (Vidalia or Tor Browser) they actually need to quit when they're done using the software.
2c). To make matters worse: For some reason, technically sophisticated users won the argument that TBB's Vidalia+Tor should remain open after the browser was closed (so they could manually configure other app SOCKS settings to point at Tor's SOCKS port, and manually re-launch the browser piece from the command line). This choice was made to the detriment and confusion of novice users, who often end up launching several copies of Tor over time, or simply giving up on TBB altogether when it fails to re-launch with Vidalia open, depending on their OS's dock behavior.
Not to mention Vidalia+Qt adds 11M to our *compressed* bundle size (60M+ on disk), and also doesn't appear to have a dedicated maintainer.
So the situation is pretty dire, in my opinion.
Our plan over the next few months is to create a super-simplified Tor Controller as a Firefox extension for TBB that can configure proxies/bridges/pluggable transports (but nothing else), launch Tor, and display a bootstrap progress bar *inside* the browser window while it waits for Tor to download network data.
Once we get to that point, I plan to make Vidalia an optional package for people who really want advanced configuration like also running a relay/bridge, watching the network map, etc. However, if your Tor Controller ends up being superior to Vidalia by then, I could easily see recommending it as the official "Advanced Controller" addon package, especially since it should be substantially less of a packaging burden than building and shipping all of Qt for several platforms (I hope).
It will be pretty hard to convince me that we should continue shipping a separate Controller UI bundled with Tor Browser by default though, given the above issues.
Hey,
On 2013-02-21 19:49, Mike Perry wrote:
This is actually a pretty deep problem with many pieces. It might not be fixed automatically so long as the OS considers the Tor Controller a separate app.
i have to stop here. I made an mistake in my previous E-Mail. I don't plan to launch or integrate the TBB into the control tool. I thought TBB was something else.
I dont' want to support the browser or any other applications. My tool is simply a control tool for the running tor instance. (the local one or additional servers via an SSH connection).
But i am just working on a control tool, not a launcher for the secure browser or something like that.
About the already existing Python libs for tor. thanks for telling me about it. I am goinig to use them. the reasion i started my own impelementation was because i simply did no know about the libs.
Greetings Leo
Thus spake Leo Unglaub (leo@leo-unglaub.net):
On 2013-02-21 19:49, Mike Perry wrote:
This is actually a pretty deep problem with many pieces. It might not be fixed automatically so long as the OS considers the Tor Controller a separate app.
i have to stop here. I made an mistake in my previous E-Mail. I don't plan to launch or integrate the TBB into the control tool. I thought TBB was something else.
I dont' want to support the browser or any other applications. My tool is simply a control tool for the running tor instance. (the local one or additional servers via an SSH connection).
But i am just working on a control tool, not a launcher for the secure browser or something like that.
This sounds great. Sounds like it can be exactly what I had in mind: An optional Tor Controller that can let you do nifty advanced stuff if you want, but otherwise won't get in the way or confuse people.
The next release of TBB will have a Control Port on 9151. We still use randomly-generated password authentication though, which might make testing difficult for now.
When we move to the browser-based controller, we'll hopefully also move to "AUTHCHALLENGE"/"SAFECOOKIE" authentication so that it is possible for the user to run alternate controller programs without configuration.
It looks like stem supports automatic authentication negotiation with a single API call, which will come in very handy for you for this purpose: https://stem.torproject.org/api/connection.html#stem.connection.authenticate
Hi Leo. I forgot to mention earlier, if you haven't tried the arm gui then it might be worth a look. It's GTK, python, and functional so it might have some bits that you'd find to be useful.
To run it simply download arm (http://www.atagar.com/arm/download.php) and run "arm --gui".
Cheers! -Damian
Hey, sorry for not responding so long, but i had very much things todo.
On 2013-02-22 06:56, Damian Johnson wrote:
if you haven't tried the arm gui then it might be worth a look. It's GTK, python, and functional so it might have some bits that you'd find to be useful.
i tryed that some time ago, but i was unable of getting it to work properly. Always hat a problem during the cagraph installation. So i gave up on it. But i know Arm itself in the command line version. Use it every day.
I have also continued to work on my tool as well. I dumped my own implementation of the Tor Control Protocol and looked into Stem and txtorcon.
Both are good libraries, but i have some difficulties implementing them for remote servers. Using them on local servers is easy and saves me a lot of work, but tunneling it over SSH to manage remote Servers as well is something that i currently failed at.
I tryed to reach the developers in the irc, but i think we have there a little timezone problem :)
Currently i fafour Stem for my tool because it simply looked easier to use. But i don't want to say that txtorcon is a bad software, it just seems a little bit mor complicated that i need :)
I also have named my tool. It's called "Gibbs". I also created a github repository where i will push my local git repository the next couple of days. I also want to release some screenshots soon so you can see what is comming.
https://github.com/LeoUnglaub/tor-gibbs
Greetings Leo
i tryed that some time ago, but i was unable of getting it to work properly. Always hat a problem during the cagraph installation. So i gave up on it. But i know Arm itself in the command line version. Use it every day.
Sweet! Always glad to hear that people find it to be useful. :)
Cagraph should be a standard python library. You can snag it from...
http://cagraph.googlecode.com/files/cagraph-1.2.tar.gz
... then simply extract it into the 'arm/src' directory.
Both are good libraries, but i have some difficulties implementing them for remote servers. Using them on local servers is easy and saves me a lot of work, but tunneling it over SSH to manage remote Servers as well is something that i currently failed at.
What kind of issues did you encounter in using stem remotely? I haven't tried it personally, but in theory it should work.
I tryed to reach the developers in the irc, but i think we have there a little timezone problem :)
We can always fail over to email if that works for you.
Cheers! -Damian
Hey,
On 2013-03-11 04:10, Damian Johnson wrote:
Sweet! Always glad to hear that people find it to be useful.
yes, it is very usefull. There are just two issues that cause arm to crash if you resize the terminal during some events. It simply freezes arm. But thats a place for an issue report :)
... then simply extract it into the 'arm/src' directory.
I always followed your install assistant with failed and nevery tryed it manualy. I have to do that some time to check our all your functions.
What kind of issues did you encounter in using stem remotely?
I think thats more of an logical problem than a technical issue. If i read your api documentation right you are using stem.socket for all the low level communications with tor. If i am on localhost a "simple" ControlSocket.ControlPort or a Control.Socket.ControlSocketFile is enought.
But i have no idea on how to tunnel that thru SSH. I think i have to use your send, recv, connect, close, ... methods directly. But sadly i was still unable of connecting to my virtual test server.
We can always fail over to email if that works for you.
Thats nice, but i think i will catch you in the future in the IRC to. And if i published my code you will propobly see my problem very fast :)
Greetings Leo
Leo Unglaub leo@leo-unglaub.net wrote:
On 2013-03-11 04:10, Damian Johnson wrote:
Sweet! Always glad to hear that people find it to be useful.
yes, it is very usefull. There are just two issues that cause arm to crash if you resize the terminal during some events. It simply freezes arm. But thats a place for an issue report :)
For example: https://trac.torproject.org/projects/tor/ticket/7813
You could try the patch, although at least on FreeBSD resizing the terminal isn't necessary for arm's UI to become unresponsive.
Fabian
On Mon, Mar 11, 2013 at 2:40 AM, Leo Unglaub leo@leo-unglaub.net wrote:
I also have named my tool. It's called "Gibbs". I also created a github repository where i will push my local git repository the next couple of days. I also want to release some screenshots soon so you can see what is comming.
https://github.com/LeoUnglaub/**tor-gibbshttps://github.com/LeoUnglaub/tor-gibbs
Hey Leo,
Are you making progress on this? I would love to test it out if you are able to push it to your github repo.
Thanks! Matt
Hey,
On 2013-06-25 06:04, Matthew Finkel wrote:
Are you making progress on this? I would love to test it out if you are able to push it to your github repo.
the tool is done and works very well on my laptop. I simply have forgotten to push it to Github.
I am putting it on my ToDo list and will push it when i get home from work.
I am looking forward to your Feedback. Greetings Leo
Hey,
On 06/25/2013 10:42 PM, Leo Unglaub wrote:
I am putting it on my ToDo list and will push it when i get home from work.
i have encountered a little problem while uploading it to the repository. I used some parts of the "firemoon" framework in my tool to build it. This framework is developed my the company i work for and it's open source. But it's not released yet, because it's not 100% done.
I have to replace the parts in where i used it so i can upload it. Sorry for that, but while coding i did not thought about what i used :)
Greetings Leo
Mike Perry:
Our plan over the next few months is to create a super-simplified Tor Controller as a Firefox extension for TBB that can configure proxies/bridges/pluggable transports (but nothing else), launch Tor, and display a bootstrap progress bar *inside* the browser window while it waits for Tor to download network data.
If they can not easily configure to be a bridge or relay, won't that results in fewer Tor servers? Isn't Vidalia encouraging users to contribute to the network?
Thus spake adrelanos (adrelanos@riseup.net):
Mike Perry:
Our plan over the next few months is to create a super-simplified Tor Controller as a Firefox extension for TBB that can configure proxies/bridges/pluggable transports (but nothing else), launch Tor, and display a bootstrap progress bar *inside* the browser window while it waits for Tor to download network data.
If they can not easily configure to be a bridge or relay, won't that results in fewer Tor servers? Isn't Vidalia encouraging users to contribute to the network?
It is quite debatable as to if Tor nodes on residential Internet connections actually help the network. For some time, we planned on developing a way to detect if your connection was fast enough and stable enough to ask you to be a relay[1], but it's never been implemented.
If this feature is ever implemented in Tor, the Javascript controller can periodically ask Tor if it has detected this and suggest that you download the Advanced Controller package to help out.
But even without this notification, I suspect if your Internet connection is fast enough (and your browser stays open long enough) to help the Tor network, you're going to know it already, and you'll have no problem downloading an Advanced Controller package.
[1]. https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/175-automatic...
Ok, a python rewrite sounds good. I'd speculate that it eases development and more people are speaking it and willing to contribute.
These are the issues I see so far with Vidalia.
- I am running Tor under Debian and they set it up to run under the debian-tor user account. Vidalia should run under which user account? How can Vidalia modify /etc/tor/torrc?
- When starting TBB, there is no progress bar. There was usability paper that people see the Vidalia icon and think they could start Firefox and are not aware, that Tor Browser is still running in background.
- No easily usable plugin structure.
- It would be awesome if people could make something such as a wordpress plugin, which sets up wordpress as hidden service. Just as an example, or another blog software or web service.
- No functional torrc editor (only in Vidalia alpha).
- can't easily use an obfsproxy bridge
- can't easily use a fashproxy bridge
- no first time connection wizzard (https://trac.torproject.org/projects/tor/ticket/2905)
- can't easily add multiple socks ports (for stream isolation)
On Wed, Feb 20, 2013 at 2:37 PM, Leo Unglaub leo@leo-unglaub.net wrote:
Hey friends, i want to inform you that i am working on a complete new control tool for Tor. I know some people use Vidalia for it, but i never liked the program and the people i showed vidalia often got confused.
It sounds like a cool project!
I don't know very much about the Gnome architecture -- will this work for users who aren't using the Gnome desktop?
Are you aiming for portability?
Also, what license are you thinking of going with?
One other thing -- I'd suggest naming your program something other than Vidalia, so that people can tell which program is which. (Other Tor controllers have included stem and TorK. If they were all named Vidalia, things would be very confusing.)
best wishes,
So i started to rewrite it from scratch and i am close to the release of the source code.
That would be... quite a substantial project. Kamran Khan, a GSoC student from a couple years back, did a GTK controller in python. What language did you use? How long have you been working on this, and by 'release of the source code' to you mean a functional prototype?
Personally I'd love to see a shiny, new Tor UI in python since that has our best language support in terms of controller libraries.
Cheers! -Damian
I think if it become as good as Vidalia and better, that would be most welcome.
Questions are:
* What is missing in Vidalia? * Why has development of Vidalia stopped? * Time to switch to python? * Time for a rewrite or better improve the existing code base?
Before developing it, I'd make a list of requirements/features.
Open Vidalia tickets:
https://trac.torproject.org/projects/tor/query?status=accepted&status=as...
Closed Vidalia tickets:
https://trac.torproject.org/projects/tor/query?status=closed&max=500&...
On Thu, Feb 21, 2013 at 01:39:08AM +0000, adrelanos wrote:
Closed Vidalia tickets:
https://trac.torproject.org/projects/tor/query?status=closed&max=500&...
This list is misleading, since I moved a few of Vidalia's tickets over to Tor's trac well after most Vidalia development had completed. Unfortunately, I believe the old Vidalia domain, and trac, are offline now. I assume we have some backup copies around somewhere, but I don't think they're exposed to the world in any usable way.
You might look at the Vidalia ChangeLog file to get a rough summary of its old trac tickets.
--Roger
On Thu, Feb 21, 2013 at 06:11:59PM -0500, Roger Dingledine wrote:
This list is misleading, since I moved a few of Vidalia's tickets over to Tor's trac well after most Vidalia development had completed. Unfortunately, I believe the old Vidalia domain, and trac, are offline now.
I am wrong! We still have a copy of the old Vidalia trac up at
https://trac-vidalia.torproject.org/
Enjoy your walk down memory lane. :)
--Roger
-
adrelanos -
Damian Johnson -
Fabian Keil -
Greg Norcie -
Leo Unglaub -
Matthew Finkel -
Mike Perry -
Nick Mathewson -
Roger Dingledine