Re: [tor-dev] DirAuth usage and 503 try again later

[Sebastian Hahn]

> On 18. Jan 2021, at 18:00, Roger Dingledine  wrote:
> While I was looking at moria1's directory activity during the overload,
> I did say to myself "wow that's a lot of microdescriptor downloads".
>
> So hearing that torpy isn't caching mirodescriptors yet makes me think
> that it's a good bet for explaining our overload last weekend.

The fact that torpy doesn't use microdescriptors makes me think there's
at least some other party involved here. Hopefully they can also improve
their software, but it makes me wonder what that software is :/

Cheers
Sebastian
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] DirAuth usage and 503 try again later

[Sebastian Hahn]

Hi James,

thanks for already working on patches for these issues! I will reply
inline some more.

> On 15. Jan 2021, at 23:56, James  wrote:
> 
> First of all, sorry if torpy hurt in some way Tor Network. It was 
> unintentionally.

I believe you :)

> In any case, it seems to me that if there was some high-level description of 
> logic for official tor client, it would be very useful.

Indeed. The more people work on alternative clients etc, the more we can
learn here. Perhaps you can help point out places where documentation
could help or something was not easy to understand.

> >First, I found this string in the code: "Hardcoded into each Tor client
> >is the information about 10 beefy Tor nodes run by trusted volunteers".
> >The word beefy is definitely wrong here. The nodes are not particularly
> >powerful, which is why we have the fallback dir design for
> >bootstrapping.
> At first glance, it seemed that the AuthDirs were the most trusted and 
> reliable place for obtaining consensus. Now I'm understand more.

The consensus is signed, so all the places to get it from are equally
trusted. That's the beauty of the consensus system :) The dirauths
are just trusted to create it, it doesn't matter who spreads it.

> >Once this
> >happens, torpy goes into a deathly loop of "consensus invalid,
> >trying again". There are no timeouts, backoffs, or failures noted.
> Not really, because torpy has only 3 retries for getting consensus. But 
> probably you are right because user code probably can do retry calling torpy 
> in a loop. So that will always try download network_status... If you have 
> some sort of statistic about increasing traffic we can compare that with time 
> when was consensus signed by 4 signers which enough for tor but not enough 
> for torpy.

Interesting, I ran torpy and on the console it seemed to try more
often. Perhaps it made some progress and then failed on a different
thing, which it then tried again.

To your second point, something like this can probably be done using
https://metrics.torproject.org. But I am not doing the analysis here
at the moment for personal reasons, sorry. Maybe someone else wants
to look at it.

> >The code frequently throws exceptions, but when an exception occurs
> >it just continues doing what it was doing before. It has absolutely
> >no regards to constrain its resources when using the Tor network.
> What kind of constraints can you advise?

I think instead of throwing an exception and continuing, you should
give clear error messages and consider whether you need to stop
execution. For example, if you downloaded a consensus and it is
invalid, you're likely not going to get a valid one by trying again
immediately. Instead, it would be better to declare who gave you the
invalid one and log a sensible error.

In addition, properly using already downloaded directory information
would be a much more considerate use of resources.

> >The logic that if a network_status document was already downloaded that
> >is used rather than trying to download a new one does not work.
> It works. But probably not in optimal way. It caches network_status only.

I may have confused it with asking for the diff. But that should not
be necessary at all if you already have the latest one, so don't ask
for a diff in this case.

> >I have
> >a network_status document, but the dirauths are contacted anyway.
> >Perhaps descriptors are not cached to disk and downloaded on every new
> >start of the application?
> 
> Exactly. Descriptors and network_status diff every hour was asking always 
> from AuthDirs.

Please cache descriptors.

> >New consensuses never seem to be downloaded from guards, only from
> >dirauths.
> Thanks for pointing out. I looked more deeply into tor client sources. So 
> basically if we have network_status we can use guard nodes to ask 
> network_status and descriptors from them. Otherwise using fallback dirs to 
> download network_status. I've implemented such logic in last commit.

Cool!

> >- Stop automatically retrying on failure, without backoff
> I've added delays and backoff between retries.
> 
> >- Cache failures to disk to ensure a newly started torpy_cli does not
> >  request the same resources again that the previous instance failed to
> >  get.
> That will be on the list. But probably even if there is a loop level above 
> and without this feature but with backoff it will be delays like: 3 sec, 5, 
> 7, 9; 3, 5, 7, 9. Seems ok?

Well, the problem is if I run torpy_cli in parallel 100 times, we will
still send many requests per second. From dirauth access patterns, we
can see that some people indeed have such access patterns. So I think
the backoff is a great start (tor client uses exponential backoff I
think) but it definitely is not enough. If you couldn't get something
this hour and you tried a few times, you need to stop trying again for
this hour.

> > Defenses are probably necessary to implement even if
> >torpy can be fixed very quickly, because 

Re: [tor-dev] DirAuth usage and 503 try again later

[Sebastian Hahn]

