tor-dev March 2016

tor-dev@lists.torproject.org

75 participants
71 discussions

Make TorBirdy Better [GSoc16]
by Pushkar Pathak 09 Mar '16

09 Mar '16

Hi, I am a sophomore in IIIT,Hyderabd and would like to take the project to build TorBirdy better as my GSoc project.I have experience in c++,python,javascript,bash. Any links to get me started would be obliged. Thanks, Pushkar.

1 0

Interest in GSOC 2016
by AKASH DAS 09 Mar '16

09 Mar '16

Hii Community, I am a great enthusiast in network security and is very keen to increase my knowledge in this field and I think this is a way I can learn more things. So, I want to do something for this org and wanna contribute to it. I am currently a second year undergrad CSE student in Indian Institute Of Information Technology, Sricity. So please can anyone guide me so that I can get into it as soon as possible and start contributing. Regards, Akash Das Indian Institute Of Information Technology, Sricity System Administrator

2 1

TorBirdy (HTTP Proxy) [GSoC 2016]
by Prakhar Pratyush 09 Mar '16

09 Mar '16

Hello, My name is Prakhar Pratyush. I've been working on this project- "Make TorBirdy Better (HTTP Proxy)" for a few days. I have tried to understand the project and I would like to discuss a few things. At present, what TorBirdy does is- it configures ThunderBird to access the internet through a proxy SOCKSv5 server provided by Tor Bundle. So, are we trying to design an standalone HTTP Proxy which will directly connect to Tor network entry point without needing entire Tor bundle or are we just trying to design an intermediatery HTTP Proxy which will then connect to Tor SOCKSv5 proxy using some form of tunneling or Masqueranding. Thanks Prakhar Pratyush 3rd year, IIT Roorkee

1 1

Re: [tor-dev] Leif's important piece on update golden keys
by Nathan Freitas 07 Mar '16

07 Mar '16

On Mon, Mar 7, 2016, at 11:11 AM, Spencer wrote: > Hi, > > >> > >> Holger Levsen: > >> https://reproducible-builds.org and > >> https://reproducible.debian.net > >> > > Thanks! > > > > > Nathan Freitas: > > https://f-droid.org/wiki/page/Deterministic,_Reproducible_Builds > > > > Thanks! > > However, even though reproducible-builds seems to address the manual > install as well, which is good, I read the problem as being the actual > backdoor of auto-update. > > Since my Dad will not be able to make this verification, removing > auto-update from the package is the only real resolution here. I think our goal is to remove any one person from having the authority to release an update. F-Droid or similar package managers should expect multiple signatures in the future instead of just one. Part of the trust people will place in projects or apps in the future is that they are not only open-source, but have a judicially diverse or robust set of signatories. > Besides, given the broken/missing auto-update opt-out in packages like > OrFox, it is difficult to trust the developers, since it is the user who > defines "malicious". Can you explain this more? I want to make sure I don't misunderstand what the issue is. +n

2 1

Re: [tor-dev] [valencia2016] Leif's important piece on update golden keys
by Nathan Freitas 07 Mar '16

07 Mar '16

On Sun, Mar 6, 2016, at 11:44 AM, Holger Levsen wrote: > Hi, > > On Montag, 29. Februar 2016, Spencer wrote: > > > [auto update] a threat model we must > > > take more seriously. > > > we are making real progress. > > Like what? > > https://reproducible-builds.org has the very long answer and > https://reproducible.debian.net shows the status for Debian in great > detail. > (And these pages have links to the status of other projects as well.) ... and also: https://f-droid.org/wiki/page/Deterministic,_Reproducible_Builds +n

2 1

Questions regarding the future of families
by Brian "redbeard" Harrington 06 Mar '16

06 Mar '16

For a few months I've been tracking this ticket: https://trac.torproject.org/projects/tor/ticket/6676 Regarding the state of family support. I've been working on a project which could be used to expand the number of running relays and have been trying to find the best way to coordinate this so as to make it both obvious who the operator is (which can be done with contact info) as well as to help users avoid building circuits within these related nodes. In the vein of "playing nicely" with the network my concern is that when running large scale infrastructure one needs to minimize the number of moving pieces possible. Ideally this would allow me (in the best case scenario) to supply a static family identifier en masse minimizing the need for managed configurations. In the worst case scenario (that of an entity trying to launch a sybil attack) the administrator would not even attempt to populate this so as to try and appear as separate nodes in the network. Do folks have suggestions on the best way to "play nice" here? --redbeard

