- tor-dev - lists.torproject.org

Pluggable transports meeting tomorrow (16:00UTC Wednesday 3rd of December 2014)
by Yawning Angel 03 Dec '14

03 Dec '14

Hello! just wanted to remind you that the regular biweekly pluggable transports meeting is going to occur tomorrow at 16:00 UTC. Place is the #tor-dev IRC channel in the OFTC network. Thanks for your attention! -- Yawning Angel

1 0

Re: [tor-dev] Feedback on obfuscating hidden-service statistics
by George Kadianakis 02 Dec '14

02 Dec '14

"A. Johnson" <aaron.m.johnson(a)nrl.navy.mil> writes: > Hello all, > > <snip> > >> We put in some simple obfuscations in order to not reveal too >> sensitive data: we multiplied actual values with a random number in >> [0.9, 1.1] before including those obfuscated values in extra-info >> descriptors. Maybe there's something smarter we could do? Or is this >> okay? > > I actually think that additive rather than multiplicative noise > (i.e. randomness) makes sense here. Let’s suppose that you would like > to obscure any individual connection that contains C cells or fewer > (obscuring extremely and unusually large connections seems hopeless > but unnecessary). That is, you don’t want the (distribution of) the RP > cellcount from any relay to change by much whether or not C cells are > removed The standard differential privacy approach would be to *add* > noise from the Laplace distribution Lab(\epsilon/C), where \epsilon > controls how much the statistics *distribution* can multiplicatively > differ. I’m not saying that we need to add noise exactly from that > distribution (maybe we weaken the guarantee slightly to get better > accuracy), but the same idea applies. This would apply the same to > both large and small relays. You *want* to learn roughly how much RP > traffic each relay has - you just want to obscure the exact number > within some tolerance. > Hello Aaron, I posted an initial draft of the proposal here: https://lists.torproject.org/pipermail/tor-dev/2014-November/007863.html Any feedback would be awesome. Specifically, I would be interested in undertanding the concept of additive noise a bit better. As you can see the proposal draft is still using multiplicative noise, and if you think that additive is better we should change it. Unfortunately, I couldn't find any good resources on the Internet explaining the difference between additive and multiplicative noise. Could you expand a bit on what you said above? Or link to a paper that explains more? Or link to some other system that is doing additive noise (or even better its implementation)? Thanks!

2 4

Is PublishServerDescriptor needed to collect metrics?
by David Fifield 02 Dec '14

02 Dec '14

If a bridge has PublishServerDescriptor 0 does that prevent it from counting in metrics? If so, what's the right setting to enable metrics (0|1|v3|bridge,...)? Is there a way to send metrics data without also ending up in BridgeDB? David Fifield

4 7

New documentation for Tor Metrics website
by Karsten Loesing 02 Dec '14

02 Dec '14

Dear list, writing documentation is hard work. I'm sure you already knew that, but let me re-assure you that I now believe it, too. At least until I forget it again and carelessly start documenting something else that looks tiny and friendly and trivial to document. Anyway, I spent the last day (felt like half a week) on rewriting the relevant text for the Tor Metrics website, and I wrote a short glossary of terms I didn't want to explain over and over. Would people on this list mind reviewing my text and suggesting improvements? For reference, the old text and real graphs, tables, etc. are still available here: https://metrics.torproject.org/ The new text with sample graphs and the glossary are here, conveniently packaged into a single HTML page: https://people.torproject.org/~karsten/volatile/metrics.html I'd be happy for any suggestions here or off-list, either as comments, patches, or edited HTML files. Whatever works best for you works for me. I'll update the .html file whenever I include suggestions. I hope to put the new text on the real Tor Metrics next week. Thanks in advance, much appreciated! In fact, I'm pretty sure that all future visitors of Tor Metrics will appreciate your efforts. All the best, Karsten

4 8

Re: [tor-dev] tor-dev Digest, Vol 47, Issue 3
by teor 02 Dec '14

02 Dec '14