> On 11. Jan 2021, at 23:20, James  wrote:
> 
> Good day.
> 
> Is there any chance that torpy (https://github.com/torpyorg/torpy) was 
> triggered this issue 
> https://gitlab.torproject.org/tpo/core/tor/-/issues/33018 ?
> 
> Some wary facts:
> - Torpy using old fashion consensus (not mircodesc)
> - When consensus not present in cache (first time usage) it downloads 
> consensus from random directory authorities only.
> - Before August 2020 it was using plain HTTP requests to DirAuths. Now it 
> creates "CREATE_FAST" circuits to DirAuths (is that right way by the way?)
> 
> From other side:
> - Torpy store consensus on disk (so whenever client restart it must not 
> download full consensus again)
> - It will try download consensus after time which sets by valid_time field 
> from consensus which more than 1 hour (so it's not so often)
> - Torpy try get consensus by "diff" feature (so it's minimize traffic)
> 
> Still may be some of this features not working well in some conditions. Which 
> could cause a lot of consensus downloads in Jan 2020... Or may be you know 
> more info about this situation?

Hi there,

thanks for the message. I think it is very likely that torpy is
responsible for a at least a part of the increased load we're seeing on
dirauths. I have taken a (very!) quick look at the source, and it appears
that there are some problems. Please excuse any inaccuracies, I am not
that strong in Python nor have I done too much Tor development recently:

First, I found this string in the code: "Hardcoded into each Tor client
is the information about 10 beefy Tor nodes run by trusted volunteers".
The word beefy is definitely wrong here. The nodes are not particularly
powerful, which is why we have the fallback dir design for
bootstrapping.

The code counts Serge as a directory authority which signs the
consensus, and checks that over half of the dirauths signed it. But
Serge is only the bridge authority and never signs the consensus, so
torpy will reject some consensuses that are indeed valid. Once this
happens, torpy goes into a deathly loop of "consensus invalid,
trying again". There are no timeouts, backoffs, or failures noted.

The code frequently throws exceptions, but when an exception occurs
it just continues doing what it was doing before. It has absolutely
no regards to constrain its resources when using the Tor network.

The logic that if a network_status document was already downloaded that
is used rather than trying to download a new one does not work. I have
a network_status document, but the dirauths are contacted anyway.
Perhaps descriptors are not cached to disk and downloaded on every new
start of the application?

New consensuses never seem to be downloaded from guards, only from
dirauths.

If my analsis above is at least mostly correct, if only some few people
are running a scraper using torpy and call the binary in a loop, they
will quickly overload the dirauths, causing exactly the trouble we're
seeing. The effects compound, because torpy is relentless in trying
again. Especially a scraper that might call torpy in a loop would just
think that a single file failed to download and go to the next, once
again creating load on all the dirauths.

There are probably more things suboptimal that I missed here.
Generally, I think torpy needs to implement the following quickly if it
wants to stop hurting the network. This is in order of priority, but I
think _ALL_ (maybe more) are needed before torpy stops being an abuser
of the network:

- Stop automatically retrying on failure, without backoff
- Cache failures to disk to ensure a newly started torpy_cli does not
  request the same resources again that the previous instance failed to
  get.
- Fix consensus validation logic to work the same way as tor cli (maybe
  as easy as removing Serge)
- use microdescs/consensus, cache descriptors

I wonder if we can actively defend against network abuse like this in
a sensible way. Perhaps you have some ideas, too? I think torpy has the
ability to also quickly overwhelm fallback dirs in its current
implementation, so simply switching to them from dirauths is not a
solution here. Defenses are probably necessary to implement even if
torpy can be fixed very quickly, because the older versions of torpy are
out there and I assume will continue to be used. Hopefully that point
is wrong?

Thanks
Sebastian

___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] How do Ed25519 relay IDs look like?

[Sebastian Hahn]

Hi Damian,

> On 2. Aug 2020, at 00:04, Damian Johnson  wrote:
>
>> I'd like to use "ed25519 identity" or even just "identity" here going
>> forward.
>
> Gotcha. The name of 'identity' makes me wonder how this relates to
> relay fingerprints, which are the canonical identifier we use.
>
> Regardless, the more we can standardize the terminology we use the
> less confusing these fields will be.

The way I understand it is this: Relay fingerprints are based on the
RSA key, which will go away eventually. The canonical identifier will
be the identity. We should start that transition

Cheers
Sebastian
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal 320: Removing TAP usage from v2 onion services

[Sebastian Hahn]

Hi there,

> On 19. May 2020, at 19:55, Nick Mathewson  wrote:
> If we do decide to finally deprecate v2 onion services, that would be
> a significant maintenance burden reduced for us, but we'd have to
> handle the transition carefully.  Unlike all the other migrations
> we've done, there isn't a drop-in path to get the same functionality
> or keep the same identities with v3 onion services.  (And the problem
> is that there _can't_ be: the identities are strongly tied to
> 80-bit-truncated-SHA1 and RSA-1024, and the lack of key blinding makes
> them enumerable.)

I would be exstatic about not having V2 onions around anymore. This
would reduce a huge attack vector that incentivizes people to set up
malicious relays, which causes huge amounts of time lost, the relays
shouldn't have this opportunity to harvest onions, etc.

> The main reason I wrote this proposal is this: Any deprecation will
> probably cause a few users to stick with the old versions of the code
> for as long as they still work on the network, even if those versions
> become unsupported and insecure.  (After all, people who listen to our
> advice about what is secure and what isn't have already stopped using
> v2 onion services.) .

I kind of don't buy the statement in the parentheses, we don't seem
to discourage v2 strongly at all afaict. Or is there a warning when
you use it or connect to it, for example?

A question, is the HSDir flag for both v2 and v3 onions? If not we
could just take that away to break v2 at some point.

> Is it time to start this deprecation?  If so we need to start working
> on a timeline, and I agree with Teor that we'd need to figure out how
> that timeline would work with any walking onions timeline.

I think it should have been started a while ago :)

> What do others think?

Cheers
Sebastian
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Is there strictly a one-to-one BW scanner to BW auth relationship?

[Sebastian Hahn]

> On 24. Mar 2018, at 13:50, Rob Jansen  wrote:
>> I think moria1 runs its own, and Faravahar runs its own. I've lost track
>> of the others, but I'd guess that bastet also runs its own, and that
>> maatuska pulls numbers from a bwauth that tjr runs.
>> 
>> https://consensus-health.torproject.org/#bwauthstatus
> 
> Hmm. I wish we were more transparent about who is running scanners and which 
> bwauths consume results from which scanners. Something to keep in mind for 
> those of us working on next-gen replacement scanners.

It is at the discretion of the bwauth operator to ensure that
they're using a trusted source for their data. To me, that
means anything other than running the code myself is utterly
unacceptable, other operators might make other choices. I
think it makes sense to say that the operator of a given bw
auth is *responsible* for whatever they're voting on, whether
they run the bwauth themselves or not.

Cheers
Sebastian
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Tor in a safer language: Network team update from Amsterdam

[Sebastian Hahn]

Hi there tor-dev,

as an update to those who didn't have the chance to meet with us in
Amsterdam or those who haven't followed the efforts to rely on C less,
here's what happened at the "let's not fight about Go versus Rust, but
talk about how to migrate Tor to a safer language" session and what
happened after.

Notes from session:

We didn't fight about Rust or Go or modern C++. Instead, we focused on
identifying goals for migrating Tor to a memory-safe language, and how
to get there. With that frame of reference, Rust emerged as a extremely
strong candidate for the incremental improvement style that we
considered necessary. We were strongly advised to not use cgo, by people
who have used it extensively.

As there are clearly a lot of unknowns with this endeavor, and a lot
that we will learn/come up against along the way, we feel that Rust is a
compelling option to start with,  with the caveat that we will first
experiment, learn from the experience, and then build on what we learn.

You can also check out the session notes on the wiki (submitted, but not
posted yet).[1]

The real fun part started after the session. We got together to actually
make a plan for an experiment and to give Rust a serious chance. We
quickly got a few trivial things working like statically linking Rust
into Tor, integrating with the build system to call out to cargo for the
Rust build, and using Tor's allocator from Rust.

We're planning to write up a blog post summarizing our experiences so
far while hopefully poking the Rust developers to prioritize the missing
features so we can stop using nightly Rust soon (~months, instead of
years).

We want to have a patch merged into tor soon so you can all play with
your dev setup to help identify any challenges. We want to stress that
this is an optional experiment for now, we would love feedback but
nobody is paid to work on this and nobody is expected to spend more
time than they have sitting around.

We have committed to reviewing any patch that includes any Rust code to
provide feedback, get experience to develop a style, and actually make
use of this experiment. This means we're not ready to take on big
patches that add lots of tricky stuff quite now, we want to take it slow
and learn from this.

We would like to do a session at the next dev meeting to give updates on
this effort, but in the meantime, if team members would like to start
learning Rust and helping us identify/implement small and well-isolated
areas to begin migration, or new pieces of functionality that we can
build  immediately in Rust, that would be really great.

So, for a TLDR:

What has already been done:
- Rust in Tor build
- Putting together environment setup instructions and a (very small)
 initial draft for coding standards
- Initial work to identify good candidates for migration (not tightly
 interdependent)

What we think are next steps:
- Define conventions for the API boundary between Rust and C
- Add a non-trivial Rust API and deploy with a flag to optionally use
 (to test support with a safe fallback)
- Learn from similar projects
- Add automated tooling for Rust, such as linting and testing


Cheers
Alex, Chelsea, Sebastian

[1]: Will be visible here 
https://trac.torproject.org/projects/tor/wiki/org/meetings/2017Amsterdam/Notes
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] blacklisting relays with end-to-end correlation capabilities?