5 5

(no subject)
by Alex Mourtziapis 05 Mar '16

05 Mar '16

HI, My name is Alex and I am looking forward in collaborating with you. I am particularly interested in working for Tor messenger but sadly things seemed a little unclear to me and the existing code here [1] didnt help me at all. If I got it right you want the messenger to be written in Node.js and use a lib like nw.js or electron to package and distribute it. Am I looking at the wrong direction? [1] https://gitweb.torproject.org/tor-messenger-build.git ᐧ

2 2

tor-roaster.org creates incentives for *non*-proper MyFamily configurations
by nusenu 05 Mar '16

05 Mar '16

(since this is not really part of that ticket I'm moving this reply to tor-dev) Replying to [comment:21 virgil][1]: > Re: comment #15 >> 2) there are no incentives for a relay operator to set it properly > > Roster aims to fix this. http://tor-roster.org Quite the opposite I think. tor-roster creates incentives for lazy operators because it does not require a proper MyFamily configuration to aggregate relays into a group. tor-roaster's way to group relays (one mutual connection into a group of relays is enough iirc) does not match tor's definition of MyFamily. While tor-roster's way to group actual set of relays to it's operator might represent a more accurate picture of reality than systems that do require proper MyFamily configs, it misses the possibility to create incentives for proper configurations. > For what it's worth, Roster also makes MyFamily a bit less painful to > work with because the detected families are now robust to changes > in the Family graph. For details see [3] This causes the offset between tor's and tor-roster's interpretation/definition. To give you an example, roster says this relay is part of a 24 relays group [4] even though it has only a mutual MyFamily with two other relays: https://atlas.torproject.org/#details/E6E18151300F90C235D3809F90B31330737CE… Ideally tor-roster would make it very clear on their website that groups do not require a complete mutual MyFamily agreement between all relays in that group, or require proper MyFamily configuration to create incentives for properly configured families. [1] https://trac.torproject.org/projects/tor/ticket/6676 [3] ttps://trac.torproject.org/projects/tor/ticket/16750 [4] http://tor-roster.org/family_detail/E26AFC5F718E21AC502899B20C653AEFF688B0D2

1 0

Next version of the algorithm
by Ola Bini 04 Mar '16

04 Mar '16

Hi, Here is the next version of the algorithm - put it in a gist to make it easier to look at: https://gist.github.com/olabini/343da01de8e01491bf5c Cheers -- Ola Bini (https://olabini.se) "Yields falsehood when quined" yields falsehood when quined.

4 16

Tor in Google Summer of Code 2016
by Damian Johnson 03 Mar '16

03 Mar '16

Interested in coding on Tor and getting paid for it by Google? If you are a student, we have good news for you: we have been accepted as a mentoring organization for Google Summer of Code 2016! https://summerofcode.withgoogle.com/organizations/6655685232164864/ Here's the facts: GSoC gives you the opportunity to work on your own Tor-related coding project with one of the Tor developers as your mentor. Your mentor will help you when you're stuck and guide you in becoming part of the Tor community. Google pays you 5,500 USD for the three months of your project, so that you can focus on coding and don't have to worry about how to pay your bills. https://www.torproject.org/getinvolved/volunteer.html.en#Projects Did we catch your attention? These are your next steps: Go look at the Google Summer of Code FAQ [1] to make sure you are eligible to participate. Have a look at our ideas list [2] to see if one of those projects matches your interests. If there is no project on that list that you'd want to work on, read the documentation on our website [3] and make up your own! Come to #tor-dev on OFTC [4] or let us know about your project idea here. Communication is essential to success in the summer of code, and we're unlikely to accept students we haven't heard from before reading their application. So really, speak up on this list or come to our IRC channel and talk to us! Finally, write down your project idea using our template [5] and submit your application to Google before March 25th [6]. We are looking forward to discussing your project idea with you! [1] https://developers.google.com/open-source/gsoc/faq [2] https://www.torproject.org/getinvolved/volunteer.html.en#Coding [3] https://www.torproject.org/docs/documentation.html.en#UpToSpeed [4] https://www.torproject.org/about/contact.html.en#irc [5] https://www.torproject.org/about/gsoc.html.en#Template [6] https://developers.google.com/open-source/gsoc/timeline

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev March 2016