Hi Tom, Can you please describe the bug? Is it in the Tor Trac with a bug number? In general, if you start in the tor directory of a source distribution: (I'll use gitweb links, but you can use git and clone a local copy) tor/src/or https://gitweb.torproject.org/tor.git/tree/src/or Contains the tor onion routing-specific source code Your bug is likely to be here tor/src/common https://gitweb.torproject.org/tor.git/tree/src/common Contains the common facilities used by the tor/src/or code Your bug is also likely to be here tor/src/ext tor/src/trunnel tor/src/win32 https://gitweb.torproject.org/tor.git/tree/src Contain external libraries and platform-specific source Your bug is probably not here, or in any of the other directories teor pgp 0xABFED1AC hkp://pgp.mit.edu/ https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 http://0bin.net/paste/Mu92kPyphK0bqmbA#Zvt3gzMrSCAwDN6GKsUk7Q8G-eG+Y+BLpe7w… > Date: Tue, 2 Dec 2014 07:05:45 +0530 > From: Tom Mody <bug29195(a)gmail.com> > Subject: Re: [tor-dev] Help regarding Development > > hi list , > I am having troubles on bug solving , im new to it and i want to know where > to search in code for a particular bug ,, > please help ?? > >> On Tue, Nov 18, 2014 at 10:22 PM, rl1987 <rl1987(a)sdf.lonestar.org> wrote: >> >> 1. Read doc/HACKING. >> 2. Browse "Easy tickets" page [1] and see if you can solve any of them. >> >> [1] https://trac.torproject.org/projects/tor/query?status= >> accepted&status=assigned&status=needs_review&status= >> new&status=reopened&order=priority&keywords=~easy&col= >> id&col=summary&col=component&col=status&col=type&col= >> priority&col=milestone&report=30 >> >> 2014-11-14 03:53, Tom Mody ra??: >> >>> I would like to contribute to Tor ,, >>> >>> I'm not getting where to start .... >>> >>> Please , Can anyone help me how to start ??

1 0

Help regarding Development
by Tom Mody 02 Dec '14

02 Dec '14

I would like to contribute to Tor ,, I'm not getting where to start .... Please , Can anyone help me how to start ??

2 2

[PATCH] Tor Weather: Switched preferences and unsubscribes URLs.
by Ondrej Novy 01 Dec '14

01 Dec '14

--- weather/weatherapp/emails.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/weather/weatherapp/emails.py b/weather/weatherapp/emails.py index 2b5a0f5..cc298c9 100644 --- a/weather/weatherapp/emails.py +++ b/weather/weatherapp/emails.py @@ -179,7 +179,7 @@ def _add_generic_footer(msg, unsubs_auth, pref_auth): unsubURL = url_helper.get_unsubscribe_url(unsubs_auth) prefURL = url_helper.get_preferences_url(pref_auth) - footer = _GENERIC_FOOTER % (unsubURL, prefURL) + footer = _GENERIC_FOOTER % (prefURL, unsubURL) return msg + footer -- 1.9.3 (Apple Git-50)

1 0

Specification for 'How to Safely Sign a statement with a .onion key'
by Tom Ritter 01 Dec '14

01 Dec '14

Attached is a document written in the specification format for one aspect of CA-signed .onion addresses - specifically a "What is a safe way to sign (or not sign) a statement using the .onion key" It presents a couple options - I'd love to get feedback from folks on which they prefer. I recognize that no consensus or decision has been reached on whether to encourage or guide CAs on issuing .onions. (Although I'm in favor[0].) Although this is obviously written skewed towards CAs, it addresses a generic problem, and could be rewritten in that form. Excerpting from the Introduction/Motivation: Several organizations, such as Facebook, (collectively, 'applicants') have expressed a desire for an end-entity SSL certificate valid for their .onion Hidden Service address signed by a Certificate Authority (CA) present in browser trust stores. The existing Facebook .onion URL was issued by Digicert under a loophole in certificate issuance requirements. The Basic Requirements [0] is a document created by the Certificate Authority/Browser Forum that governs acceptable certificate issuing policies. Adherence to its policies is required for inclusion in many browsers' trust stores. .onion counts as an 'internal hostname' as it is not a recognized TLD by IANA. November 1, 2015 sets the deadline for when all internal server certificates must be revoked and no new certificates may be issued. Resolving the requirements and preferences for issuing .onion certificates before this date is extremely desirable, as it will determine if organizations such as Facebook will invest in the time and engineering effort needed to deploy Hidden Services. The full requirements for issuing .onion certificates is TBD, although recognition of .onion by IANA as a reserved domain is likely required. During discussions about the requirements for issuing for .onion one question that has arisen is what is a safe way to assert ownership of a .onion address and format an x509 certificate with a .onion Subject Alternate Name (SAN). This document is designed to address some of those questions. -tom [0] https://lists.torproject.org/pipermail/tor-dev/2014-November/007786.html

5 7

Reminder for weekly OONI dev meeting Monday 18:00 UTC (19:00 CET)
by Arturo Filastò 01 Dec '14

01 Dec '14

Hi, This is a reminder that today there will be the weekly OONI meeting. As I am writing this I am on a plane heading towards London and will be working on a GlobaLeaks workshop in some office there. The schedule for the workshop is not very well defined so I am not 100% sure I will manage to be online at the above defined time. If I am not there please start without me and I will be sure to read the backlog and write feedback asynchronously. ~ Arturo

1 0

Re: [tor-dev] [tor-reports] Tom's November 2014
by Karsten Loesing 01 Dec '14

01 Dec '14

On 01/12/14 02:34, Tom Ritter wrote: > With my shiny new ldap I got access to a user and official repo for > Depictor [0][1]. Not sure how I'll manage the difference. The code > for depictor is in both of them. Hi Tom, here's how I use official and user repos for my code: - The official repo contains what's deployed on the server, in its master branch. There are usually no other branches than master in that repo, though there would be for different version branches, or in the case of DocTor the old Java branch. I never rebase the master branch in the official repo. - The user repo has feature branches that I'm working on. For example, the feature branch for #23456 would be called task-23456, or task-23456-2, -3, etc. when I rebase that branch or mess with history in some other way. The user repo has no master branch, because that would be out of date most of the time anyway. I sometimes delete branches after they're merged into the official master branch, if I'm sure that nobody would base their work on those branches. There may be better approaches to using official vs. user repos, but maybe this is useful as a first data point for you. The Githax repo may contain more ideas: https://gitweb.torproject.org/githax.git/tree/doc/Howto.txt All the best, Karsten

1 0