[Sebastian Hahn]

> On 08 Dec 2016, at 15:02, nusenu  wrote:
>> If we did this, also why would we blacklist the nonexit relays? That
>> seems to not make sense, as a relay operator could have multiple relays
>> that act as guard and exit simultaneously.
> 
> Exit relays with the guard flag have usually a guard probability of 0%
> according to onionoo. Since exit capacity is harder to get I was
> suggesting to blacklist the guard-only relays of such groups, so the
> exit capacity could still be used while breaking the end-to-end
> capabilities (if we can assume onionoo's guard_probability to be correct).

This is not guaranteed by the design.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Requiring p lines in consensuses

[Sebastian Hahn]

Hi there,

Karsten and I have been working on metrics-related tasks and one thing
that's got a potential to cause us pain going forward is that of
"p"-lines in consensuses. Tor has added them with consensus method 5 but
only declared them to be optional. In practice, every consensus ever
produced that used method 5 or later has added these lines, and I'd like
to require them to be included going forward. The reason is that without
looking at the consensus method, there's an ambiguity wrt exits: A
missing line either means "reject 1-65535" (method 5 or later) or "no
information" (anything before that).

I believe this should cause no compatibility issues and wouldn't require
a new consensus method. Is there some reason against doing this now?

Cheers
Sebastian
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] [::]/8 is marked as private network, why?

[Sebastian Hahn]

Hey,

I've been wondering about the private_nets const in src/or/policies. It
was added in a96c0affcb4cda1a2e0d83d123993d10efc6e396 but Nick doesn't
remember why, and I'm hoping someone has an idea (maybe teor, who I've
CCed here, who documented this in a later commit?). If nobody knows why
we do this I think we should remove it as likely incorrect.

Cheers and thanks
Sebastian
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Dynamically updating tor

[Sebastian Hahn]

Hi list,

I recently played with the Kitsune[0] framework to figure out whether we
might be able to use it to dynamically update (that is, perform an
update without restarting the process) Tor relays on Linux. This post is
just to make you aware such a thing has been attempted. I deem it
currently infeasible due to the high overhead (in developer time) and
the lack of confidence in the resulting update binaries. Nevertheless,
people might want to take a look. I have not cleaned this up at all and
it is quite dependent on the software currently available in Debian
jessie, including the versions of OpenSSL and libevent.

In short, THIS WILL NOT WORK FOR YOU UNLESS YOU ARE VERY LUCKY AND
ARE PREPARED TO SPEND SIGNIFICANT TIME WITH IT. THIS IS NOT RELEASE
QUALITY CODE BY A LONG SHOT.

The Tor code is in a branch[1] in my tor repo and there's a tarball[2]
of the modifications I had to make to Kitsune to enable building it with
a newer version of one of its dependencies. This is a generally exciting
topic imo, but I currently have no intentions to keep pursuing this
angle more because of other commitments and due to the fact that I think
it is unrealistic to expect the Tor developers to learn this tool. If
there is serious interest both in improving Kitsune as well as dynamic
updatability support for Tor, I might reconsider in the future.

Cheers and have fun
Sebastian

[0]: http://kitsune-dsu.com / https://github.com/kitsune-dsu/kitsune-core
[1]: https://gitweb.torproject.org/sebastian/tor.git/log/?h=dsu
[2]: https://people.torproject.org/~sebastian/kitsune-core.tar.gz
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Draft proposal -- no number yet: How to safely drop support for old clients.

[Sebastian Hahn]

Hi,

comments inline.

On 09/30/2015 12:01 PM, Nick Mathewson wrote:

Early versions of Tor checked the recommended-versions field in the
directory to see whether they should keep running.  If they didn't
recognize


you did the thing where you



To override this, a Tor instance may include a configuration option,
"IgnoreDisabledVersion VERSION".  It is an error to set this option when
*not* running with a disabled version.


This does not work unless the client already has a consensus that they 
have parsed so they know they're running a disabled version. I 
appreciate the sentiment here (don't allow people to blindly set the 
option), but I'm not sure it's worth it.



3.4. Disabling all versions that don't support this proposal

We should allow 'n' (short for "node") as a synonym for 'r' in
consensus documents.  Later, if we want to disable all Tor versions
before today, we can change the consensus algorithm so that the
consensus (or perhaps only the microdesc consensus) is spelled with
'n' lines instead of 'r' lines.  This will create a consensus which
older clients and relays parse as having no nodes.


Hrm. I'm not a fan of this, it seems like a pretty sad hack. I don't 
have an alternative ready unfortunately.



3.5. In the event of overzealous retries

We need to be sure that client running versions from 0.2.1 through
0.2.6 respond gracefully to the responses above.  In particular, we
need to make sure that they don't continually retry the connections
that fail in these ways: that would put a lot of extra load on the
network.

Above, I recommend stalling connections rather than just closing
them.  This may prevent the risk of retries, at the risk of using
additional relay resources.


Stalling is much less preferable than closing to me. We should actually 
do the analysis and do it well to know if we actually have to do it, imo.


Cheers
Sebastian
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] [tor-reports] Sebastian's August 2015

[Sebastian Hahn]

> On 11 Sep 2015, at 07:04, ilv  wrote:
>> Next up is more of the same, especially focusing on website tickets
>> and preparing the community team's dev meeting contributions.
> 
> Maybe we could have a session at the dev meeting to talk about the
> website (content, structure, translations, etc.). What do you think?
> 
> (cc'ing @tor-dev in case more people are interested)

Yes, Lunar has suggested this as well.

Cheers
Sebastian


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] tor's definition of 'median'

[Sebastian Hahn]

 On 13 Aug 2015, at 18:50, Nick Mathewson ni...@alum.mit.edu wrote:
 
 On Wed, Aug 12, 2015 at 5:34 PM, nusenu nus...@openmailbox.org wrote:
 from today's measurement meeting:
 
 15:00:20 virgil karsten: I've decided I'm going to fix the definition of 
 median
 15:00:26 virgil in the tor sourcecode
 15:00:36 karsten virgil: is it broken?
 15:00:53 karsten or just not specified as clearly as it should be?
 15:01:01 virgil for ordered list {a,b,c,d}, it returns b instead of 
 (b+c)/2.
 15:01:24 karsten yes. maybe that's for a reason (which I don't know).
 15:01:40 virgil I look forward to hearing this reason when my patch is 
 rejected.
 15:01:41 karsten like, using value (b+c)/2 would break for some reason, 
 whereas any of a, b, c, d would be fine.
 15:01:45 Sebastian you cannot do that
 15:01:51 Sebastian without breaking Tor's voting
 15:02:21 Sebastian Tor's specification requires low median for a bunch of 
 directory stuff
 
 
 I'd be interested in the reason as well.
 
 The correct fix here is to update the code documentation to define the
 functions as returning the low-median, and to update dir-spec.txt to
 say so too.  I'd accept documentation patches like that.

The documentation for the code already says that. The spec could be
updated to say low-median consistently, tho.

Cheers
Sebastian
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Brainstorming ideas for controller features for improved testing; want feedback

[Sebastian Hahn]

Hi!

 On 20 Mar 2015, at 16:55, Nick Mathewson ni...@torproject.org wrote:
 
 IDEAS
 =

Many great ideas! Here's a few more, mostly just adding a bit to the
things you already listed. Some of them make me kind of uneasy because
they really are testing only and could be used for much unhappiness on
the real network:

Expose more per-circuit information to the controller, like bytes
sent/received on this circuit, maybe even an event any time new bytes
are received (testing only). This could help debug stuff like slow
connections, inefficiencies in the protocol, etc.

Allow write access to everything in the state file (testing only).

Access to all stored cached documents (TESTING ONLY) (thinking about
consensus diffs, hs descriptors, etc). Also an event (TESTING ONLY)
whenever such a document is accessed/served.

Modify state of existing connections at relays (TESTING ONLY), like
redirecting to a different host, killing it, etc.

I'll add more if I think of anything else.

Cheers
Sebastian


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] #if 0 unused functions?

[Sebastian Hahn]

Hi teor,

 On 22 Mar 2015, at 14:41, teor teor2...@gmail.com wrote:
 Date: Sun, 22 Mar 2015 05:12:03 +0100
 From: Sebastian Hahn sebast...@torproject.org
 To: tor-dev@lists.torproject.org
 
 Hi there,
 
 we have some functions which we never call anywhere. In many cases, it
 appears we shouldn't delete them from the source because they belong
 there - the thing I initially stumbled across was
 ed25519_seckey_write_to_file(), for example. But I also don't see why
 compiling it and potentially including it in our binary makes any sense.
 
 Thoughts?
 
 Cheers
 Sebastian
 
 I'm think that removing / disabling unused code is a great idea, but I wonder 
 what happens over the long term:
 
 [How] do we prevent bit-rot on the disabled code?
 
 Does the disabled code have unit tests?

I meant code which doesn't have unit tests currently.

 Should we add unit tests or keep them active to prevent bit-rot?
 Or should any unit tests be disabled too?
 
 I wonder if we could unit test unused code, but not link it into the tor 
 binary.
 This would make sure it works if we ever want to use it in future, but 
 without the risks and performance impacts of including unused code in the 
 binary.
 
 There could be issues with this strategy that I haven't thought of. Like the 
 added maintenance cost involved in keeping unused code and unit tests 
 up-to-date.
 
 Perhaps we could:
 * remove entirely if we're unlikely to ever use the code,
 * disable if we want to keep it around for future reference, and
 * unit test it, but not link it in to the tor binary, if we think we'll use 
 it soon.
 
 Which category do most of the unused functions fall into?

I don't know how much of this code there actually is, I would just
do it as I spot such code, not as a big project to identify it all
(tho looking at a call graph including unit tests should give you
some idea).

Cheers
Sebastian


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] #if 0 unused functions?

[Sebastian Hahn]

Hi there,

we have some functions which we never call anywhere. In many cases, it
appears we shouldn't delete them from the source because they belong
there - the thing I initially stumbled across was
ed25519_seckey_write_to_file(), for example. But I also don't see why
compiling it and potentially including it in our binary makes any sense.

Thoughts?

Cheers
Sebastian
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Removal of Vidalia-related content from Tor's website

[Sebastian Hahn]

Hi,

I'm currently working on cleaning up the website. Our Vidalia bundles
haven't been maintained in a long time, Tor Browser is the best way to
use Tor as a client and nobody is stepping up to replace maintainership
of the windows bundles.

I'm removing the link to these bundles as well as the related
documentation from the Website.

Cheers
Sebastian


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Internet-wide scanning for bridges

[Sebastian Hahn]

Hi there,

On 14 Dec 2014, at 20:06, Vlad Tsyrklevich v...@tsyrklevich.net wrote:
 I'm not against keeping some around, but this warning is unlikely to turn 
 around the thousands that currently match this configuration--hopefully it'll 
 just encourage future bridge operators to use a 'safer' configuration. The 
 obfs4proxy README shows users how to set-up obfs4 running over port 443 which 
 is probably the most desirable option: those users can evade network 
 restrictions without enabling discovery by scanning.

I really dislike warnings unless we absolutely need to have
them, and this imo is in the category of change the default,
update the docs, especially because just changing the port
is not a real solution in my book.

Cheers
Sebastian



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Git hosting changes, git:// support discontinued

[Sebastian Hahn]

Hi Jason,

On 30 Nov 2014, at 23:32, Jason Cooper t...@lakedaemon.net wrote:
 On Sun, Nov 30, 2014 at 06:48:09PM +0100, Sebastian Hahn wrote:
 Access via https:// has been provided for years, and should continue
 to work without any hiccups.
 
 No issue there for folks that prefer the extra layer.

My point is basically that there's no reason not to always use the extra
layer.

 If there are questions or concerns, let's here them.
 My problem with cancelling access via git:// is that the alternative
 (https) trains new users to think they need to trust the server.  The
 fact is they don't.  They need to trust the person identifying himself
 as Nick Mathewson who holds the private key for 8D29319A.

We don't just have tor.git up there, a lot of repos don't include a
single signed commit or even tag. You're right that trusting the server
is nothing a good dev should do, but I'm also not worried about our
demographic here.

On a tangent, referring to keys by their short (or long, for that
matter) keyid is not a good idea. How to verify Nick actually has the
blessing of the Tor project (or any subset of people therein, etc) to
sign tags is yet another problematic area without a real solution.

In conclusion: Yes, don't trust the server. I sleep a lot better
pretending that people don't trust it.

 I'd much prefer they be taught not to trust the path *or* the server.
 
 Please consider restoring git:// access.

I have considered it, but my conclusion remains not to do it for now.
Further discussion is invited.

Thanks
Sebastian



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Understanding bwauth data in Stem?

[Sebastian Hahn]

Hi there,

On 21 Nov 2014, at 23:44, Damian Johnson ata...@torproject.org wrote:
 In other words, if I sorted the descriptors by measured value, what would
 that order mean?
 
 I *think* that would be the ordering of 'relays who receive the most tor
 client traffic due to having a more highly weighted heuristic for relay
 selection'.

that would be accurate, is my understanding

 That said, this is an area I'm honestly not that familiar. I'm looping in
 Sebastian, Karsten, and Roger. As mentioned on irc Sebastian has touched the
 Bandwidth Authorities most recently, so he's likely the most knowledgeable at
 present about this space.

I've tried fixing stuff and have mostly given up. I'm not too familiar with
it, and probably can't help too much. I'll try to answer questions if there
are any, tho.

 Separately, is there a way (using Stem or some other tool) to see the raw
 bwauth measurements rather than the weights?
 
 I don't believe this is exposed anywhere, so only the bandwidth authority
 operators have this. And by 'have' I mean 'maybe in their logs, or possibly
 not even surfaced at all'.

We could publish those. Let's ask karsten if he thinks that'd be worthwhile?

 Is that a calculation I can reverse?
 
 Maybe run a bandwidth authority of your own? This could be a terrible idea.
 Sebastian would know.

You can look at the votes before a consensus was formed, they'll continue the
values for each measuring bwauth. Running your own bwauth might be interesting,
but it's probably not very useful if you want to learn values for the
deployed network.

Cheers
Sebastian
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Building TOR using Visual Studio

[Sebastian Hahn]

On 18 Oct 2014, at 06:29, teor teor2...@gmail.com wrote:
 Are there no-cost, non-license-restricted compilers available for Windows 
 that support C99?
 
 This could be a way out for those who don't wish to pay for the VS 2013 
 upgrade.
 
 But it's a bit more of a barrier than using an existing compiler on the 
 system.

Well, it's always possible to compile it using mingw with gcc. Not that
big of a barrier imo?
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Building TOR using Visual Studio

[Sebastian Hahn]

On 17 Oct 2014, at 18:07, M. Ziebell ziebell_ma...@posteo.de wrote:

 Looking at this blog post [1] even the support for C99 in VS2013 is
 limited. I don't know if tor hit the limitations, that's for you to
 decide.
 
 C99 is 15 years old ... It should be sane to use it.

Please also see bug #13260 and its friend #13233. We might re-evaluate
based on this input here, tho I'm inclined not to...

Cheers
Sebastian

https://trac.torproject.org/projects/tor/ticket/13260
https://trac.torproject.org/projects/tor/ticket/13233
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Scaling tor for a global population

[Sebastian Hahn]

On 28 Sep 2014, at 02:12, Tom Ritter t...@ritter.vg wrote:
 why not also change the consensus
 and related document formats to be something more efficient than ASCII
 text?  Taking the latest consensus and doing some rough estimates, I
 found the following:
 
 Original consensus, xz-ed: 407K
 Change flags to uint16: ~399K
 +Removing names: 363K
 +Compressing IPv6 to 16Bytes + 4 Bytes - 360K
 +Compressing IPv4 to 4 Bytes + 4Bytes + 4bytes - 315K
 +Compressing the Datetime to 4 bytes - 291K
 +Compressing the Version string to 4bytes - 288K
 +Replacing reject 1-65K to a single byte - 287K
 +Replacing Bandwidth=# with a 4 byte - 273K
 
 These numbers are optimistic - you won't see quite this much gain, but
 if I'm understanding you correctly that the consensus is painful, it
 seems like you could save at least 50K-70K out of 400K with relatively
 straightforward changes.

This analysis doesn't make much sense, I'm afraid. We use compression
on the wire, so repeating flags as human-readable strings has a much
lower overhead than you estimate, for example. Re-doing your estimates
with actually compressed consensuses might make sense, but probably
you'll see a lot less value.

Cheers
Sebastian
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Scaling tor for a global population

[Sebastian Hahn]

On 28 Sep 2014, at 16:33, Tom Ritter t...@ritter.vg wrote:
 On 28 September 2014 07:00, Sebastian Hahn sebast...@torproject.org wrote:
 This analysis doesn't make much sense, I'm afraid. We use compression
 on the wire, so repeating flags as human-readable strings has a much
 lower overhead than you estimate, for example. Re-doing your estimates
 with actually compressed consensuses might make sense, but probably
 you'll see a lot less value.
 
 All of those numbers were after compressing the consensus document
 using xz, which is the best compression method I know.

sorry, I completely missed that you showed compressed numbers. Interesting
results!
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal 220 (revised): Migrate server identity keys to Ed25519

[Sebastian Hahn]

Hi Nick,

On 25 Feb 2014, at 17:18, Nick Mathewson ni...@torproject.org wrote:
   To mirror the way that authority identity keys work, we'll fully
   support keeping Ed25519 identity keys offline; they'll be used to
   sign long-ish term signing keys, which in turn will do all of the
   heavy lifting.  A signing key will get used to sign the things that
   RSA1024 identity keys currently sign.

There was a discussion of this point on tor-talk just now. s7r (one
of the nice support people) was also present, maybe he will follow up
here as well.

Basically, the operational complexity of doing this seems to be
under-appreciated here, and we're wondering if the added code
complexity can possibly be worth it. Maybe we should ask some of the
super big relays to weigh in.

Cheers
Sebastian
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal idea: Stop assigning (and eventually supporting) the Named flag

[Sebastian Hahn]

On 18 Apr 2014, at 21:56, Nick Mathewson ni...@alum.mit.edu wrote:
 Thanks!  I've added this as proposal 235.

Code review down to 0.2.3.x has shown that the naming-related code
hasn't changed much at all, and no issues were found which would mean a
Named-flag free consensus would cause any problems.

gabelmoo and tor26 have stopped acting as Naming Directory Authorities,
and - pending any issues - will stay that way. For now, the two will
continue to collect naming-related statistics to ensure we can turn it
back on in case any trouble is identified.

Cheers
Sebastian

___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] [GSoC] Consensus diffs - Fifth report

[Sebastian Hahn]

On 02 Aug 2014, at 21:25, Daniel Martí mv...@mvdan.cc wrote:
 This is the fifth status report of my Google Summer of Code project,
 which is to implement consensus diffs for Tor. My mentors - Sebastian and
 Nick - and myself usually hold meetings on IRC on wednesday at 16h UTC.

14h UTC.


___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal idea: Stop assigning (and eventually supporting) the Named flag

[Sebastian Hahn]

On 18 Apr 2014, at 15:02, Karsten Loesing kars...@torproject.org wrote:
 If I understand the proposal correctly, operators will still be able to
 name their relay or bridge, and people can still find it in Atlas or
 Globe by this nickname.  If so, great!

Yes, this is in no way related to the nickname field.

   The gabelmoo and tor26 directory authorities can simply remove the
   NamingAuthoritativeDirectory configuration option to stop giving out
   Named flags. This will mean the consensus won't include Named and
   Unnamed flags any longer. The code collecting naming statistics is
   independent of Tor, so it can run a while longer to ensure Naming can
   be switched on if unforeseen issues arise.
 
 What's the process here?
 
 Ask on tor-dev@ if anybody sees a problem if the Named and Unnamed
 flags go away, wait for a week, and then just do it?

I don't know, I want to move gabelmoo to a new machine and don't really
want to set up the naming system. So I guess the above process as soon
as possible :)

Cheers
Sebastian
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Proposal idea: Stop assigning (and eventually supporting) the Named flag

[Sebastian Hahn]

Filename: xxx-kill-named-flag.txt   
  
Title: Stop assigning (and eventually supporting) the Named flag
Authors: Sebastian Hahnn
Created: 10 April 2014
Target: 0.2.5
Status: Draft

1. Intro and motivation

   Currently, Tor supports the concept of linking a Tor relay's nickname
   to its identity key. This happens automatically as a new relay joins
   the network with a unique nickname, and keeps it for a while. To
   indicate that a nickname is linked to the presented identity, the
   directory authorities vote on a Named flag for all relays where they
   have such a link. Not all directory authorities are currently doing
   this - in fact, there are only two, gabelmoo and tor26.

   For a long time, we've been telling everyone to not rely on relay
   nicknames, even if the Named flag is assigned. This has two reasons:
   First off, it adds another trust requirement on the directory
   authorities, and secondly naming may change over time as relays go
   offline for substantial amounts of time.

   Now that a significant portion of the network is required to rotate
   their identity keys, few relays will keep their Named flag. We should
   use this chance to stop assigning Named flags.

2. Design

   None. Tor clients already support consensuses without Named flags,
   and testing in private Tor networks has never revealed any issues in
   this regard.

3. Implementation

   The gabelmoo and tor26 directory authorities can simply remove the
   NamingAuthoritativeDirectory configuration option to stop giving out
   Named flags. This will mean the consensus won't include Named and
   Unnamed flags any longer. The code collecting naming statistics is
   independent of Tor, so it can run a while longer to ensure Naming can
   be switched on if unforeseen issues arise.

   Once this has been shown to not cause any issues, support for the
   Named flag can be removed from the Tor client implementation, and
   support for the NamingAuthoritativeDirectory can be removed from the
   Tor directory authority implementation.

4. Open questions

   None.

___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] TorBEL migration

[Sebastian Hahn]

On Apr 30, 2013, at 3:17 AM, Sreenatha Bhatlapenumarthi 
sreenatha@gmail.com wrote:
 Hi,
 
 My name is Sreenatha Bhatlapenumarthi. I'd like to migrate TorBEL 
 from TorCtl to Stem as a part of GSoC'13 project this summer.

Hi Sreenatha,

great to hear from you!

 Damian pointed out that there is still some improvement to be made to
 TorBEL to replace DNSEL. I've downloaded the source code from [0] and 
 started looking around for missing functionality and components that use 
 TorCtl(and hence need migration) and here is what I've observed:
   • TorBEL components that use TorCtl
   • Controller - control.py
   • Logger - logger.py
   • Router - router.py
   • Tests - tests.py
   • The main interface - torbel
   • Exit policies of narrow_exit routers can be checked in 
 Router.will_exit_to[1]
   • RouterRecord.update_to()[2] can use Router Status Entry 
 descriptors[3] to update the router's attributes
   • I think the following line[4] in network.py has a bug - 
 socket.inet_aton works only for IPv4 addresses[5].
   •  (ip,) = struct.unpack(I, socket.inet_aton(peer.host))

Quite possibly! ipv6 support in Tor was far away when that code
was written.

 Please let me know if I've missed something or got something wrong.

You might want to check out the TorBEL trac tickets [6] if you haven't,
to get some further ideas about things that need doing.

 I donot have any background on Haskell as such but if you recommend that I
 learn it inorder to understand TorDNSEL, I am prepared to spend the required
 amount of time learning it during May before the coding period starts. Also, 
 can 
 you give me a rough estimate of how long you think the migration will take so 
 that 
 I can plan the project timeline accordingly?

Learning Haskell will be much less valuable than investing the time to
learn what's needed from a dnsel replacement. Also note that unless
you have experience with functional programming languages, Haskell will
not be just another language, but rather you'd first spend some time
wrapping your head around functional programming.

As for the timeline, that's a bit tricky. Migrating to stem will
probably require a fair deal of refactoring, as the current
implementation makes heavy use of TorCtl internals, and especially the
Router class is tailored to TorCtl. Damian might have some input here
on how much TorCtl and stem differ here, and what (some of) the
architectural differences will be. That said, if you invest some time
before the actual coding period to get up to speed on what the tool
is actually supposed to do, you have a great shot at porting in 6
weeks. Three weeks learning stem and porting, 3 weeks testing and
fixing issues you'd encounter along the way, I'd assume. The rest of
the summer could be spent on improving stem, or on implementing
additional functionality. All this depends on your Python skills tho,
of course. Ultimately, it's  your job to figure out and propose a
timeline (but don't worry, it's not like that'll be set into stone
the moment the program starts).

 Thanks for taking your time out to read this.

My pleasure, thanks for your interest in TorBEL!

 Cheers,
 Sreenatha

All the best
Sebastian

[6]: 
https://trac.torproject.org/projects/tor/query?status=acceptedstatus=assignedstatus=needs_informationstatus=needs_reviewstatus=needs_revisionstatus=newstatus=reopenedcomponent=TorDNSEL%2FTorBELorder=priority
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Parallel release series for directory authorities?

[Sebastian Hahn]

On Sep 1, 2012, at 1:02 AM, Roger Dingledine wrote:

 On Sat, Sep 01, 2012 at 12:36:51AM +0200, Linus Nordberg wrote:
 Just a thought. A few of the directory authorities, I think at least
 three, as well as the bridge authority run packages/ports only, not
 builds from source. We'd have to package our -da branch ourselves for
 those I guess. But that's probably a better option than the others.
 
 Right. The people who are willing to run from git generally are fine
 running master (and helping to find bugs), so it's really the people
 who only run from packages that we need to consider here.
 
 Maybe we should just enumerate the eight directory authorities and their
 habits, rather than trying to generalize too early?
 
 - I generally run moria1 from git master, to maximize the cool new bugs
 I can find.
 
 - I think weasel only runs tor26 from debs. I wonder what he would think
 of us asking him to deb up a separate git branch for just a few people?
 He says I don't mind running 0.2.4 - it's not worse than running a fork
 of 0.2.3.
 
 - Linus runs maatuska from git, and is happy with git master too.
 
 - I'm not sure about gabelmoo, dizum, dannenberg, turtles, and urras.

I run gabelmoo from git, typically not tip of master early in a release
series except when necessary.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Win32/MSVC: tinytest.c problems

[Sebastian Hahn]

On May 5, 2012, at 3:30 PM, Gisle Vanem wrote:

 There are 2 problems with the use of 'stricmp()' (line 295) in tinytest.c.
 
 1. As it is now, I'm getting an undefined reference to 'stricmp' when  
 linking tinytest.exe and using '-nodefault:oldnames' in the link-flags.  Can 
 we please remove this lib from the requirements?
 
 2. 'stricmp()' is used nowhere else in Tor. But rather 'strcasecmp()'.
 Can we use that for consistency instead? Need to include or.h
 to include src/compat.h.
 
 Like the lines from src/compat.h says:
 /* Windows names string functions differently from most other platforms. */
 #define strncasecmp _strnicmp
 #define strcasecmp _stricmp
 
 How about this little patch:

Tinytest is supposed to be an independent library, so including a
tor-specific header file doesn't work here.

 There are more MSVC-issues in other test/*.c files. I can get back to that.

Please do, thanks.

___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] [PATCH] tor-exit-notice.html: shorten Cornell URLs

[Sebastian Hahn]

On Mar 17, 2012, at 8:37 AM, Christian Kujau wrote:

 Hi,
 
 these ever so long law.cornell.edu URLs are now automatically redirecting 
 to a shorter version - let's use that in our tor-exit-notice.html as well.
 
 Christian.

Hi, and thanks for the patch. I've filed a trac ticket[0] for this patch. Please
follow up there.

Thanks!
Sebastian

[0]: https://trac.torproject.org/projects/tor/ticket/5410 

___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal 193: Safe cookie authentication

[Sebastian Hahn]

On Feb 10, 2012, at 12:02 AM, Robert Ransom wrote:
 The sole exception to ‘non-safe cookie authentication must die’ is
 when a controller knows that it is connected to a server process with
 equal or greater access to the same filesystem it has access to.  In
 practice, this means ‘only if you're completely sure that Tor is
 running in the same user account as the controller, and you're
 completely sure that you're connected to Tor’, and no controller is
 sure of either of those.

Why is it so hard to do this? Can't we tell controllers to do a
check of permissions, and only if they can't be sure refuse to use the
requested path by default unless a config whitelist or user prompt
allows it? I think that's a lot easier to implement for controllers, and
I just don't really see the huge threat here. If you have malicious
system-wide software on your host, you lost anyway.

___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Using Tor w/o GeoIP

[Sebastian Hahn]

On Jan 20, 2012, at 1:48 AM, Nathan Freitas wrote:

 Is it the geoip database only required if you are specifying
 Exit/Entrances nodes by country code?
 
 I am thinking about not fully unpacking it into Android storage, unless
 the user activates those option in Orbot. This will save quite a bit of
 internal storage space.
 
 Thanks!
 
 +n8fr8

As a client, the geoipdb is only required for specification of nodes by
country code, yes. On relays/bridges, we also use it for statistics. One
idea for you might be to not include the geoip thing by default at all,
and only when the user requests a feature that requires it do you inform
them that they need to fetch another file. I'm not clear if that's legal
on Android, but if it is, it could be an effective mechanism.

Also we've had plans to make the geoip db a thing the tor client
downloads on demand only, but haven't gotten far with that. If you
wanted to help with that on an 0.2.4 timeframe, that'd probably be
fantastic.

___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal 178: Require majority of authorities to vote for consensus parameters

[Sebastian Hahn]

On Nov 25, 2011, at 9:58 PM, Sebastian Hahn wrote:
 On Nov 25, 2011, at 9:27 PM, Sebastian Hahn wrote:
 I have since become convinced that it would be better to get
 this implemented quickly, even if it doesn't have a generic
 prevent this param from being set mechanism. I would thus like
 to change the proposal to the following (also available in my
 prop178 branch in my torspec repository). The diff is available at
 https://gitweb.torproject.org/sebastian/torspec.git/commitdiff/db9a429d005ae05ad0841e6026941594d5740b0b
 
 I meant to also send the proposal here, inline. Looks like I messed
 that up. Here goes:

Looks like Nick liked the revised proposal and implementation after
fixups, the code and spec changes have been merged and the
proposal was marked closed just a few minutes ago.

Thanks all!
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] git-rw moved hosts - new ssh host key

[Sebastian Hahn]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hey there people who have repositories hosted on tpo hardware,

weasel migrated cupani to our shiny new VM server. Along with this came
a change of ssh host key, so please be ready to modify your known_hosts
file accordingly when you next push. The new ssh key fingerprint is:

ssh-rsa e7:a0:63:15:a6:d3:41:e3:cf:92:6e:78:ea:cb:d7:ee

After doing the migration, we took the opportunity to run a full
git gc --aggressive on each repository, which should result in smaller
clone sizes and generally faster clones. Take this as a reminder to
occasionally optimize your local repositories too, your pushes will
benefit and you can reclaim some lost space :)

Sorry this went through without prior notice, I hope nobody's work
was interrupted.

Let me know if there is anything amiss, we don't expect any
kind of issues tho.

All the best
Sebastian
-BEGIN PGP SIGNATURE-

iQEcBAEBAgAGBQJOrbUZAAoJEKlsb90UDJYb77AIAIXIW5bkuXVfOB8DEYwh93vN
ddIlxAea8QvrY8hebqHNYGC9a/GgHkgT3+fDGRLW1EsHgTb6YzpYT4Jhnrj1BKHu
37Kn1UzIyuS1X6X1CzFKJzoa6Z2Wej8lmpcOMk5m8GXE+MTMnYV/3kAZ+qsRgJOi
GLO75HIFZc4FbD/wy2xAU6it3aBMPP1wszKK30wtU0oCldo20FDeltqaXt9GlWav
jimBI+AcWBhgFr6hx7FKVLsLNlNkVEeH911E7qtDTF2lNzQAh7mHnzDU4sIZ6FhK
wTNJOV3n/eCiyOp6amNmWC9mk+5RO0qjtNsdG+0aiPcmeKPzNNeIPiH1oQFVBWc=
=rYix
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Sanitizing and publishing our web server logs

[Sebastian Hahn]

On Sep 2, 2011, at 2:46 PM, Karsten Loesing wrote:

 Hi Andrew,
 
 On 9/2/11 2:18 AM, Andrew Lewman wrote:
 On Thursday, August 25, 2011 04:08:00 Karsten Loesing wrote:
 we have been discussing sanitizing and publishing our web server logs
 for quite a while now.  The idea is to remove all potentially sensitive
 parts from the logs, publish them in monthly tarballs on the metrics
 website, and analyze them for top visited pages, top downloaded
 packages, etc.  See the tickets #1641 and #2489 for details.
 
 My concern is that we have the data at all.  We shouldn't have any
 sensitive information logged on the webservers. Therefore sanitizing the
 logs should not be necessary.
 
 My concern is that we remove details from the logs and learn in a few
 months that we wanted to analyze them.  I'd like to sanitize the
 existing logs first, make them available for people to analyze, and only
 change the Apache configuration once we're really sure we found the
 level of detail that we want.  There's no rush in changing the Apache
 configuration now, right?

So, if we decide in a few months that we need more detail, we can
change the logging then. Sure, we won't have history, but that just
means that the graphs we make start in 2012 instead of 2007.

 Finally, we'll have to find a way to encode the country code in the logs
 and still keep Apache's Combined Log Format.  And do we still care about
 the HTTP vs. HTTPS bit?  Because if we use the IP column for the country
 code, we'll have to encode the HTTP/HTTPS thing somewhere else.

IP addresses have plenty of bits for a country code and http/https
encoding, we could for example use the first bytes for country code.

 So, it should be possible to implement GeoIP lookups in the future.  I'd
 like to consider that a separate task from sanitizing the existing web
 logs, though.

It's separate, but without the on-the-fly geoip lookups we won't have
any, because the sanitizing process doesn't get them magically.

All the best
Sebastian
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal 178: Require majority of authorities to vote for consensus parameters

[Sebastian Hahn]

On Mar 2, 2011, at 8:06 AM, Nick Mathewson wrote:

 On Tue, Feb 22, 2011 at 1:34 AM, Sebastian Hahn hahn@web.de wrote:
 
 Design:
 
 When the consensus is generated, the directory authorities ensure that
 a param is only included in the list of params if at least half of the
 total number of authorities votes for that param. The value chosen is
 the low-median of all the votes. We don't mandate that the authorities
 have to vote on exactly the same value for it to be included because
 some consensus parameters could be the result of active measurements
 that individual authorities make.
 
 This is possibly bikeshed, but I would suggest that instead of
 requiring half of  existing authorities to vote on a particular
 parameter, we require 3 or more to vote on it. (As a degenerate case,
 fall back to at least half if there are fewer than 6 authorities in
 the clique.)

Hrm. I'm not too happy with this, unless we also include a way for a
majority of authorities to prevent voting on that parameter altogether.
Doing the design as presented above would then be simpler.

 I think we don't want the number to be _less_ than 3, since 3 is the
 smallest number of parties who can come up with a low-median that
 isn't just the diktat of a single member (1 party), or as low as
 either member wants it to be (2 parties).

Yes, anything less than 3 is bad imo.

Sebastian
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev