Re: [tor-dev] blacklisting relays with end-to-end correlation capabilities?
> I do not think that this is worthwhile. It establishes a precedent where > setting your contact info is something that gets you banned, potentially > incorrectly because it's unauthenticated, whereas we're unable to identify > people who actually maliciously run several relays without such indicators. "actually maliciously" somehow implies that openly run groups (all relays have the same contact info) are certainly not malicious because they do not try to hide? (set contact info) While I even assume that this is true for most such operators, it does not have to be the operator itself as soon as his admin machine gets compromised. Since openly run groups are not blacklisted there is no reason for someone with malicious intents to to even try to hide. > 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). also see: https://lists.torproject.org/pipermail/tor-dev/2016-December/011715.html signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] blacklisting relays with end-to-end correlation capabilities?
Dear tor directory authorities, TLDR: Would you blacklist relays with end-to-end correlation capabilities? I'm asking to find out whether it makes sense to put any effort into finding such operators [2]. If most dir auths would not blacklist such relays than it does not make sense to look for them I guess. So please let us know whats your opinion on that - thank you. More information below and there [1]: The process could look something like this: - someone identifies such a relay groups (basically based on contactinfo [2]) - contact the operators asking to fix this (ideally this would be a @torproject.org sender) - give them 15 days to fix it - if not fixed: blacklist respective guard relays - give them the possibility to get removed from the blacklist once fixed teor [1]: > And, of course, it's worth noting that the ContactInfo might be > incorrect, so we would have to do this on a case-by-case basis, and > convince the directory authority operators it's a sensible thing to > do. [1] https://lists.torproject.org/pipermail/tor-dev/2016-December/011715.html [2] examples: https://raw.githubusercontent.com/ornetstats/stats/master/o/potentially_dangerous_relaygroups.txt signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] please update your MyFamily
Dear snaptorg tor operator, teor wrote [1]: > TL;DR: we're talking about blacklisting your non-exit relays, > because they don't have MyFamily set correctly. > > If you'd like help configuring MyFamily correctly, please let us know. If you are wondering which relay is misconfigured, the last column (MyFamilyCount) should say at least 7 (or 8 if you plan to recycle your Creanova relay key). https://atlas.torproject.org/#details/9BFBF1EA78A3FC1A790F7A7789F074338E7F81E3 +-+--+--+---+---+ | first_seen | nickname | exit | guard | MyFamilyCount | +-+--+--+---+---+ | 2016-12-03 23:00:00 | SnapTorCAN |0 | 0 |5. | | 2016-11-28 14:00:00 | SnapExitUS |1 | 1 |7. | | 2016-11-28 11:00:00 | SnapExitBULG |1 | 0 |7. | | 2016-11-27 00:00:00 | SnapTorBANG |0 | 0 |8. | | 2016-11-26 23:00:00 | SnapTorSNPR |0 | 0 |8. | | 2016-11-26 23:00:00 | SnapTorSTRAS |0 | 0 |8. | | 2016-11-12 00:00:00 | SnapTorFr|0 | 0 |8. | +-+--+--+---+---+ [1] https://lists.torproject.org/pipermail/tor-dev/2016-December/011715.html signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] protecting users from known relay groups with end-to-end correlation capabilities
>> Examples (generated daily): >> https://raw.githubusercontent.com/ornetstats/stats/master/o/potentially_dangerous_relaygroups.txt >> (see CC) > > This is a useful check, but it is insufficient. > Can you please produce a similar list for middles and exits by the same > operator? done https://raw.githubusercontent.com/ornetstats/stats/master/o/potentially_dangerous_relaygroups.txt >> 1) try to contact the operators and give them time to fix it >> I've done that multiple times but haven't been successful [1] > > Have you tried emailing them individually? > I've typically got better results that way. Yes I did. Just one example: https://lists.torproject.org/pipermail/tor-relays/2016-November/010950.html >> 2) build tools to easily/automatically manage MyFamily >> done[2], but it is unlikely to be used > > Maybe one solution is to build a generic tool that works with more than > just ansible? other example by coldhakca https://github.com/coldhakca/sync_family signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] onionoo.tpo stuck at 2016-10-30 23:00:00
Hi Karsten, could you look into onionoo.tpo, looks like it is stuck again. thanks, nusenu > https://onionoo.torproject.org/details?limit=4 "relays_published":"2016-10-30 23:00:00", signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] onionoo: poor reverse DNS results
> some time ago I reported onionoo's poor reverse DNS results > https://trac.torproject.org/projects/tor/ticket/18342 > and it didn't change since then. > > As of 2016-07-02 08:00 (tpo instance) > 3144 out of 8473 (~37%) still have no reverse DNS result (=IP address). > > Do you have an idea whether this will improve sometime before 2016-09-01? > Ok, this timed out. Will there be any improvement in the future? (just so I know whether it makes sense to start post-processing onionoo data to improve rDNS data) signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] GeoLite ASN Database (still) broken
Hello Jason, thanks for reporting back. > I'm writing on behalf of MaxMind. We believe we have addressed the issues > you noted in the latest update of our GeoLite ASN database: > http://dev.maxmind.com/geoip/legacy/geolite/#Downloads. > > Thank you for bringing the issues to our attention. I just downloaded the current version of GeoIPASNum2.zip (SHA1: c72a275c66cededf47157e3cea4625342b85bf94) to have a short look at it and I'm not sure the problem is fixed completely. While the number of unnamed AS entries significantly improved (unnamed count is down to 1462 from >57k, still not back to ~500 (Feb 2016), but just comparing absolute numbers without considering total entries in each CSV might be a bit flawed metric anyway), incorrect AS names apparently remain: I searched for the two examples I gave in my last email: AS8708 and AS12741 they are still incorrectly named "73-75 Dr. Staicovici" and "Warszawa 02-822" in your DB, which means the problem still persists. actual names: http://bgp.he.net/AS8708 http://bgp.he.net/AS12741 thank you for looking into this again, nusenu signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] onionoo: poor reverse DNS results
Hi Karsten, some time ago I reported onionoo's poor reverse DNS results https://trac.torproject.org/projects/tor/ticket/18342 and it didn't change since then. As of 2016-07-02 08:00 (tpo instance) 3144 out of 8473 (~37%) still have no reverse DNS result (=IP address). Do you have an idea whether this will improve sometime before 2016-09-01? thanks, nusenu btw: Thanks for working around the maxmind AS problem with reverting to the May version. signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] RelayAwards - incentives
> - We started this > website because we believe that competition can make more operators > improve their relay by following best practice. This would make the > whole Tor-network better if we have straight guidelines. > https://www.relayawards.com/ If it is about competing operators then you should aggregate an operator's tor instances not care to much about single tor instances of a given operator? You might just team-up with http://tor-roster.org/ Creating incentives for a high uptime would create incentives to run relays insecurely (never upgrade, never reboot, run vulnerable software longer). I wouldn't give away awards for low uptimes either - just leave it out of the equation? With over 94% CW [1] being routed by Linux relays, why is it good to run more Linux relays? I'd say create incentives for non-Linux relays. [1] https://github.com/ornetstats/stats/blob/master/o/os_share.txt How about anti-incentives? -5 for relays @ OVH added after a certain point in time? signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Onionoo AS Name
> I've noticed a lot of ASNs are no longer showing their whois descr field in > the Onionoo output. > > Is this expected? you can find more about it in trac: https://trac.torproject.org/projects/tor/ticket/19420 https://trac.torproject.org/projects/tor/ticket/19437 signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] onionoo.tc stuck at 2016-05-26 00:00
Hi Thomas, I'm using your onionoo instance to fetch details documents. Currently it is stuck at 2016-05-26 00:00, you might want to look into it? (even though its date does not change since a few days its file contents do) https://onionoo.thecthulhu.com/details?limit=0 signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Sibyls: introducing AS-level sign-up rate limits, per relay caps, family-level caps
Hi, there is a strict limit on the number of relays that one can run on a single IP address to make Sybil attacks harder, but there are no limits on sign-up rates. Such sign-up rate limits would prevent many of the known and simple Sibyls of the past months and probably reduce the manual actions required by dir auth ops to mitigate them (but I've little inside on that part). In the past 8 months the proposed AS sign-up rate limit thresholds (see below) triggered on ~27 events [some-examples]. I consider all of them to be true-positives, but 15 (vs total: >750) likely unrelated relays signed up on the same ASes during these events. AS-level sign-up rate limit thresholds --- max new relays per 24 hours per AS per OS family: 9 (default); value for OVH/ONLINE/Digital Ocean ASes: 14 I deduced to these threshold values by watching the past 8 months of OrNetRadar emails while keeping false-positives at a minimum (at the price of more false-negatives). How does a well behaving operator (aka Brian) add more than 9 relays per AS per day? All relays in an effective family should be treated as "1 new relay". (In my opinion a reason to keep the family [0] functionality and implement prop242). denial of service risk To prevent trivial dos attacks where an attacker with a single IP generates several new relay fingerprints until the entire AS is blocked from adding new relays for a few hours these relays should come from distinct IP addresses. Pros: + automatically enforced + less manual action required by dir auth ops (maybe some dir auths can commend on that.) + address more (and smaller) Sibyls (I assume that many small Sibyls are currently ignored due to risk/effort trade-offs) Cons: - maxmind AS-IP mapping db becomes crucial and needs to be in sync across dir auths - false-positives - non-dir auths will not notice if an AS run into this limit unless they publish some kind of transparency reports - dir auths must keep more state (not sure if they know all existing FPs of the past already) Feasibility Initially the idea was to provide immediate feedback to the relay that tries to publish its descriptor to the dir auth via the HTTP response (an important point), but since descriptors are not uploaded to a single central dir auth that does not work I guess. So before thinking on how one would actually achieve that or something similar I wanted to gather the general opinion about something like this. single relay caps -- 25 consensus weight (to prevent [1]) family-level caps -- max cw fraction: 2.5% [2] max. exit probability: 10% [3] guard probability: 5% [4] AS-level caps: --- max cw fraction/guard/exit probability: 15% [5] AS12876 (ONLINE SAS) and AS16276 (OVH) are already past that value, so if you do not want to change the game for them you would have to set it to ~20%. [0] https://trac.torproject.org/projects/tor/ticket/6676 [1] https://lists.torproject.org/pipermail/tor-talk/2015-December/039696.html https://trac.torproject.org/projects/tor/ticket/17810#comment:8 [2] https://raw.githubusercontent.com/ornetstats/stats/master/o/main_operators_by_cw.txt [3] https://raw.githubusercontent.com/ornetstats/stats/master/o/main_exit_operators.txt [4] https://raw.githubusercontent.com/ornetstats/stats/master/o/main_guard_operators.txt [5] https://compass.torproject.org [some-examples] http://article.gmane.org/gmane.network.onion-routing.ornetradar/1135 http://article.gmane.org/gmane.network.onion-routing.ornetradar/1132 http://article.gmane.org/gmane.network.onion-routing.ornetradar/1100 http://article.gmane.org/gmane.network.onion-routing.ornetradar/1030 http://article.gmane.org/gmane.network.onion-routing.ornetradar/939 http://article.gmane.org/gmane.network.onion-routing.ornetradar/943 http://article.gmane.org/gmane.network.onion-routing.ornetradar/898 http://article.gmane.org/gmane.network.onion-routing.ornetradar/856 http://article.gmane.org/gmane.network.onion-routing.ornetradar/813 signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] tor-roaster.org creates incentives for *non*-proper MyFamily configurations
(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/E6E18151300F90C235D3809F90B31330737CEB43 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 signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Questions regarding the future of families
> 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? So you want to have a proper MyFamily configuration across a very high number of relays without reloading them all every time you add a new relay? Why are you worried about these reloads? The only way I can think of is to preemptively create relay keys. Lets say you are about to deploy 100 relays within the next week. First you would create 100 relay keys and collect all fingerprints to form the MyFamily string. Then you could use that static string and no reload is required as long as you do not run more than 100 relays. Depending on how much "idle/spare" fingerprints are in your MyFamily string this might also costs the network an unnecessary overhead. So adding fingerprints to MyFamily on demand is probably nicer than creating huge descriptors with spare fingerprints just because you do not want to reload your tor instances. @"minimizing the need for managed configurations" If you run "large scale infrastructure" you usually want to have "managed configurations". No one wants to manage many servers manually. Also: Please consider AS and geo diversity when adding a significant amount of tor bw and maybe set yourself an upper boundary as to how big you want to grow. signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] tor-wiki-changes is dead. Alternatives?
> Damian Johnson: >> > https://lists.torproject.org/pipermail/tor-wiki-changes/2015-December/017387.html > thanks for that url. Oh, looks like the list is pushing emails again. signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] tor-wiki-changes is dead. Alternatives?
Damian Johnson: > https://lists.torproject.org/pipermail/tor-wiki-changes/2015-December/017387.html thanks for that url. Maybe it would make sense to mention that this list is discontinued on the subscription page https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-wiki-changes Are there any other options to subscribe to individual pages? thanks. signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Is tor-wiki-changes ML dead?
Hi, tor-wiki-changes doesn't seem to send out any emails? https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-wiki-changes https://trac.torproject.org/projects/tor/ticket/18262 signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] SyslogIdentityTag considered to be backported to 0.2.7?
Hi, I like weasel's [1] SyslogIdentityTag feature that is available in debian 0.2.7 packages only. The ticket [1] suggests that it will be included in tor 0.2.8.x (milestone). Would you consider to backport it to 0.2.7 as well so other platforms can make use of it before we see tor 0.2.8 (without having to ask every package maintainer to maybe ship packages with the patch applied)? thanks! [1] https://trac.torproject.org/projects/tor/ticket/17194 https://gitweb.torproject.org/debian/tor.git/tree/debian/patches/20-upstream-syslog-identity?h=debian-0.2.7 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Tor metrics: Questionable relays-by-platform accounting
>>> Is it possible that the "Tor metrics" count everything but "Linux" >>> and "Windows" as FreeBSD? >> >> Good question. Not exactly: it's counting everything containing "BSD" >> as "FreeBSD". Ugh. I agree that this is misleading. How about we >> change the graph legend to "BSD"? +1 > Without further explanation that seems still a bit misleading because > "DragonFly" and "Bitrig" are BSDs, too. In fact, "DragonFly" is short > for "DragonFly BSD" so even a graph legend like "platforms that contain 'BSD'" > would be misleading for someone who does not know the actual platform strings. How about adding Bitrig and DragonFly as well, see: https://trac.torproject.org/projects/tor/ticket/14862#comment:4 signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Better relay uptime visualisation
> Also, here are the steps to reproduce: > > wget > https://collector.torproject.org/archive/relay-descriptors/consensuses/consensuses-2015-11.tar.xz > tar xvJf consensuses-2015-11.tar.xz > go get git.torproject.org/user/phw/sybilhunter.git > sybilhunter -data consensuses-2015-11/ -uptime How much of an effort would it be to support onionoo files as input data? (onionoo data would be able to display more data like AS, CC, first-seen) I could provide some archived onionoo data. signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Better relay uptime visualisation
Philipp Winter: > Red pixels are used to highlight suspiciously similar clusters. Last year [1] there were a few huge groups, 3 of them are not flagged (black lines, not red) even though they look like a perfectly matching group? [1] https://nymity.ch/sybilhunting/uptime-visualisation/slide_2014-12.html signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] tor ignores --SigningKeyLifetime when keys exist
(thread split from [1]) s7r wrote: > - - when you run tor --orport [...] just to generate the keys in a > non-interactive way, include a PublishServerDescriptor 0 in the > command as well, send the log to /dev/null and terminate the process > immediately. The descriptor will have to be published by the Tor > process actually running the relay. If the master id private key is > not encrypted, --keygen should be able to renew the medium term > signing key in a non-interactive way. But it's not a big deal if you > decide to do it with tor --orport [...] if it's easier for you this way. Turns out my workaround to generate keys without a passphrase non-interactively is not working entirely in every case since tor apparently ignores --SigningKeyLifetime (when used without --keygen) when keys exist: Signing keys are not (re)generated according to the (new) SigningKeyLifetime parameter (signing key/cert remains unchanged). reproducer: mkdir tdata tor --PublishServerDescriptor 0 --orport 1234 --datadirectory tdata --list-fingerprint --quiet (new signing key with default expiry created) attempt to change (reduce) expiry: tor --PublishServerDescriptor 0 --orport 1234 --datadirectory tdata --SigningKeyLifetime "1 week" --list-fingerprint --quiet expected result: key lifetime is reduced to 7 days actual result: key lifetime is not changed (remains at 1 month) (invoking tor with --keygen causes the expected lifetime but can not be run non-interactively if keys do not exist) So I reopened [2]. [1] https://lists.torproject.org/pipermail/tor-dev/2015-November/009959.html [2] https://trac.torproject.org/projects/tor/ticket/17127 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] tor ignores --SigningKeyLifetime when keys exist
> I think [2] is the wrong link? There's nothing about this in there. thanks for pointing that out, correct URL: https://trac.torproject.org/projects/tor/ticket/17603 > I think this is expected and correct behavior. > > If medium term signing key exists, and is sufficiently valid in the > future for Tor, it won't try to automatically renew them. > It will use the new SigningKeyLifetime value for the NEW keys, once > the ones it already has are _about_ to expire and Tor _wants_ to > generate new medium term signing key. The important info for me here is: How is "about to expire" defined? x days before expiry or 80% of its lifetime is over? Can it be configured? > If you already have medium term signing key valid 30 days in the > future you can't replace it using the automated key generator in Tor > (no manual --keygen). > > I think it should stay like this. If you want to change the lifetime > of the medium term signing key with --orport, do a rm -rf > ed25519_signing_* before that command. > > P.S. also if they master id key is not encrypted you can use --keygen > in a non-interactive way afaik. yes that is correct. So for the workaround of the workaround I will simply invoke tor twice. First time without --keygen for key generation, then with --keygen for signing key renewal. thanks for the quick reply. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] tor ignores --SigningKeyLifetime when keys exist
s7r: > On 11/28/2015 2:26 PM, nusenu wrote: >> > The important info for me here is: How is "about to expire" >> > defined? x days before expiry or > I think 24 hours before expiry. After trying this in practice I can confirm that tor renewed the signing key after it entered a timewindow not bigger than 24 hours before key expiry (not before). signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] documentation for new offline master key functionality (--keygen is undocumented)
> I have actually tried this in practice to see what happens. > > If you replace the ed25519 medium term singing key and certificate in > $datadirectory/keys, Tor will re-read keys from disk even if you don't > send a SIGHUP when it outputs: > > [notice] It looks like I should try to generate and sign a new > medium-term signing key, because the one I have is going to expire > soon. To do that, I'm going to have to try to load the permanent > master identity key. If that logentry is generated on a system with 'OfflineMasterKey 1' I would find it a bit misleading since it will never be able to load the permanent master key. > This message is repeated once every 30 seconds or so. When you send a > SIGHUP, the reload happens instantly. > > So, if an user correctly generates and provides the new medium term > signing key and certificate and forgets to SIGHUP (reload), when the > old key expires Tor won't exit. This is good. Thanks for this info, so we don't have to do anything else than just replace the key files (no explicit SIGHUP needed) - and tor will read it when necessary. That is great since it makes key renewal idempotent out of the box. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] does renewing ed25519 signing key hurt if done to often?
the 'problem' solved itself (tor does not need HUP when it's keyfile changed) ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] tor weather warning tor ops about expiring signing keys?
Hi, I'm wondering if a service like a future tor weather could have an additional check to warn relay ops about key expiry: (something like "Email me when the router's signing key is about to expire") Do relays disclose the fact that they are run via OfflineMasterKey 1? Do dir auths/tor clients see when a currently used signing key is about to expire? thanks ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] OfflineMasterKey / ansible-relayor
> Some suggestions: > > - don't copy the ed25519_master_id_public_key file. If it is missing, > Tor will just compute it from the certificate and save it to disk. > But, if by accident an user copies the medium term signing keys > related to another relay, Tor will detect they don't match the > ed25519_master_id_public_key file and exit. I'm copying ed25519_master_id_public_key to the relay to get rid of the following [warn] level log entries: [warn] No key found in .../keys/ed25519_master_id_secret_key or .../keys/ed25519_master_id_public_key. [warn] Master public key was absent; inferring from public key in signing certificate and saving to disk. The goal was to reduce the noise at the warn log level. > - when you run tor --orport [...] just to generate the keys in a > non-interactive way, include a PublishServerDescriptor 0 in the > command as well added >, send the log to /dev/null done [1] > and terminate the process > immediately. I'm using --list-fingerprint for that. The descriptor will have to be published by the Tor > process actually running the relay. If the master id private key is > not encrypted, --keygen should be able to renew the medium term > signing key in a non-interactive way. But it's not a big deal if you > decide to do it with tor --orport [...] if it's easier for you this way. I can switch to --keygen if it generates RSA keys (as long as they are a requirement for a relay) as well and --no-pass is implemented, but I'm also fine with the current way to generate keys. > - make it as hard as you can for users to accidentally mix keys > belonging to different relays. This will be a tough one. I'm aiming to add a check that aborts if a key is found more than once in ~/.tor/offlinemasterkeys. thanks, nusenu [1] https://github.com/nusenu/ansible-relayor/commit/43d52e995abf6b3a311984bd54a4e9c5e4a5410f signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] displaying an ed25519 signing key's expiry date
>> How can a tor relay op display a given signing key's expiry date? >> > > I don't think there is an option for this. filed a ticket for it: https://trac.torproject.org/projects/tor/ticket/17639 Is there a custom openssl command to display the expiry date until this gets implemented in tor? thanks! signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] documentation for new offline master key functionality (--keygen is undocumented)
Is the offline master key limited to ed25519 keys and useless > while using ed25519 + RSA keys at the same time? (because the > RSA key is not offline?) >>> Hmmm. Probably yes. Until transition (until we remove permanently >>> RSA identities) only the ed25519 key will be protected, RSA key >>> will have to be online. Even in this case, directory authorities >>> remember relays by their ed25519 + RSA pair of identities. If >>> just one of them changes, that relay will be rejected. >> Ok, so I guess the only reason to use offline master keys now is to >> not have to start from scratch once RSA keys are deprecated for >> real. > > A compromised relay's RSA key can't be used to run another relay > without the corresponding offline ed25519 key. (I am assuming that a > RSA key with a missing ed25519 key is treated the same as a RSA key > with a different ed25519 key: the authorities reject the relay with > the missing ed25519 key from the consensus.) > > This is a good reason to use offline ed25519 master keys, which > doesn't relay on RSA keys being deprecated/removed. According to tor's changelog, key pinning is not enforced currently (changelog of 0.2.7.3-rc): https://gitweb.torproject.org/tor.git/tree/ChangeLog?h=release-0.2.7#n89 signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] documentation for new offline master key functionality (--keygen is undocumented)
>>> Does a tor operator has to SIGHUP a running tor instance after >>> copying the new signing keys to the appropriate folder or will tor >>> attempt to reload that file as soon as this signing key expires? >> Yes. > > Yes, HUP? reference: https://gitweb.torproject.org/tor.git/tree/ReleaseNotes?h=release-0.2.7#n86 signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] displaying an ed25519 signing key's expiry date
How can a tor relay op display a given signing key's expiry date?
>
>>> I don't think there is an option for this.
>>
>> filed a ticket for it:
>> https://trac.torproject.org/projects/tor/ticket/17639
>>
>>
>> Is there a custom openssl command to display the expiry date until
>> this gets implemented in tor?
>
> No. The on disk Ed25519 key format is custom to Tor, and the code
> doesn't use OpenSSL for any of the Ed25519 operations anyway.
>
> Someone that wants to work on this should find the relevant data
> formats documented in prop 220.
The spec [1] does not mention the first 32 bytes (== ed25519v1-cert:
type4 ==) but after them it is fine.
if anyone else needs a quick'n dirty solution:
python
import time
f = open('ed25519_signing_cert','rb')
x = f.read()
time.ctime(int(x[35:38].encode('hex'),16)*3600)
'Sat Dec 19 02:00:00 2015'
[1]
https://gitweb.torproject.org/torspec.git/tree/proposals/220-ecc-id-keys.txt#n72
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] OfflineMasterKey / ansible-relayor
>> I copy/expose the following files to the relay: >> > >> > [ 'ed25519_master_id_public_key', 'ed25519_signing_cert', >> > 'ed25519_signing_secret_key', 'secret_id_key', 'secret_onion_key', >> > 'secret_onion_key_ntor'] >> > >> > > When first setting up (new relay) or restoring the relay, yes. But > when only renewing the ed25519 medium term signing key (if > ansible-relayor will support this) you only need to copy/expose the > following files to the relay: > > ed25519_signing_cert, ed25519_signing_secret_key > > If you also move secret_onion_key and secret_onion_key_ntor, it could > mess Tor's internal automated key rotation, and the descriptors > available to clients might become invalid, making it impossible for > clients to extend circuits through this relay. That's why Tor keeps a > .old version of these keys when rotating, so clients with older > descriptors won't experience circuit failures when using this relay. > > To detect this, either the user will let ansible-relayor know if he is > setting up a new relay / restoring a relay or just renewing the > ed25519 keys for a running relay, either read Tor's > $datadirectory/keys folder and if secret_id_key exists, assume the latter. thanks for the feedback! Are secret_onion_* files required at all when restoring a relay? (it doesn't look like it) If you confirm that I would simply remove them from the list and never copy them over. remaining with these files: ed25519_master_id_public_key ed25519_signing_cert ed25519_signing_secret_key secret_id_key (tor's manual page FILES section is not very verbose in that regard - unfortunately) signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] OfflineMasterKey / ansible-relayor
> background: > I might want to integrate offline master key functionality into > ansible-relayor [1]. I added (preliminary) OfflineMasterKey support to ansible-relayor [1] - in fact it will become the only option eventually as it make many things actually simpler, would be great if someone could take a look and let me know whether it looks reasonable. The security critical parts are probably - key generation [2] - copying of key material to the relay [3] I copy/expose the following files to the relay: [ 'ed25519_master_id_public_key', 'ed25519_signing_cert', 'ed25519_signing_secret_key', 'secret_id_key', 'secret_onion_key', 'secret_onion_key_ntor'] [1] https://github.com/nusenu/ansible-relayor/commit/2c4040df7848f382ced02b43f35ca8a9f07ab284 [2] https://github.com/nusenu/ansible-relayor/blob/2c4040df7848f382ced02b43f35ca8a9f07ab284/tasks/configure.yml#L18 [3] https://github.com/nusenu/ansible-relayor/blob/2c4040df7848f382ced02b43f35ca8a9f07ab284/tasks/configure.yml#L84 signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] possible to run --keygen non-interactively?
s7r: > The "Enter passphrase" request when manually calling --keygen is > optional, not mandatory. If you just leave it blank and proceed it > will just create an unencrypted master identity key. I know, but that requires someone to press enter (or a dirty expect script) if you want to run that non-interactively. Something like --nopass would be appreciated (if not there yet?). https://trac.torproject.org/projects/tor/ticket/17603 thanks! ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] possible to run --keygen non-interactively?
>> The "Enter passphrase" request when manually calling --keygen is >> optional, not mandatory. If you just leave it blank and proceed it >> will just create an unencrypted master identity key. > > I know, but that requires someone to press enter (or a dirty expect > script) if you want to run that non-interactively. > > Something like --nopass would be appreciated (if not there yet?). > > https://trac.torproject.org/projects/tor/ticket/17603 Maybe not using --keygen in the first place is the workaround here ;) (So I get master keys without passphrase and non-interactively) ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] possible to run --keygen non-interactively?
> Maybe: > > echo "" | whatyouwanttodo --keygen > > or > > whatyouwanttodo --keygen < EOF Yes I tried that already, but no it does not work. That would require the program (tor) to read from sdtin - which it doesn't. solution: generate master keys non-interactively: tor --datadir data --orport 1234 --list-fingerprint ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] . tor-roster's geo diversity badge, recommended version check broken, exit badge for guard family?
Hi, roster's recommended tor version check seems broken, example: http://tor-roster.org/family_detail/963ADC0137505151C1AFA6757DD2367EDEEC7B62 Runs Recommended Tor Version For All Relays: false but all relays run 0.2.4.27 - which is currently a 'recommended version' as per https://consensus-health.torproject.org/#recommendedversions Why does that family has a exit bw badge if it doesn't provide any exit relays? Displaying guard probability would be nice. >> Do you consider in-family diversity so important - even though all of >> them are run by a single entity anyway? >> How about having a badge for tor network wide diversity? >> I'd consider the tor network's overall diversity far more important than >> in-family diversity because clients won't use more than one relay of a >> given family anyway. > > Entire-network diversity is obviously more important than within-operator > diversity---no doubt > about that. We are doing within-operator diversity simply because the it's > easier to > measure/understand. I agree that measuring a family's relay diversity with > respect to the > entire Tor network is would be supplementary, maybe even strictly better. I > am already logging > relevant data, namely the number of relays per country and total CW per > country (as you > suggested previously). The former stastic could be used for badges like > "First relay in country > X." > >> More than 4/5 of the family's CW is located in countries with a cw lower >> than 2%* (currently means non-top 7 country) and ASes lower than 1.5%* >> (currently means non-top 8 AS)? >> >> That implies some degree of in-family diversity since a big family would >> have to spread across multiple countries/ASes > > Although there have been some interesting discussions about which ASes to > prioritize in putting > new relays, an actual concrete numerical measure is thus far an unsolved > problem. Virgil and I > have talked about using a new tool (http://labs.apnic.net/vizas/) to observe > which ASes have > more interconnections and award bonus points to new relays on them. When > these measures become > better established definitely in favor of making badges for them How about keeping it simple? "All relays run in countries with a CW fraction < 5%" ? you could simply use compass output. > (perhaps even replacing the > within-operator diversity badges?). Yes, please. signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] documentation for new offline master key functionality (--keygen is undocumented)
>> Is the offline master key limited to ed25519 keys and useless >> > while using ed25519 + RSA keys at the same time? (because the RSA >> > key is not offline?) >> > > Hmmm. Probably yes. Until transition (until we remove permanently RSA > identities) only the ed25519 key will be protected, RSA key will have > to be online. Even in this case, directory authorities remember relays > by their ed25519 + RSA pair of identities. If just one of them > changes, that relay will be rejected. Ok, so I guess the only reason to use offline master keys now is to not have to start from scratch once RSA keys are deprecated for real. thanks for your answers! signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] possible to run --keygen non-interactively?
Hi, is there a way to use tor --keygen non-interactively? background: I might want to integrate offline master key functionality into ansible-relayor [1]. The basic idea is to generate the master keys on the ansible client and push only the required signing keys to the relays (master keys never touch the relay). Since every step should be automated, master keys will not be passphrase protected. I consider unprotected (no passphrase) offline master keys still a lot better than online master keys, but currently I don't know how to generate master keys without passphrase in an non-interactive way (--keygen asks for the passphrase when generating a new key). If that is not possible (out of the box) yet, would you consider a feature request, lets call it '--nopass' that can be used with --keygen to generate new keys without passphrase? (a more general approach would probably be to have --passphrase but doing so would potentially write your passphrase to your shell history file). thanks! [1] https://github.com/nusenu/ansible-relayor signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] documentation for new offline master key functionality (--keygen is undocumented)
Hi, since tor 0.2.7.5 is apparently not very far [1] from being released I was wondering whether there is any documentation about the new offline master key functionality? (or is this undocumented because it is not considered for general use yet?) tor v0.2.7.4-rc's manual has the following: " SigningKeyLifetime N days|weeks|months For how long should each Ed25519 signing key be valid? Tor uses a permanent master identity key that can be kept offline, and periodically generates new "signing" keys that it uses online. This option configures their lifetime. (Default: 30 days) OfflineMasterKey 0|1 If non-zero, the Tor relay will never generate or load its master secret key. Instead, you’ll have to use "tor --keygen" to manage the master secret key. (Default: 0) " but doesn't say anything about --keygen itself [2]. The 0.2.7.x mentions also a '--newpass' option that I wasn't able to find in the manpage: " - Add a new OfflineMasterKey option to tell Tor never to try loading or generating a secret Ed25519 identity key. You can use this in combination with tor --keygen to manage offline and/or encrypted Ed25519 keys. Implements ticket 16944. - Add a --newpass option to allow changing or removing the passphrase of an encrypted key with tor --keygen. Implements part of ticket 16769. - On receiving a HUP signal, check to see whether the Ed25519 signing key has changed, and reload it if so. Closes ticket 16790. " Can a tor operator use one offline master key for several relays (that are running at the same time) or is one master key required for every relay? (I assume the latter) How does the process of renewing the signing keys look like? According to the logs I assume simple run tor --keygen again and copy ed25519_signing_cert + ed25519_signing_secret_key to the relay's /keys folder the logs say: "It looks like I need to generate and sign a new medium-term signing key, because you asked me to make one with --keygen. To do that, I need to load the permanent master identity key." Does a tor operator has to SIGHUP a running tor instance after copying the new signing keys to the appropriate folder or will tor attempt to reload that file as soon as this signing key expires? How can a tor relay op display a given signing key's expiry date? Does using the offline master key functionality imply that the relay will only have an ed25519 and no RSA key? Is the offline master key limited to ed25519 keys and useless while using ed25519 + RSA keys at the same time? (because the RSA key is not offline?) thanks! [1] https://lists.torproject.org/pipermail/tor-consensus-health/2015-November/006427.html [2] https://trac.torproject.org/projects/tor/ticket/17583 signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] documentation for new offline master key functionality (--keygen is undocumented)
>> since tor 0.2.7.5 is apparently not very far [1] from being released I >> was wondering whether there is any documentation about the new offline >> master key functionality? > > Hi! There's a draft faq at > https://trac.torproject.org/projects/tor/ticket/17021 > > and a ticket to improve the documentation at > https://trac.torproject.org/projects/tor/ticket/16645#comment:7 > > I hope that somebody can pick up writing this all up and/or reviewing > what's there now to make sure that it's working and right? Hi, thanks for the pointers. Looks like s7r takes care of the "guide", but for starters I would already be happy if the basic tor cli switches would be in the man page. signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Two new Onionoo versions 2.4 and 2.5 add new "effective_family" and "measured" fields
Hi, was there a specific reason for reverting the tpo instance back to version 2.3? (since 2015-09-27 07:00) thanks! signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] multiple relay identities on a single IP:port, bug or feature?
Hi, in the last two days someone started generating a steady amount of new relay fingerprints on a single IP:port (2 per hour, actually a lot more than that but only to make it into the consensus) [1]. I'm surprised that actually both of them end up in the consensus. example: https://collector.torproject.org/recent/relay-descriptors/consensuses/2015-09-15-22-00-00-consensus search for "67.173.119.40 51256" - you will find it twice. Does that make sense or is this a bug? btw: Why do dir auths include non-running relays in their votes (flag line is "s" only), instead of not voting for them at all? thanks! [1] http://article.gmane.org/gmane.network.onion-routing.ornetradar/113 signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] tor-roster's geo diversity badge and self-ref relays
Hi, tor-roster has a badge for in-family geo diversity: "Geo Diversity in Relays (Number of countries / Number of relays >= 0.5)" Do you consider in-family diversity so important - even though all of them are run by a single entity anyway? I'd consider the tor network's overall diversity far more important than in-family diversity because clients won't use more than one relay of a given family anyway. How about having a badge for tor network wide diversity? Something like: More than 4/5 of the family's CW is located in countries with a cw lower than 2%* (currently means non-top 7 country) and ASes lower than 1.5%* (currently means non-top 8 AS)? That implies some degree of in-family diversity since a big family would have to spread across multiple countries/ASes. potential problem: "growing" ASes/countries might cross the threshold in that case you would either have to accept the fact that someone else can take away that badge by adding relays to your AS/CC ;) or consider the diversity at relay signup time (less fun) *) these are arbitrary thresholds "No Self-Referencing Relays" I'm not sure what exactly you mean by that but I assume it is a MyFamily config where a relay includes his own fingerprint. Why does that hurt? The unnecessary descriptor space/bw? thanks signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] CollecTor data of the current month older than 72 hours
> This is fixed now. thanks! signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] CollecTor data of the current month older than 72 hours
Hi, data in the /recent folder goes back 72 hours, /archive is updated "every few days" [1]. The latest file in the archive folder [2] is currently from 2015-09-07: votes-2015-08.tar.xz07-Sep-2015 04:11 159M but does not contain any data from September 2015. is there currently any data for the time period between 2015-09-01 - 2015-09-07 9:00 on Collector or should I wait a few days? thanks! [1] https://collector.torproject.org/ [2] https://collector.torproject.org/archive/relay-descriptors/votes/ signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Should cloud-hosted relays be rejected?
>> I don't think banning GCE, AWS and MS Azure is an efficient method >> to >>> significantly increase the cost of attacks because it is trivial >>> for an attacker to quickly spin up "a large number of disposable >>> machines" at other ISPs as well. > It has other benefits. Those big providers see a huge amount of exit > traffic and can potentially do correlation against that. I disagree on 'huge'. If you worry about i.e. Amazon hosting to much exit bandwidth you have to worry about many other* ASes first, and even then, banning them all completely (exit prob = 0) isn't probably a wise strategy. *) +---+-+ | exit_prob | AS_name | +---+-+ | 9.261 | OVH SAS | | 7.629 | Avira B.V. | | 6.239 | SOFTplus Entwicklungen GmbH | | 5.306 | Hetzner Online AG | | 4.013 | UK2 - Ltd | | 3.563 | LeaseWeb B.V. | | 3.316 | Voxility S.R.L. | | 3.171 | Init7 (Switzerland) Ltd.| | 2.454 | NFOrce Entertainment BV | | 2.232 | CYBERDYNE | | 2.174 | Association TETANEUTRAL.NET | | 2.111 | ALISTAR SECURITY SRL| | 2.018 | 31173 Services AB | | 1.852 | PlusServer AG | | 1.831 | root SA | | 1.713 | ONLINE S.A.S. | | 1.703 | QuadraNet, Inc | | 1.475 | ISPpro Internet KG | | 1.441 | Foreningen for digitala fri- oc | | 1.427 | BlazingFast LLC | | 1.377 | rrbone UG (haftungsbeschraenkt) | | 1.288 | IP-EEND BV | | 1.249 | WEDOS Internet, a.s.| | 1.240 | Abovenet Communications, Inc| | 1.181 | The Calyx Institute | | 1.169 | myLoc managed IT AG | | 1.024 | Digicube sas| | 0.871 | Amazon.com, Inc.| << Amazon | 0.817 | Hurricane Electric, Inc.| | 0.799 | University of Michigan | +---+-+ onionoo data from 2015-09-01 07:00:00 signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] New Onionoo version 2.6 adds new "alleged_family" and "indirect_family" fields
> The current "family" field will stay available until Atlas and Globe > are updated. If I should also wait for other clients to be updated, > please let me know. Please do not forget about compass before removing the 'family' field, thanks. signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] New Onionoo version 2.6 adds new "alleged_family" and "indirect_family" fields
> The current "family" field will stay available until Atlas and Globe > are updated. If I should also wait for other clients to be updated, > please let me know. If someone is actually going to adjust atlas/globe/compass it would be great if that someone could also take this enhancement request [1] into account - which might go hand in hand with the required change. [1] https://trac.torproject.org/projects/tor/ticket/15417 signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Should cloud-hosted relays be rejected?
> We sometimes see attacks from relays that are hosted on cloud platforms. > I have been wondering if the benefit of having cloud-hosted relays > outweighs the abuse we see from them. I don't think banning GCE, AWS and MS Azure is an efficient method to significantly increase the cost of attacks because it is trivial for an attacker to quickly spin up "a large number of disposable machines" at other ISPs as well. Detecting new groups of relays in a single AS that all sign up in a short timeframe is trivial (DocTor does and did that already [1][2], OrNetRadar [3] does it as well). Should you decide to continue generally blacklisting entire ISPs/ASes/IP ranges: Please add that info (including the banned ISPs/ASes/IP ranges) to the documentation (i.e. relay setup guides [4]) so volunteers don't waste their time and money to setup blacklisted relays [5]. [1] https://lists.torproject.org/pipermail/tor-consensus-health/2015-July/005955.html [2] https://lists.torproject.org/pipermail/tor-consensus-health/2015-July/005974.html [3] https://lists.riseup.net/www/info/ornetradar http://news.gmane.org/gmane.network.onion-routing.ornetradar [4] https://www.torproject.org/getinvolved/relays.html.en [5] https://lists.torproject.org/pipermail/tor-relays/2015-August/007655.html signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] bwauths: Are you publishing your output somewhere?
Hi, since a request to make bwauth output available has been closed as wontfix previously [1] I'm not going to ask whether this data would be added to CollecTor, but maybe bwauth ops are publishing it 'inofficially' (like Tom does [2]) for the dir auth to fetch already and would be willing to disclose the URI to the files? thanks! (one can also use the votes [3] to find out what the dir auth submitted but the raw bwauth files would include the timestamps/frequency) [1] https://trac.torproject.org/projects/tor/ticket/2532 [2] https://bwauth.ritter.vg/bwauth/ [3] https://collector.torproject.org/recent/relay-descriptors/votes/ signature.asc Description: OpenPGP digital signature ___ 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'
Changing the code to return the mean of the two center elements from even arrays would break all authority voting, and wouldn't actually be useful. Yes, that is what Sebastian said on IRC as well. Can you shed some light as to why it would break voting? thanks signature.asc Description: OpenPGP digital signature ___ 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'
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.
signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] tor's definition of 'median'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2028 If 3 or more authorities provide a Measured= keyword for a router, the authorities produce a consensus containing a w Bandwidth= keyword equal to the median of the Measured= votes. a random sample from recent votes: grep 37.59.38.117 -A 3 *|grep Measured w Bandwidth=6869 Measured=7570 w Bandwidth=6869 Measured=15500 w Bandwidth=6869 Measured=18100 w Bandwidth=6869 Measured=30500 Tor says the median value is 15500 2015-08-10-16-00-00-consensus: w Bandwidth=15500 but the median of these 4 values is actually: (18100+15500)/2 = 16800 no? Has tor a different definition of 'median' and simply takes always the second ordered measurement vote out of 4 votes or is there a bug in the spec or implementation? -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVyNtYAAoJEFv7XvVCELh0YU8P/0hWhCLfafvFDPdAfUwUJFPA A1ZA946JGKg1Vjy+ch3tffjDHRosXt7K5U33N9rKMUlW9ul2BQ+uNgzK4eTbghHz yCMn6D+uLk1xruYTsIUZ+Pk/ZywaUKj/FngohVvQnaJIgJCHCEnCIqqBNEK0PjUh EBzI5GdyWpEA2fh55PSRuSNCVzbiVhGwYSKgrVwFrFcKr9iPLmdZsa9SD1mb1PD1 IZOkU6TnSnFGbPaN+pHYdNr5/QJA1/08yYBpG7qAJaTCAMvMif7bKMJ7ElYo7opc oXcECIcBBPnATgKvbO47dbSnX3s+vPMsrRhhdTa1BMr1MIzVG3RWGhNSJwXXQTJh jyaPGj10JRWNxDsY0ro001MX0HymmXeLLCkY4nWsUqPXDiZcQe4oRzLQas5bOI94 ct4tCavj9pRNp2XYCWe631gqcsQ3xV7y37dWUCvpdXqt2NC1B7j2w/Y/UiuNArSj QBtS4Ap5wqnU5JySjndi+lIPOlaPk9uitmzpKLxNF9fnpI6ZECP3T50vHVeZiiQ9 7o1ZyBsPLk3bi2hRy8ZJ0wyO+5WF8bdrlsKXSR40UjrwQZ5kCQf6xmWiSg9PqZFU rIL14yCOsQkR3P4/IgMlL8dtgFk3Asmkkx039144fRKveEhffFjo54CUMhg/jLra EF5cUqz4QdgcpRvKa/5h =lA/6 -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] collector problems since 2015-08-07 18:00?
Hi, I was wondering why onionoo reported empty platform strings for a growing number of relays. I wanted to confirm that by looking at collector data, but then I noticed that there is a problem with collector data itself. Files in [1] usually have a size of around 1 MB, currently they are at 1KB (basically empty). @thomas: Is that the cause for your onionoo instance issue? [1] https://collector.torproject.org/recent/relay-descriptors/server-descriptors/ signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] collector problems since 2015-08-07 18:00?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 In the event of collector missing data, there are (at least) two backup instances. One is at bwauth.ritter.vg - no website, just files. Does that have the same issue? https://bwauth.ritter.vg/rsync/relay-descriptors/server-descriptors-cat/ looks fine. -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVxg8pAAoJEFv7XvVCELh0ccUP/2VPE/P96qP7ujbNcoM8/bYJ /b8G5NpKQggpMsAjXVUq9P2M4rYhYkzLn3wvyn8paXBkX/HX5d3574lsFQ7W/C0x 9V8IVc+uqqP3EeVIOg5kPrHblG+UuQ8ldYwwDKmY/RgrD5772m3LAa9WY/hrpfiC FQavIUWeIn1UPyKtCpfBWDwbzQ0zT/BC4Ak74AGJA6GN9q9NXQFbtcQtoBTXdaGc RPmzas4meEkGez7tj418Ku8UFxckPAA7yWCmzzwSPckfCzv54IxXso4tKVUEZxi+ lvjEJ0WVbKsPp0eO3ljKnieRgeB3zHRqRQZShesY5c5l6alZCcow4K9V9CeHsivn LaeoN1H/vXKCL8WROEK1hSEv8YbE3uOZ2u+G6O8tBPr8uSQpecLQFO/74dj32gD5 d727W9M8hKcguRaUg2QzxNe7cdy2dfWIlxKGomlEr7GK4FYJljMGxnaOe4vHoCxR ZMZgiSbnaGVAmlPBfVoOAMvemN5+YXUgWPbucFp0b7bjGlk1aVO1/PoU3OwdGw9h go+7OqFuYJvwu+KrhaPkM/DBceX9IbNpw44D9ox0cB/D+UddJXVknzxXuPw5TwZ1 U9ilD/SYD1QY2EgRz0LVL2qnwZzPUDffz0ZgLFzRRK1EVjrrCiDa1uItY2x3EA52 YqLmUMVFQhQ3VbjOnQfW =NQM+ -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] onionoo.tpo stuck at 2015-07-29 07:00
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Karsten, just in case this is not known yet, onionoo.tpo does no longer update and is stuck at: relays_published:2015-07-29 07:00:00 -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVuU9pAAoJEFv7XvVCELh0DKEP/3NdXl9sSZUk+Q6CPlyHvu7e /5VmgR/qdqLPY8DVmKqXbXv0A/pUVGk32vXC3AV2dAL0pRlx2zqi/KeQsAozIzAd SH28YaQnibOFjdDouTrgmRxtpErIWv/WImu7kGm6ojQeXsOw64QcmGIUPjPMbv7c qmdziCCFBLkwsrPBqCIKmH03x6IKz/Rxvv0Moxl+5wpWdu0uQvjjI/PbcHCtSjqM /D6M6+cIqEzZYWPia7Bk0+y6/nydP5vQsBiEgQYXerDkfwwAQdQLVouMPTFEG4i7 oq/eSk3WzRty08Ur3qJxBQ2qWw8gCieYsVWBrS8H5AfTTR8+vT/tgE1MELE+CTS3 oiiRruFxuVRiJM+BeTZ+b72QJn/MGbL3wcCH7oKZ5k/cJSh9juhSK171OQ50z7B+ pDBDjrteaRktDlPqRUkesOY/1SQwXeBEVObxICGIXcrQMeXt+slm4NSefKsIUbDX 4s2ivApLMbPq5AgHylXJDunSmjXTyjkqsOlD+n9UkCgy9lcijHHrE93zncAHGs2m 6RaPJtebhat2h0utjgm5PlD0EWcxrTEhI2cTStqQeAIGIdRuOYCsDfFBlj/khGUk GMrQG6jvbn/WFRj/1rXRkh6T55dTHYE/NZDpQU81U8g2O0qipKrQ9UotuqklwVuF W++VCTDn5XHSST2YhIiC =oY5H -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] Relay Web Dashboard - Summer of Privacy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, [4] https://leivaburto.github.io/sop-proposal is this strictly a one dashboard for one tor daemon or will this also be usable to monitor multiple tor instances without running multiple dashboard instances in parallel? (while leaving the 'how to securely connect to a remote controlport' task to the operator) August 15 - October 5 Implementation of further statistics that were not included in nyx but are going to be included in Relay Web Dashboard. Would that include data that is not available via the controlport, like exit/guard probability, (measured bw), cw and cw fraction (available via onionoo) or is that not something that you are planing to include? thanks -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVt+C5AAoJEFv7XvVCELh02UYP/RlSQiflvrwWTCR0JkEms6LS ggD23t72guHzz1X7KDaDrV0Q/XkL1c0THEjohVpKOESKV0HscTXe6aMhXmJoBKrx 0DvKyeujZvOs+X52jUIJNawfs61f3NrnzXpsdA94GrmSzogEpaoGNspVK+F2m44y Le30SfU+o2VGRd0QIxH40TgnM31xelnISpfSsRdowswAS5+VQmMMicvjQtGyHo+q 1PdhK8s4ZvcQ/vkN4AVj718iG0xeBkozRQ7G6qMzG0DmPEHatV0fN0pnn9E/TBBX /23IBfQ2qP2O/dwELrOvOHd5050FE/f3N6fF5BiOOcy5U5TFudI62bR6zxvGcFPz EweKc702IS36RD2WUESLUWBvOz89PbUbPotopKe204o0ULV4q0XimSQpztGvmw66 9vxW1pBQXoW5YDR+ieETvk1zzd5slFEdlrDOMhL2rADJPQaChlDfVL5wC44Lurpu WUDyebcfIT7pfxaAb63AU0m6KQwnNUPcsmiIFQXQuyVTawrseUVfV8GMnMY78951 WsgauOWqBrb4XNRbdlzNY9ivU1fY5cUPa8+HZ7TLbl1vnAY5ptajBinHiLiuZhst ekUUjQ4gJw8tZD16A9k42xLiei9vQ8nfZ8NahCG2t/A+1YEZyzHPPpr7sYzWHc9I K5pKQO6m2Tq1lJK6rCGQ =yV3W -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] Roster introduction
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 The main difference between Roster and Globe/Atlas is that Roster provides information at the level of *operators*, not individual relays. Agreed, this was just a placeholder. Will put contact info instead for now. Thanks, alot better now. In the future I would like families to have ids/nicknames as well. How about renaming the contact column 'operator'? (the name 'contact' comes from the descriptor field but operator might be more fitting in this context) I find the family page a bit to big, do you consider a shorter table like compass' family overview? With an option to expand individual relays on click as it is right now. Do you plan to add information about number of countries, ASes netblocks netblocks and an indicator for exit/guard to the overview? -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVmv1sAAoJEFv7XvVCELh0nrsP/1qnayToOvsTlXzH82D6rYoX QEdafbDUYiUThKWDEAeQrJqvRGHXjbINJ5QLFvN9wmhvG1eBccmm1stoq5oDbfJO AC4lBb6OHCCJGQAGNQ11+Mt1Mzn4O0qZG2nEvhIb+zRnATEjSNXzzw0cmkJM4R0X hc9xi03kJ2y3iAuL2N85bB1qmfAXr4sh9b7Xgjos2zbCrD9Z/OAoEmixFRVzrEaD E2kuTiPWWKtHsREhVKu0iDPHIxf6fMAzAVvHJzFSVtvX8/28+SH5L4BVEdt3zh3D QRPiRwi7Qv2kukVwSwB4EjMS+kQJZOoNpxL4mQOGP624ezYM/aaQQy98eqSpm0Tf JiyEr1ZGpx+I0SO+qZuMouBHS742jjbjNVmK/rmDbA9DXEVjMSCiblzeEDBFDDSB 11ic0dIvhYUz/Sdv/6jwo3OGR6xoPbA7zdQmSx1eu7EsOuYnGI5F9SYCy7RiPOHI Qpx26z1/lCszqIp+9v6Eetw4LjJS8+CR2tr0Vi6Aslj965610yY8KDTkoEYeFJ// UddVQCZK4lXyirYhwpLjGF+k8HRT7WS9Zw++yYUl0iwzko4bnugbw3EpOpXmpp1C ctTSlX4qQCko6NPFGtjKAzyHvne8i88FNXlBwbl3XGEFQJkmdGIB+Kbo5emTZiAq b2j5vSBbBGyP9wyOyr4l =sfL9 -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] Roster introduction
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Main things accomplished so far: * Setup the basic website at: http://www.tor-roster.org/ Thanks for doing this! A few comments: - - the page seems to be AS name centric - first column of the table is AS name - only clickable column in the table is AS name - - the AS column suggests that all relays in a family run in one AS only - - the family page of a specific family shows the AS name as title, this is a bit confusing as one might think that the page shows all families/relays in the selected AS after clicking an as name on the start page Family identifier - - by looking at your page I assume your family identifier is the fingerprint of the oldest relay in the family, does that mean that an operator has to start over at 0 with collecting points once he kills his oldest relay? -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVl5wiAAoJEFv7XvVCELh0c1kP/1C5YbWsv8pEoHuTiISs8UzI ah7ZtlBO27YNLlPj2xdDDjkEb46kf8l+AatWnk6u1z5XjiGGnc3T3kLRRfVphj4B S2b55QwuUldXJtI59aOcfNOkHdOIBWKCGLBZKkI7lgsIcsE1YAEjSgKMBQ/Q4FTb yzXnEla5bZa0daAcPkPkPwm43DQSygVrnuKqdxOglQFkvFLTB03qiEW9pa0yAhts 2qEVQyXo14sfehu2c0NoyWREnttbgrjIVZqHAM7yVRqYl5AxTZwMA8s0IohGdFTE ZRakg8uOzjhgJuXmL67VnowrVBiDLirezbTZxHLpqSBzQwyClBCbY4qgt0gmYeZ8 LMNRDYLE4r7bK9kweLhg+iJbsD0JQJUOS6H5l0LraDAVfHKtiH+dgRqwtGI0xSLh zjY+aAXUc1fpULgO1BwXHuTGh0uhXFRN8A++Xmki7DtIKm6LP40NjfiCg9nTgXkf Gv1bCzUxh1feCoJXWR4dt9oMUwcnpxPO2S16MQ4mwC0VGPedhg2D10/Ltfe8BzkZ hFodw8MQyWjTT2Xz78BI4sXGfbldYIgng0bkfvWXJzNhJ4M35sTEPUvQyLbj7szg n6cZZ/aOzMlg33sgSaS2UG0UzCa5XUtqSdmkeNuc7rrGr4/+GvV93ZXofLJnvaYZ kFz7aLxyS8kr3LR9aM7O =v2Lf -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] How bad is not having 'enable-ec_nistp_64_gcc_128' really? (OpenBSD)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, since enable-ec_nistp_64_gcc_128 is disabled by default on OpenBSD due to compiler bugs [1] I wanted to ask how bad is it (in relay context) to ignore the usual tor log entry: We were built to run on a 64-bit CPU, with OpenSSL 1.0.1 or later, but with a version of OpenSSL that apparently lacks accelerated support for the NIST P-224 and P-256 groups. Building openssl with such support (using the enable-ec_nistp_64_gcc_128 option when configuring it) would make ECDH much faster. Tor's changelog highly recommends it [2]. Can this be translated to something like the relay's bandwidth usage and usefulness will be reduced latency will be higher security will be degraded due to fallback to DH-1024 ? thanks, nusenu [1] http://article.gmane.org/gmane.os.openbsd.misc/218944 [2] https://gitweb.torproject.org/tor.git/plain/ReleaseNotes?id=tor-0.2.5.10 -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJViDmDAAoJEFv7XvVCELh0Fi0QAKF0/7eVWgL5gExyGcCugz66 9CJOaNGVdeqb8LDxH/KEW4xC+MLhqMQ/+dL7iVOZIOtCM6i4vTpD3u4ZVnFhcGfx luyX78TqXDW3riV3izBWYScYxQdeHGv3XFXQlbGi7WQYfRt0AdorchmP2xuxD7Cg zGZFk4Bggj3qnW1sd/G3JvJL0bUi7iBKrQwPTDlnK3YSGbTYpU6lS3dQqbHqNYin yrwtlNSCi9DFjbQm5g4yjvaawnmOuxf8dlm54Ltjdn2cIHsXaPqQ6kXICiukrJhE ZLfTnPBd3yngyoq9xe7bW9P4mNVkTNmAU3VqGgEq1gSUJQObXkzOKAz63z9WAqQl GBvZFtwkbdBM4pjfWaG5FjDRc+awXxP/8K/d2vF2r6KAwkbh9Fw2uhjC6yu5c6hB KtQaovd+we+Ag4vDdE6lbQPLiCbPBiFdB6qYjkWbVflYcrsYQPoCgwjaodbV7I/Y 8Kb3Lx2C8+HFLtktEh19tOk34iKVliQk7FjE2FoiKkWryRYtY5KUAfFS8hOCfBqr 2XYtWGqQ9eh14RqvBu7CuN1cKCc0EQLcr6BF9uvd6EYtKZsa5rQC+y9Bbbd65MwB qU7lLckEkG+qwzgvuyOBvGwN8JmMmTBQASsdalAUscQFbPq7wySp9tz21pu8mOje NRRdnL1/3X9KcCMLMCVk =Oa2Z -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] additional triggers for DocTor?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Damian, does DocTor's design allow for triggers that alert if a certain amount of relays signed up within one day or within a week (instead of within one hour)? Another trigger could be the last_restarted timestamp. If that makes sense I would file feature requests on trac and provide some possible thresholds. Example of an event that would trigger then (2015-04-01): https://lists.torproject.org/pipermail/tor-talk/2015-April/037384.html -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVcdCSAAoJEFv7XvVCELh0l5IP/R0NeXImuchqastZcg4T4PK7 Qy5VmFrWBdG9AOnypxIMgzVF5/M+hKjRgbbAp9/VrRXqpbFCgnChnQvqyJcW1nB0 AYGfqEUfavTBthbtTfq6g43BLBZke0olBMVFlKHaAYTidXMabrY0OlZ3QjdHt1Sx DovQ/zGVX263VR1YZimXom1xokCDm7J51vPURjx9BLrBQ2zdEGvOWWwdT+w1CiaK iH4I0AGUPZfLxxLU7rCorFAIV2AyKTT97EN9lQlD3TtPmoDiZdhPthR2MRKVruEP 3Kt76VDMRPro6oKo2d3sk5UFuyh0Hg+yqJhTJhjdZ0w/ZQtbIjlkHbnfSqgthEPL fi2XKQrX1BSfbQpsig70FRFHgKEQVzplXLlca9o1sn52GrwdY8fzNLc0p8xZiFSc xoognuyER4IgLP10c2QsYSoCx50yfpYOxDZIEFVIelDDKGIqVQzR/rGRwBfXBcn/ 598SPhka+h0BK/NudG/k5qRlsdWpQdygeAfDBUUO6AxHaIH2P96Pe1CfxNkoMGX4 TWZ2+pTXye6wdiFhdhDYGPuCtmOgI5GQ5alHEvsk3s7/n0YitRRNHNiNe3SGw7UN hX6HQuWmxD5J/D1fcj5gC/gJZxkeluTRO6iOP1AoNAqP9XGgQeT7uwhL+FzT65V5 GlMIH20AeBn2FWIesaxf =Ia4Q -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] onionoo: bug in family set detection?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 https://trac.torproject.org/projects/tor/ticket/16276 -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVbiccAAoJEFv7XvVCELh0/rUP/i7Q/cZwYaklkvHAaqmsDffK x8J77/21/5ppN1kyPd8jI7M8ktOC+1uqhV4mlf5CyidKR+2kAhhPYjfX57xQ1sbv OJwDq33EbQiTk/ed3DLQdQpbrt7fqaAzZi3+q2NIKMx2/GFRs6Sxnp7D9b69TEt3 WgW2sEuAuexl//HU01dKxPXp6+5EiW6UBz0eUJcTz4WUf/+CltRBg4sbBXImls3w J5mLqMNwyrRT/StTZB5oSMHsOfxQGgGGJppT0l91onQLzpM1A38ZtgN2zs5tD6T9 OSl7hwhUJHaWR3mg9vDywXO0CQ8tTadfZLGtDU0q5H88vU00jTRW1XA7bKLxtLqY INu9APIjnOhaatVTRGhJMMvP/Vuk6OE/L9n2FBw5FAPxmJ3Tn0+NwElamYizq7o8 AMNpWcfjHxAiH7R9PEuhwYyNktlBz3Swm4uNFvSGPaJsm99lxJLmd7ko9qrxd5Cm WcmQvPpfXN9Ym5iTWlMpu17MLmBGb2YgshFv+fTViCY1JwaEqAlTP+5/m2XmnM2x 8CZgNHjL1C7QWffx6AQYqcoAP183ClR3MD9poan7LMYfaqxXIbLceCzMOKeu9Ptt KPAdPAvACngB9kz43oQeJanE/nmjW90j/hr5oPezL57ayJEvpRiT+cmkkRTT2RvB Aj2Q3IqrXhOzTJkR+N94 =pTF3 -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] onionoo: bug in family set detection?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 teor: MyFamily requires bidirectional declarations to be effective. I'm aware of that fact ;) In this case: OnionOO appears to correctly implement the bidirectional MyFamily logic Apparently it doesn't. Since onionoo says there is a bidirectional connection (family) between 5510FC1736B16D46D3F2DDA5011995C478D42594 = 0C77421C890D16B6D201283A2244F43DF5BC89DD but there is none.. (as explained in my last email) Compass does *not* say that there is a bidirectional connection between those relays.. onionoo says there is one even though I can't see it, do you see it? -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVbd8wAAoJEFv7XvVCELh0clQP/AoZmVBLltEWueM0OYH52IS0 1ZLGjhhnCd/PhEUOrgr0Y4Q4/My7IzCNVSMwca9FPBiFKLIg4ejQf+vTTVkCJFD8 aw+gJImqKTD2x7WP5V36kjIDJjnWpDsybcx/kjEGA8j3yeIx67MdySc3daRl5c9e sk5rl1HlhR2LFyFzNNc+pq08plJxDU8ciW5vaMLDUotumkenkF8DBaYonqlAE/bk etyBdphZWvCVW9WrwkMoeYZZEgDt0WlS1iKjUb6kuHGYIlmx6/4tCBHglW85hDB3 AsKxKRohoxZEwG6QGiTAC+zbYeMT3Gzgs549Tja4WDkYieZrrfNCCaOj2SRa1aaQ DCz4u9LQFRtr4oHqLA0JlHedEHziRogOt25CdQCch7Bu33P5Gsj9wpYEICmpWNPS hyLPTQTZMWb21PUuJ33VUWSZ//fLF5zJkkJiO+rp+OBt205n6+8PjY9vRAXu00QU 5qsIwwjklpnt2i4EFKOgSPkFczgRaW7ZyPdu7NRbfrD8VMYeeSWjlAJ2JZc7kKkp q4UWPysTULTbltMOqE8+SRy1m8G2HU1wsSDY95ajhqVjikPSw+ROx2LKPPYr/OzC KrDKxqOzwX032GY0fRSLNLz3grMP+MdZtHC47qb2Ki+1d99Ifw+F7XCHeIXVrWKv XqGLL2yYZjfZyTaPn25w =mDOq -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] onionoo: bug in family set detection?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, by comparing different methodologies of parsing myfamily data I stumbled upon differences between onionoo and compass. After manual review I assume there is a bug in onionoo (or onionoo has a different opinion on what families actually are) Example: According to onionoo, torpidsDEevanzo [1] is part of a family with 38 members. It lists torpidsFRonline [2] as one of its members, that implies that torpidsFRonline lists torpidsDEevanzo as one of its members as well, but torpidsDEevanzo does _not_ list torpidsFRonline (according to onionoo data). grep 'fingerprint:0C77421C890D16B6D201283A2' details.json|grep 5510FC1736B16D46D3F2DDA5011995C478D42594 (no result) Is this a bug? thanks [1] https://atlas.torproject.org/#details/5510FC1736B16D46D3F2DDA5011995C478D42594 [2] https://atlas.torproject.org/#details/0C77421C890D16B6D201283A2244F43DF5BC89DD -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVbLCAAAoJEFv7XvVCELh0bxkP/1Ep/fhLMhHGIgYnVzEj+xyJ Sb4gqUBuwLckcXLAYGoKZkIeHNS4TFLBidKxuP54bvSLgqPgpsy+OzLiaUk8AYyP Ea2tTmDqcjWy2v/cpP43M3Vh+TpPBTMenNajKwe9Moz63pMpo0V9HLnBjCwBN+Mh 1vGFJw/ov4wmQO3J5OOEABdVt8RTmqCWJBVbz1NmKWNEpxa5sbPS+6tNEvBLbsaL XmtoPcdyAl+14QQk1GSq4Px49K4MFEcRuCN2r1bzRv2WaPgRmFUtrK9JCDwwLlV5 aSrBU7S2M5gn6KowkEZllniZ7n5Ze3SiifqJEPm3hyIUXczveR02LHk++lEXneQE pqxDX6PPnVIt7lm1JW5Svr82boYTC1LQ9xHyF9LStBfYvgWSD5TrDeNaIe8+mka3 OrJ6r0hxMB1IRUaxouI/IGMZLmwj2lqifBeaNccsz876oJ2W6SZu6JPVvNstf7lc TnesBplpAprekofUb3DaGeM80Pa/NmuRjga5F+H6HLH3qE8AxeGKzSQDKYLuRlaM GdZY/bMN/6JGhoHCvYIT8NMNGMYfMPE7UWiHtX+1dezIwyYtwnHxiAcRl/e73TuI cmtzvIiKA9Z1sM2FX8mhaRi6r6TOBdvovSTkKtxkXHk2qT1Sf/oPtvlGtzTlrVp7 uFFgl0Sg++eiHAd1VG58 =D6Qh -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] valid MyFamily syntax variations ('$FP=nick' ?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, based on your answer and linked trac entry, I assume my point was not entirely clear. I was specifically wondering about a combination of *both* ($FP=nickname) something I haven't seen till now: Example as provided in the URLs of my last email: $2B76359D3AAA94CA107F447D2D14E481A99EB207=Konata,$827BF0F1E52B82D69B3CE3DFEE1F1FE3A11042FD=KosakaKirino (onionoo excerpt) have a look at this relay's family: https://atlas.torproject.org/#details/2B76359D3AAA94CA107F447D2D14E481 A99EB207 Normally you see, fingerprints only: $FP1, $FP2, ... or Nicknames only: PPTOR0042,PPTOR0043,PPTOR0044, ... or nicknames next to fingerprints: $FP1, oilsrv1, ... -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVa23KAAoJEFv7XvVCELh02vQP/R/d0kNfQM3r30CZj4jXExbT XIuas66C/tqxtF8BPSQ3+xCUSStknbCEuhoMnjDJr4J5G5M5RaFk7XSOl4DbZ56/ GoVVKvG6HYEUHdnkAwk7dUDJQELZ+4UB4s24wPV/mFkzjx/503dA7TWeVWE9O2/E rnUvPPo8rMZ8vh6rksgBId3XvqFl6ShHduToNe83leomwl1V9qZY5F28dUrBkcFp ZIPhPsnonZYXRqlsW6WJlFWwAfTou5do8H7yJSAZd6+0+w0PLZKoF0pzH7vE5Ht8 T9dKQSw/9ZFbL8iJMdf0lVWpkhDGKHkDEOx7X8oRAVBrKdYj7xvnGhcj8XkwLGp3 h0L3pTqH3ApqlohCyuSA3ePYw4Cwy1ZJt0ix0t8PDRmm+j/r2uxELZHyWF7tV8CS LCpKLnWIecEOtA9fnn4eCTLqQQ/PZgSqJ3pJdhK8wFQXSHOD0vr0xjssPDohIfE3 xtBSQocainlCLtaWc4ickrDpZgldIVSuKaSRxGs67Pxd4qxxaQEDPG3F+UrCbUJU Xoy2bD9LXhD56H8mKp35L0wOBK/rl81HHlVztNqUVvNN/kyHvFFb1KRhtQaXKTYg NLefBY9/a+P3cHZ/Yv6PlugyNWQmc5QiqrLn3er11SOWde6Rg3si2jEEAz9MYiAT A8J3fn94VkaYR1f4uIlz =1VTB -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] valid MyFamily syntax variations ('$FP=nick' ?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, according to the spec [1] relay ops can choose between fingerprint (with and without $ prefix) and nicknames when constructing their MyFamily configs. The man page recommends fingerprints. Now I'm faced with [2][3] families that use a combination: $fp=nick Are they actually valid or is this a bug or can one actually specify arbitrary strings there? (dir auths and onionoo apparently accept them) thanks [1] https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n504 [2] https://atlas.torproject.org/#details/2B76359D3AAA94CA107F447D2D14E481A99EB207 (search for KosakaKirino) [3] https://collector.torproject.org/recent/relay-descriptors/server-descriptors/2015-05-30-14-05-48-server-descriptors (this url has a lifetime) -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVa2WkAAoJEFv7XvVCELh0jEwQAJqdeZaFpRWPfI9/17o7aEKI Jx8Lp811GGwr4STO41ixwOIQ69hjNuav47apcmR4AsUVAq8zkSnzljKyYtVnp7qH 4EHx0kqIop92s9de1AFKg2XDnZ3u4eSN6z53VXeO2+/jFl2CgMVarzLYPHNBBF/x ev3zMk8gYsGA7K5TowZ+HnMalXhHLpTvO+iPPzNF6eY3/pG31hImFfHvhkJ5nrzB gex9wmCTXigM6I1mcT8mK8OH/2+MkNFra2h4tcEmqzmzRdWx1UWDTgl97Jp2injL UxuHL1RkoGLqlZ/MDiMiZPa4JurNRKgBXdZNsASOvcX8ZiPiCzqbbCm4hN4Rsidi ROWR8AcadA/9a5Ovi0z8IhxUiF8Ks2Wadeovp4w+E2NuYvFNmUpvkH0jVSViSE8n v+XClj0DX8oHirRqp80M0o5GpOB2hsRzT0+QhRFKYbikW2CRziM1ECWknw3aj3/z VPohoo6bkkLLBfrrXdgqclvgtoG/zPl8Ef203pmyTjPCFEdx4mJTLzq+hmjoaPsI h+RweF+HvDc0qM+6fiYeHExQl7YMNuT6GbG58lK6V8c+r++FIrPwfyOepAddoE0p dTAHfqYMYhDL952z916tmNNPnHXsUu8hVaIVuB9RvYjAU9FpPAz5Q5CDaIu+F4TY kb9dxHK1c8IHOGamYMOD =tbZE -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] exitmap feature requests?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Philipp, do you consider feature requests via [1] or would you recommend forking and implementing it oneself? thanks, nusenu [1] https://github.com/NullHypothesis/exitmap/issues -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVSlpSAAoJEFv7XvVCELh0lCQQALCIDN+o7o5rubDUP7+O2J01 pI1ezUWqRk1BkKXYOPhB17gJke/5XzYCQkA/VW8FLmjf52WnucFg25c7TJ6hbRFd T73jfQvIAoNm938c/ZRHND8xOCOxaO4oa+sd5+oPNDYCfEg3gHfFxHtjgdvUzF+P Y2CqbO271drrFzkWk0ILSoRJihmZjSZHJl21gvfmeDKRsyycig/yKip/Lyq9n8QF O9rneAsVXtT72uCKnjd7rAqVwetTgqiNKQMrOG4hZ61BoGgrwYueWpTVN9wSNNOO 755TnSjZw+/rjYJxIQngbhdFSeFOX2MvE2gaUsut4b1tUa23QSQ5bLhPVEw4P6u2 Hm9lo06RCPNoYe16Hr+ff2rLMK/UU2LfoYkBZk2f0FM7LcYzEOXs6mmeUREBoJw8 V6m+O1orczjwppF9aPBLXihUr8FZQyuhIYMPpwYnMdrtysiFAKvOusOxr7svmM/w nQvPrEy3SuiyyoQa8VGZt0DejeUfyXwhkndbTC/goxKf44pWGDVUB15fyUIKh17l 9vNVdMbCmmRVHa8Mto3RmjlNRG9c3gqsmaMteAJohXGAbe8qoSMqmRF095HYjlhb MD5UPiuNIoAqOBjC2FMTYnLT2bmrRmcQD0i0dUEtK6wg5w11M3pSbk+jR/7AD5uZ gPjSfXUM718ly0avzegm =+LN2 -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] #14995: systemd unit files - review
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi intrigeri, thanks your reply. This is being worked on there: https://bugs.debian.org/761403 (which should be a more appropriate forum to discuss this topic.) I didn't want to report bugs/feature request in debian's bts for a non-debian repo (deb.torproject.org). This resulted in a situation where tor's trac is apparently not accepted by the maintainer and debian's bts is not entirely the correct place(?) either, but with that info I'll just use debian's bts for similar matters in the future - thanks for suggesting this and the pointer to the current ticket. Please report such bugs: * to the Tor project's Trac if they are bugs in contrib/dist/tor.service.in as shipped with tor I did so in the past but since I don't know any packages actually using that service file shipped by tor https://gitweb.torproject.org/tor.git/tree/contrib/dist/tor.service.in I'll probably just report any bugs/RFEs against the package instead of tor itself. I hope this makes sense. (The service file in tor does not say on which distributions it should work and generic service file won't make use of the distribution specific features.) * to the systemd bug tracker if they are bugs in systemd itself https://bugs.freedesktop.org/show_bug.cgi?id=89875#c2 http://lists.freedesktop.org/archives/systemd-devel/2015-April/031377.html If anyone is interested in systemd problems I stumble on in the tor context: https://github.com/nusenu/ansible-relayor/issues?utf8=%E2%9C%93q=is%3Aissue+is%3Aopen+systemd tested with jessie: https://github.com/nusenu/ansible-relayor/blob/master/files/debian_tor%40.service I get a 404 there. The file moved to a new location and has become an ansible template (=dynamically created) instead of a static file to improve security [1]. CapabilityBoundingSet is dynamically build depending on which capabilities are actually required (related to [2]). This is not something you will be able to do in a service file that ships with a package, but you can still copy that service file and simply remove lines 31 and 36-39 of it [4]. Note: The dynamic service file adjustment I'm using is only a temporary workaround until [3] gets addressed - which I don't expect to happen in 2015. [1] https://github.com/nusenu/ansible-relayor/commit/cc7530a820fd2b4fd579598f6a16cc31d79e3045 [2] https://lists.torproject.org/pipermail/tor-dev/2015-April/008638.html [3] https://trac.torproject.org/projects/tor/ticket/15659 [4] https://github.com/nusenu/ansible-relayor/blob/master/templates/debian_tor%40.service -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVRPD0AAoJEFv7XvVCELh0b9QP/RD3KvqZsrHgN8IFQR5IyatB SHsQnwcngkcQgbE27s5TVwOnXLNzPwIY85nH7rqBRjLrgtweTwTVLOzw807GimxH cL81HOMT/nXdV6toyEzXu3P7W73T4GwThMzyw46hqblq3i/YYSIbfnLycpQ6vwgE dwvt4P/O2JWbtYUgzNyWMonKejFvgfyRIPZypgK855pZTaBBZbBSgwnIgdeKtdxB /GF2cFS6dQ2jHoIvI8ucv6SPWy6KKyxdkfpGzAYijp5MafzPChg+LkneUsLThail vss1/c1VqJyGi+GGxvbvc0zPGgI/ywHop3DkLpZMjD6k24XjTjayV6ec5F+Uw8UO rBtqzU06/+X+q7Je8LHIsTM3JRQFZg0Gsh1I/iN+ERrMZjtmiZ5GRB1cwObgVUAt 6BIfoE1gfXvsd6lYi16Fd9655T8F7/yrouUcU4dAVTqdGAftRMCEdyCBJSEE2GQE CjSKQ+h28I/t1RD7Iw9YmoxMVUDA5zG/gsx9CsMwTKA/YqZyqcisdWJld/l4TNuU EMzWXcsKYzeBg2JqW6ihl9JTVwvU0mip6l0J8bXDHWGl4RUBFVxVs/5yWR+PUxM5 JPSN1U31dq0Kjy23Or4fLaGil7KZ2lMbnlinyhvsj1bEP5WAmYqDxo3aJ91yRneu S5C++Lr1Rx7JG3GxLsiq =Aob6 -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] #14995: systemd unit files - review
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 intrigeri: This is being worked on there: https://bugs.debian.org/761403 (which should be a more appropriate forum to discuss this topic.) Also for the ubuntu packages? -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVRPV9AAoJEFv7XvVCELh0rFcP/RRjTZjS40d8PN5kulz+1CvD TncWbRweLMmZp8zD0vuNOsuNII2Denhy7E+2iFwtoue2CvTgM0R0UcdRjb1Ak+b5 NbwT4BdVo6H4hBI1T7lGPaUp4MMjHjDq1al/PZFqYoJqPj2H1HmjWsTq2AvE7of9 4XpebOJa27YZnNnkctzB9Z32TteYpS2rBsBnljIZwHUEwTg+TNo+3bKiSGnz85WH CJSy3FIJBsSTFjMcJzYsYpnr3iT4umRpcbKKvRDwm2HAe3G912nQ4ZO3CiRZI+Wt dAuEAHhzT4byeRAOmxKt4J8MlDIDtYBFFVxIU13/WKc4p//bXf5IBWt0gecyeh60 OToW2Vl9zfltsMO3ajdZvExDRDh9eCGqZ3hO09UaZUPaAI81SeP44FHUmru9T0mm 7d2j8ltR/VaMM/xcUo7xBHpZgJSPtuaQ6z3gQNpbJabCo0TJ5qc0vVgNtn2C8DV1 IONWk6GqCRCL4bRO76zGiPzTEgxyos2TOFfQkya0y67NgiKyxREh2ayi22rEYKtf k4inWQkhdyWWqxxelbQ/4w4uKU6JD7mfzIQ0bPVd2t3FZjC0Q5OT0DoRvI9k294z iMJCNZGyuSGHEnq5BKqFmSd9B0JuWYWd5IGnqIfwbOkzzoqiiZeuIEvE9US8ljBV xYsLahhoucqYVr/gOwCm =+oqX -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] what capabilities does tor need for reloading?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 just for the record: 'systemctl reload tor' fails due to hardening restrictions in tor's systemd service file [1]: CapabilityBoundingSet = CAP_SETUID CAP_SETGID ... The proper 'fix' is: PermissionsStartOnly=yes REF: http://lists.freedesktop.org/archives/systemd-devel/2015-April/030404.html http://www.freedesktop.org/software/systemd/man/systemd.service.html#PermissionsStartOnly= -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVQTOVAAoJEFv7XvVCELh0ceUP/14ip5/+6I022mYHuBgTwmkL 69EYtX4uaKb0hDCZAk+hGA1VgAlCwZD87zhXW6Tb42SLnhZ+XGmSg5NefG6MCO5D mKf39Habzj5eDAbyUYItQu7zYzJfgGO823KC19XTwfUjEfalCv7/D2Ra8eHYJRcX PL5cvNTyVpViKk9qW/f8rvZRar7Y4iqig4N5xe93eIf/dpLjpkfPlQhWg13zuoHW YohHSb5BC6+T3CFoIAycRYMSkkBk4KL6CF7q1MTtT1T/1mZlfbZ+ar6MZEfXI1q2 KL6NbdOWv/IIf5aGCAZ58E8RJGZKvoWiga00d8aMgRMASHd6Er93pzhpdF3y2MY9 E5//We2lb+GjDIXbrMNC2ZHsuKgDOFV773w+DJCq0z0BB2WL/X7XNmVxhq3/8h2F M6Sr0Wjazo4O2eEdE0DTNYrU91xAhfk5OuJWPxGQIU9knaqiiwWlxBCqWFJfuA1/ eiJy8sDumd9BzDtr5ewRswjZaZj4jTRYzH+owxnd8U00cImj17+4H6xjDJji8kXe cMDOMjxnnGX00PTCXLPLIoVCD//oBQUqcOhpsDP/Ga3O7lGFlynjVJbUYrjS0/lz cHxF0qX7XGtr0Bevik9xoq8bPomnoULKIfM0EjrD+0LAf3jwFK5Ne5PY+T1AsrdX Go85L9UdvUYUlZwRRTWX =7YTi -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] #14995: systemd unit files - review
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Weasel, following your comment [1] about your plans to use systemd instead of init.d scripts I prepared unit files [2] - tested with debian jessie. Would be great if you could comment on them. Since it feels a bit as if I would use the wrong communication channel (trac), please let me know if I should move this elsewhere. Now that jessie and vivid is released and debian's systemd has a bug [1] with legacy sysv scripts I wanted to ask what the status of the systemd integration is. Do you have any plans on it? I think systemd support would also improve security when taking advantage of systemd's security features - a few of them are unfortunately buggy and therefore disabled in the files below. tested with jessie: https://github.com/nusenu/ansible-relayor/blob/master/files/debian_tor%40.service tested with vivid: https://github.com/nusenu/ansible-relayor/blob/master/files/ubuntu_tor%40.service thanks, nusenu [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751638 -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVP2vNAAoJEFv7XvVCELh0Zp4QAJKVEK7+/ymalsL1eo5yzEgz 8zxXpyYxL3nWDdSuMBZfkfv6Xn+RxB/GbfhFLs1k6DL5Artpr203MALJt65pWBdp KU1KiqzVnZH3VMSFKqKbtONOUGT4BUExYkfEh2qP4LN+I4fTQdxJuAqdukIvoO6L V4nM4eb7fPNFo3xMhYve6P9/tLUZkY8RCH+vuZzt1b+xRtHW9nh/B+sHDH/qUJVx brSUOZmtVRX53ZAthoG0AU+oqiQCQSD0gf847PWmkK0xjcHcKAcsyodjlsCqfbCJ AiWwaJu+aR1ZF4LlFvDeCeLE0QGty1ZNva6wd7jSm1dub83I8S8t/jcpiX5FQbVn E+R7i3yM55BWrJ2npz926tR3FVtVrMlT9xBC8Tzv8sCDb8pS4YpTBxlUtdeQ7VdJ 2XFBdrWK1xxWXjreTOtqvK0QwDbdsrDQ6xTLlOmAxqCKJG3xtXCaGtZHh8pV7J8/ 8uPHce8VhrTBiYZI0wqo6zNXmgIVAvRagx1ORX9K4YCHomanxwwNf42lAHFdq5+8 iWrFAxv+RR3HWWO5gnVLh9aV179Y/hIzF9hT9812E+QOq1ScwpxZGkH/IJbqnQ0k Dk4ncWfaggRs3ihnbdLxXVJgRm7p/2lPbZxZx7aWsi2tbSGUaivINWkyXvpiIGz+ 60bYtFpEQ25jZugWlPGv =u89B -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] onionoo details document deterministic output
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Karsten Loesing: That timestamp is updated as last step of the hourly update process. The details documents that you're fetching may have been updated before. That would also explain some differences. Wouldn't it make sense to mention/use the timestamp of the consensus that has been used to generate the output instead then? It *is* the timestamp of the consensus that has been used to generate the output. But generating the documents that go into the output is not an atomic step. It's an hourly cronjob that runs for 15--30 minutes and writes documents for all relays to disk, and only after that is done, the relays-published timestamp is updated on disk. As I'm saying on one of the tickets, one way to change this would be to use a database and update all documents in a single transaction, but that's a major change to the current design. Which doesn't mean we shouldn't do it, but it's not trivial, and maybe it's not the most pressing missing feature. Would it be a quick and dirty fix to state the timestamp for every record separately (to become more atomic) or does that not fix anything/is not possible? (I have no onionoo insides) fix in terms of: a record with a given timestamp should not change over time and multiple instances would provide the same record for a given timestamp. -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVO9W9AAoJEFv7XvVCELh0EscP/imDkVPdyuJ+QPcc0vdKcIcv njW2YefPmLgP3NgiSZDCjhj7V2XTf/g99XQqgRupC9i0MoTnc7P8lvbNjXy0b9NL ig8DDoX6JPp4Lx2pPKolQpI2WYPbLCzNazbsmiTGQ7TU8lC/REsvFg3Tf+I+/saq HdL8MyL9rJ55VSlIOmMW7ojx/+mz1j1tBVnOECqNTtOlOY+/5Yx0oYKf4QKDr92c rvj0dw9DPPqcKnbusKp/mosh6whbZDVS5wNv0H90v9J+FpjFIFn//jnhVNzRnj9y t8lKEio+EyhyewaU8DzL4bUkRHCMIhc/1FKfWJJOHctdLm/9/q5BcBM0Imk9x1jM MoGxipqfMgvO4j7cHjBAMtRasMcDjRD9WMNF9xyOknKG/h99v116UJBq/j4MIigs kac/LIY8rEzBz9kNC5Q/R0QaJoBordfYjga7Ky7M4H3SF2FjmL+yJsnnS5zaUwMF UE001JlkiO0slLYJwmuP/30DZm7vd4gqwJrg3Z0WwMYPEROut0gAHr31xJCkDSAQ /gq54YgBM9V57ZJJiP6LYj5/TZFp8/qRlYKm+sBL3WGXnmsuPhfRXkmTbnvGlLnX Pgg9VSJ2YBwpG5xIP4w1U/7rDjlTtsr/D6mK/f4xsuBx8xXJpp0V30HoNibaYSDR f+2pSSo1vAPZjDXTEev+ =ohOR -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] onionoo details document deterministic output
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Karsten Loesing: These might either be bugs, or one instance was missing a descriptor or consensus that the other instance was processing. I assume the instances do not process the same descriptors in every case. That would explain most of the differences. If their 'relays_published' timestamp match, they processed the same consensus, correct? -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVO3AJAAoJEFv7XvVCELh0YvoP/iO/QAVqf3i/e4ZtG6OK9+S1 B2zju2z2YG8QLZvUSui3qlAzO48KHBID5p/aG8sLxMrDP/PloNfeqdIsYEjD3IYG xTLkuq7jQWwmMqn4agjJB96czQr+gTpbF4ZkuFGJ8klG/hUm36ldk14s9OwZGZgs 6HLTB6L8TJevlmFm22mtDE0dwsVn/Sq/emTSkWXCIm+FHVF9583XU9yhdSiZoGcL aRw8zYLDGr/FyQW64IZnr1tJES7d8gJYW+DC6rqBWXslZi9PHB39p8DelHxH4SWX /yDyPg5sQ3R6pBbBKnXv/rAmIyMIcu/cyC39o8THS2ESkFcP1cm85vHzA3uWHaVh FyNY/e7gGxug/KdMF92daUiziyB4r3b5i3ZOTS+T0emLIZ8Sx+kFrNYC625E4Vnb 8LmdvFOms6n4OUd571fg/rjMtJBwDBCMwhcBQJXcOGzYZxhskKUjOIggScbn6osA uobNDvUOp8J5QdpPmJE8QccdtzjxgtI1Zq8xfrx7uyxKbRBwMk8H9ZmfBGRQXFib 9OYRboRvMTh/WDXjF04HfGktmkLjvrgvpTsqnq5h5ESHte7mFczxNECyL6JHUFge +UrEve3lovpW2lz89a5NNuK5ppVkN5SI65Ad60d5kCuPIELMO/NUHTnzxg7+Wk8b ++2CmbyL5xcitJx/xzFK =3ku8 -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] onionoo: increasing first_seen granularity + providing document fingerprints
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, timestamps are useful to link relays, unfortunately onionoo only says in which consensus the relay was first seen (granularity: 1hour) but does not include the timestamp of the first seen descriptor that ended up in the consensus (published line). That timestamp would have a higher granularity (seconds). What do you think about adding such a timestamp? (I acknowledge that I might be the only user of this field) I might want to prove to third parties that I'm indeed processing/providing authentic historic onionoo documents from onionoo.tpo. What do you think of signing them? thanks -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVOpLqAAoJEFv7XvVCELh0WaIP/jqLtHaeno0EEUNPeqT8rJQp XRV76Vfq6LOciexFBRfcN2p7kkG26Y1LunRs12QuRpJngNfSW/nu3/WNUruR205D PrFJCI2Olxn3s8Fktd/N5kNLJbtPDmzqkghhvWUP+f1MBuW0FstMWi4fZ+TyerE9 FTD8eTF8woFb/JEHIrKsH4LB5Os/uGCoJbWT+AlxKHQcU/mQn0rb4ZIIllbUr9LJ uuFUV7ajZAR/rBX2AWvpkJgaS3BfOk3cMOVd3dQgweDjtUlS66Q5v+vtvBHXYk1V jd+fXyQ3txFmFVj/oQgnJJFRmGSmqpm5hRWEkzOXjXlCdsnqMPUBBjwjrgU+vmGB sNQOi/NdXUImQ0bT+ryjPTOT7Gf5EXOihYyH4e4ebn5OEEEVTQh/86iXxrLB23I2 z7sciEw3q/Tt7mM21cSMRStxavBU5InixIvQz78TgK1sE9PpeohzhToxNedm8aDE Ny/O+KYBBBmKOuRwjmbyJQ86MxQHnmEwLhksVNSJ3MUuG0QmfFTrht3thkmlew6z UfFBS9YzfBIoztL7X5Pu4nFsNFy2ffxZIV/bs4Dmx1PlweIw0eUeCgUdcdZTcvA+ v4OjCukdzLupDpb8lhDuX5EqrmeYUnczlopMX3szeX8udLKr5G+MWaihGdKasdKw Fy6T4z11bbzuW/nBf6Ra =oJ6y -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] onionoo details document deterministic output
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, if I ask two onionoo instances running the same version (as given in the header of the document) for the same details document, to what extend should they match if relays_published matches, sorting is been taken care of and lets assume that both instances use the same maxmind files and their DNS servers provide the same answers? One example: Torprojects instance says: flags:[] cthulhu's instance says: flags:[] thanks, nusenu -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVN+saAAoJEFv7XvVCELh0ywEP/RNsdjuOywrJMAuaSlLLwCYs eHK0EUcmq/DDyq2OaAK9wOgAYqtusgBp5+YhiL11dBAvuW2siTZJPiKcoj8UQk84 m6xq9FCImlxLIEe52YP+wz2t8y6p42oAiSqlMLgtBVjW6QvgK3ov0e++iEhbJbvj hKLeSPsVLHz5XWtUdSjQ5fbbpsuItzTphOc9bi/nWGGYzeRzBNdtXilU5afCysi5 GvxV2SdttRrZw0IVzbLs0CjZBBwxhiuR8yemjRTaL7QDBgS2x0TMCxqhDmVXbp70 eqwGf5Rvf9AYgGu6i+3CJk9YAPh4vcLx1XS8hKxwreIXsUpWGGOfZs3VCGVFcZKe T9oQKQgy/EX0DSi5CSU5mbAUB0XT6S6gzh2Q7ZrsYfMWOaZXuawfeyBcvp3l/gSQ vkZ496ilDsc0DK+z0rrGLNbabx3CoQmHBr8kJQS9ZqAzZEMuDETXKwOBD+IVvSYh wo7nCU9o0NrzuwQCLdjGWr7WoInMLnASgySit8sGsbjzGTigwMvbg6LD4VlUQmcj NFaofSw/KcTUDf2+ZFP5TdXOizaPHeYxfyXn+B8ntqktYav86ePpaCUtq50HMEl9 6BTKvVFcCHkpUbgYTTDFW6YMM1qSvwmODiyKQbkWaB3sItdiPZaHy5ejPSEfDRCz FOY1pHCNGjCJWjrmY5o6 =YbXp -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] onionoo details document deterministic output
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 other examples: different views on when last_changed_address_or_port actually happened: A4877053906D36F47F0E610DC56E95601123C02A,last_changed_address_or_port :2015-04-13 14:00:00 vs. A4877053906D36F47F0E610DC56E95601123C02A,last_changed_address_or_port :2015-04-11 12:00:00 diff on that field: 259D44BDF3734077902CD71606BAD95F994A606B2015-04-13 08:00:00 - --- 259D44BDF3734077902CD71606BAD95F994A606B2015-04-11 12:00:00 3737F4542BBA0C43345BCD91C4F1E194418B313F2015-02-14 12:00:00 - --- 3737F4542BBA0C43345BCD91C4F1E194418B313F2015-02-15 12:00:00 9F938AE96C6B63F726BB885E4F2D1319C84A25BB2015-04-12 14:00:00 - --- 9F938AE96C6B63F726BB885E4F2D1319C84A25BB2015-04-11 12:00:00 4E8CE6F5651E7342C1E7E5ED031E82078134FB0D2015-01-28 11:00:00 - --- 4E8CE6F5651E7342C1E7E5ED031E82078134FB0D2015-01-26 03:00:00 73AB1555F0DA2E6D6B2AB2A603A8CB34F2981B3D2014-12-30 20:00:00 - --- 73AB1555F0DA2E6D6B2AB2A603A8CB34F2981B3D2014-12-30 13:00:00 ... -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVN/lqAAoJEFv7XvVCELh0mfoP/1BqbvHK5Wj4+kLiXKWjLsqj Wi+XCAY98iAl1sDKffDSD3Av9BgmpFyb3xDwxTcvBFGCpwxDz9D/OsxE2yFH/FyA Q8Yv2ggP0nfgsB4Ewt8AmIUgMKD86C+L7Sqx9/WL3kRHS2p+ctNBWVtyTpOErJFX ZPYTe+iSTgz+Br4KH1P2+S5pxjc2m+o/QmFW0FsVuSs82Qhcy+jbi5zbfrBc2Zzf KK6TypJGVsAxBvBfo7yURxNgqhVyqZe6TZ0isG8BbZBggrljKJ2mdStVr+FMt25t wxEmy4/sUAPksZGO9vw94kluL1xbobsEsnKvW0EexAgXtCaVxarfTRPvXGs7j+fS aQn5ppRujyDSRW4fJZ/oVrOPhGaLDCfRQRuYhfxo6Q0mqNig1GrMxcR4nzDp/q44 93LzKBdHPn/oBokmm5VFascTNd7+edI+YiIE5DVmkdTwQXLcQS7REf6w/AW7Oq62 wotm4d5MNkH8go0MHrW5JD8nNC03Qr5z+wsBvqc+vKZykbmaouUO11VeXzGQj6/L ckmig2Zo3D1ZIbfpTNXrGe8XeEpyJVvVKe7jOaKPTrF9Lz639y0jlZR3mZkcFvi/ AaBrsLkIu1eU+doFhmUifksNkBI/tti+GMaw6uDi3b8ZwpQtuJSfj1FPzEAoluVO qT9rdoH2qMNM3j0i6H+9 =4yBm -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] onionoo resource requirements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Karsten, Though it's very likely easier to parse those directly (possibly using Stem) rather than setting up an Onionoo instance for the exact time you're interested in. can you say something about what amount of minimal memory and disk space one would probably need for a non-public onionoo instance? thanks, nusenu -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVNq3SAAoJEFv7XvVCELh02xIP/14QAycUAcAhun36WyzhpsC/ gb8Ta0ryCzEBW3zT4//9pyrz3VO08ryLI6Kg/OgrwOSUfVxQtTkhrnYG9GZlr89Z fPW3PgnilPFAikaH4iJzxbvVS8FrZdG3d93QM6uDsMHOfwuZZJg+PXSTfIdAawYc /eS59HfeXDEz/fCQAl+N9YWKJuKQbPqmG3ah9r27ppJRVCp6Upgm1i40s5z2emsC Wg54HBy3n5To04t8mzaW1eJKMlXFXsps6ywxERuVwyfOBPBBL3WViybJLN0IOW59 1k9qJB9UfvaxHVd52+YJw6eNaLBgVOqllz1Dd4tBctNzgUfJKCBKLsmxovQj9Daw GsA+navUOFHHJwXCs9b2yMZa+LcnbYbP3Y2HT0ZwY5al2hy4SsqA7bAyIk7RozEJ 6p8S/Mr7qh7QS0Gw7Dz4AGJ1fVgsR7FBLj2g0XO27SlqhNYC+Mf75eSkF0MQJ6vj YQCJhSZIn4DAs+AG2Ul42aY3/w0LTQfLmjbAfGrvuO1wrupDQ+6D1nvFc9AYVLHR IWhco4XdQiVOLnmDAs8bMY/llFS+3x1Tf7gVKV0rP17w6NTLsgLXq9B2ufkBYwaR nLWOGIQ3AeoBapONFmFe1Klv7/69mu0NiWsQ8Nx1JIc2Ogt+VzRrWC1jyBcbI8hC yXqlQeW9FNizS9b3SZUo =Hn+K -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] onionoo: historic details.json data
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 By the way, are you aware of Philipp Winter's work on a better Sybil attack detector? If you mean http://notebooks.nymity.ch/detecting_sybils.html then yes, I've seen it. -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVLrcMAAoJEFv7XvVCELh0Q5UQAIV4qIEADzwVNexSCs5JRun5 swV1EKq+OZtQ4BWf2kxGN388zcZvgVGsjSuj4sBYcTFlzgJ5Rx4A6kqMZ+XGA0x5 7FJ7x61rQ/lrvz9HxrFGnKjU28YNhxAkaumrK2690/+ecpk3Wdo0J+sx3nZLRurc 5CpyGmnWv2ArJhXfGbZ3cF5wvU9mYV1hAx4aoXLCbDVOk274zkyb/XA1gTUrJX2d 5BEzbsfDBbiQRIhCzoZNUIX7krZEp/Wi05MqdOoDXmuHRJ6LoGPvp3NPQnoEizaN zUDp/pNaNv1zV8ygTbAueCBLafbYPZc6xfwreI/bAjfLeJST38ABGTwtydsW3VPd UGEcuct8F8G2xq30fGDu6xCgLUhhN9tef41fpiDRRchnCoiDCZwts0rgPywlZyEp 2sWmlkOy/Dxq0GPi2owBIg9wwT8FYb4OwOe+6QiLsXkx1Xb9Adf75pPateNJ5XCB MEgVYl97mxyXonptbjVm3ToEEgljcROcz+7hhX/dD0mEinacB3t092nYHcfLFeq2 RHKEr1bpyjhX8dqjnXK4LrErhQHZlhEiQc+3PglPqq5Z9kLGOcNQowogB5KMVdj0 duBCyYtEDhUlVMCfzP5COLFkJuNfSThc1v+YO0rsnBfMjMX7RmPyCdvfODzbLCtM +yttIXDy9dB4GXHUFYdP =qb7i -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Relay Database: Existing Schemas?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, I'm planing to store relay data in a database for analysis. I assume others have done so as well, so before going ahead and designing a db schema I'd like to make sure I didn't miss pre-existing db schemas one could build on. Data to be stored: - - (most) descriptor fields - - everything that onionoo provides in a details record (geoip, asn, rdns, tordnsel, cw, ...) - - historic records I didn't find something matching so far, so I'll go ahead, but if you know of other existing relay db schemas I'd like to hear about it. thanks, nusenu GSoC2013: Searchable Tor descriptor archive (Kostas Jakeliunas) https://www.google-melange.com/gsoc/project/details/google/gsoc2013/wfn/ 5866452879933440 https://lists.torproject.org/pipermail/tor-dev/2013-May/004923.html https://lists.torproject.org/pipermail/tor-dev/2013-September/005357.htm l https://github.com/wfn/torsearch (btw, someone knows the license of this?) This is true: the summary/details documents (just like in Onionoo proper) deal with the *last* known info about relays. ernie https://gitweb.torproject.org/metrics-db.git/plain/doc/manual.pdf (didn't find db/tordir.sql mentioned in the pdf) Instructions for setting up relay descriptor database https://lists.torproject.org/pipermail/tor-dev/2010-March/001783.html Set up descriptor database for other researchers https://trac.torproject.org/projects/tor/ticket/1643 -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVLrmVAAoJEFv7XvVCELh0+ycP/0VkRWMGAhx7YwWhixtOPB0q ouitosse3SdLCMd1W7cps7nnQhcGv8E1xeUPYeizNQ+RIK9ldvnwgxhVt9ETOI3e oL6bcx3B/NSbTcGfZhIU6XCCX7+39CXz3/+/gXg4c1a5Cd9rYKuwTn7ZApPUNAK2 9yfckCwHaqh67ZDHB1A7nrHX1BJAjwhri5JRGomHSUXPwNZOyMzpgPkB+I92esqc Z4ajQo2D+Vyk42qF7apqp5ApVBLdt5ycUtW1j4s4KvyJH2BjeP4tCXvvYLKv9IvN TGHMJ111NQXbuk6H1OdaDmMZhhW6utPk8YAbNc7RZHqCdH7No40zFVlikLDrV2Xl uLt8FMlck7hGQv/4udA59Dw3PGHfrSiCbvJXb0S2jarnWOH2O+zSSuMs8jQM/x7k 6tIOlwtRDVGw3VuvNbb4MJnLzdHRxq3qy6ueDYuhmhHslxjD1Cbr3eE1RA7Da9aX kNDgjfXtdah52HWUZbIIxHQYzyCg5G3M5yy51GhUlA2Fe1sbPpNcEBeyEDK/jH3Y +7G+tgR+CdMvSFraCiYKHa1drVPJHeqNvZAqPNHKxpKwOwOoJEYrsW4wb/mJ7ybe o8xNYK691hcaMvHqwI47tw4hZfrI0f0+gQKKzENQQk8/8yUZ/0jgMRlW/Cz0yYIa FZEg+OJ/yEs8vKfYerIN =Rfn4 -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Are DAC_OVERRIDE CHOWN capabilities required for ControlSocket?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, tor will fail to startup with the current systemd service file [1] if your torrc makes use of the ControlSocket feature. To work around the issue one has to additionally allow the following capabilities: CAP_DAC_OVERRIDE CAP_CHOWN since the socket file is create as root and then changed to the tor user (chown). Is it possible to change this to not require CAP_DAC_OVERRIDE and CAP_CHOWN capabilities anymore? thanks, Nusenu [1] https://gitweb.torproject.org/tor.git/tree/contrib/dist/tor.service.in#n 26 -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVKmkiAAoJEFv7XvVCELh0Qk8QAITqZiFwp+nBIywWgLLQ5m6K CNkRa+HcNk3sCJKFWOzXqLP4Q1mIUrPWT6Mm+LbwLvo8uRnJqBNL5H0F+kDgYfyO wAsnRicwmoNfHa8hb292nj4p4eV/gQf9J94/creDl99jrtlgYBeLWY8toUZy452x QvAny7EC9Gt06/zMyNJxvVhb1SgthLsIfN6LXizH0Xe1y6m1Kh4XW/py5nvuMwmR sZg1QyUxQ8uJIs73J0KnuGZrzloJGN6IZmJ4EZ250gTUty3VtgvOTAu7W6KsGC2F dyHFqbJqHnEPLUn2ITxcmxBGduG7TWueh1+2KElVMQI9+j8IsD+9xGHUPtiywVEJ VpxaUlDqOu0tNovRPzkM01pg9KTqvydJ7BgAV0GgpoAH1rnYuEIh+kqieHvOLN96 uSuOjzTD87sHClWfIhuf645GCK+iy2Ln6f8yzxZn2DT870/yraX7eCaAK6gQt803 FMdBY2qtw3rFuGMW9ca/LTGlu04BrQb/boIEMhUMLdfAdBbJxYPuTbKbtBCbfcew NtB+5sxAuy2o8XcHsX/6gjDBi4rb7xp5QKy5xgsavE+uqyXAwCKNFF5yT7HNYX33 UMnSG1069frMXAGTYAPzQp+7dVLGs6h+xPx8aut/SoZqHjQOxQ6Qv5PtgltRvfv3 ZsOrqE5a0aly6OsspTUN =/5TL -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] Are DAC_OVERRIDE CHOWN capabilities required for ControlSocket?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Thanks for the reply, I added a trac entry: https://bugs.torproject.org/15659 -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVKnKuAAoJEFv7XvVCELh0lLUP/0VeXYEeGOI9acQtvY0WoCP/ Qjq6i6h6bRFsmPqs3pa9qqUPKo6RChE0tM8ky+kV3b+DfuFR9oCFxokTG/C3g3Go pwkvfvh7JNP9HC/vHxLa3/a90gW1999UXz4aevqqz6GvBXKUphHWIP9T1hVSlBn3 FLMaA92PrpjaDGD8HSbgO6DQ8SAQjkaMRnrpP5fJscdpKvd3DI4uJQDmdDmcSCHP 90HffJeJcSogOhTLKE7V9oUgeIG/9glIV0fDH/pg/Z1ld5utZmNNngj8lzTJzwS6 8CtYtP8mZV+hz1IZId1aZngWBtuv78+LtuZlYG5s8OK8xr5Q2SXiyoHQSiVIYnea fF+Y7R0uSXZtzILQPXASQDo7TzfOq7tQP5Ro4ccFXNQWJ2mz+PpYUkWoswI8HJdY lc22t8OrIawknTWbmcPJeKuxjPvgeyH9tRQDiv+OrgAxAejNevHP8UgDadtuMin5 2mPtOCx72KrnEUa62IS3a9uOCGWCMadYXSPf6iWB7C9wXTSUaTDF5FBR0GZQt1fu d0vLsqzpgQG5UZp1ZY/Wo3rji5sOdJXWbghkjPIkixrx65zn10RnU/uplj9OVzUr Yhe6H60N5wNXkJS9VSFkUUfg5El5HSV0sVyedLk/e9ygQM54wg7EOBpn0lUNtjJ+ dZk6MNtRxNtT3epNomFC =rNyC -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] onionoo: historic details.json data
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05/04/15 23:35, Nusenu wrote: can one download historic onionoo documents (details.json) archived somewhere or would one have to setup onionoo + feed old data into it to achieve that? There are no archives of Onionoo's documents. But of course there are CollecTor's archives which you'd feed into Onionoo. Though it's very likely easier to parse those directly (possibly using Stem) rather than setting up an Onionoo instance for the exact time you're interested in. Speaking of, what historic data are you looking for? Maybe it's something that we should add to Onionoo itself? I've a few use case for onionoo data, one of them uses onionoo to find groups of relays run by one entity. First_seen combined with last_restarted has proven to be a rather good datapoint for that. Using an array of all restarts (instead of just one) would likely reduce false-positives even more. That is one field but I'll consider (historic) changes to other fields (contactinfo, orport, dirport, ...) as well. Although I could imagine atlas displaying data like these were previously provided contact details: ... most of my use cases are to uncommon to add to onionoo. -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVI/odAAoJEFv7XvVCELh0ztoQAKbcOuA0A0/oPlt51sSMCNqU sWFCPadSOOwpKFW0s4r0r50DRiYioJ4qSTsHeOm9kLFlywoMu4mOhePEGNIDtpCK NH8KYAqWL+1eqHo1fzSNmDxqweORwiyVV4k6FJF6YPi3Lk0pHM8Dy1zllv8CAs2l 0SNaauAPEz1d7PxBBu+9X8VI7i0ChR2zvt/1za3EoEIt5yK0gu+zvyeEOcTRZR1W gwQZ8UnoDrhVYeMtei42ZZtDchOqOHVrq+0BfdWPYnOb46ma1zK535o24lW0L2Ms UwTeFtMQTc1jhM4b1GpzBlcitQCwwwgFCkHC4ZG+jAujCP/cfX/Jp+YnHH9NLe09 N/9YmtxJr2LMtUmGHF9w0TPwlSiT8syJaPPRBpHifpOkNJwP5Mbq3fjCz8No8HDz zNtGetwtsqJTTzRa3Dyd8HBYBXaZc/Ok4I3wQTw6gVF9eKKT72eCvjEmNRGigNt0 VX4hLDrIHulY5U3+9ZOJhrB1ckqfrZOnElp0Ls3xC1LFXp6AvlfulM5MsRT2uad5 3Y1xNMY+7V0o3bQaukof/bg7NcivYteGWASnHR8P6uZQJZ5VBK2jW/uftu3oVlbA JRjHeIxO3BLpNKbCnQSxZU3Y/x5sIXBHYpPokN4y/ofgBt0/U1SSf96aRLgVycfj fNwlLSmuLs09fu2N2/GR =Emnw -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] onionoo: historic details.json data
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Karsten, can one download historic onionoo documents (details.json) archived somewhere or would one have to setup onionoo + feed old data into it to achieve that? thanks, Nusenu -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVIaqIAAoJEFv7XvVCELh0OQgP/3FiBM3uMifPW9A0u8sMuh1E 7iFDmU52MNmkeToBUnuxuUK+7ig96tz/p5Ds6OyaAtC0Ld/IzRlIU5ELjqDwRqMD LPaafWm21QHO8y4fgW5FfGDfFTeLL/b3Lm1E9VmJ8wpOsgpzNnBMUoeDrpDyE3Ow zHXM/IfCSROqmO9lOeU6YGQTwInucc0HSveAWQ9i/x6iks9kMguzGnuWTxgfwA61 RQT4KUKZI+b5w//8V3/IpR5jlQ2N4OJrURpVhaKKNYMy+mqOfl5/a1ZPyQhhDaxj eLfg0qQmsk9IJY/6dZa0XogsmAzRCcEO/Ha0b0ZoiWs+VFo97cczoWdVWHoKpsyS X/qeehkOS13l22mw8va+yuj4zoRBrgK2chzcG2iPgVBeTu1H7B+x57PQrQXaCdaf rq8wwlS7mgaMQ6mgHyOQ1niZDTnvJaY0e3gVsgucR7YOTdALxnnHhQkyNboCWq/E 180SetWZfIHbL3cV38DRxYKzijwSu1gqmkwTJWffylb5SMja1TdW9cCq/RzidqyF v7vLXHQwmrRQ0XOy9UULe5XtU0Fe4YCm/zMNzBHHGIrePd664mYKqqXP2dlempwb BbbVgMLuFC2sy2eqxtwyQrrDUoWrEovUxg/BeoKO8RYXzNhPtha8eQkAhexhNux2 2mosesv/fooaQnt17qAo =q6LM -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] multi-instance tor with a single torrc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Pascal, (OpenBSD tor package maintainer) (splitting this part off to tor-dev, since it is not suited well for tor-relays I guess) For the interested reader this discussion started here [1]. Pascal Stumpf: Multi-instance support isn't something that's provided by OpenBSD's rc.d(8) subsystem, and I doubt it ever will be. Too much complexity for something that's more of a crutch to work around few applications' limitations than something universally needed and useful. I think the real solution would be to talk to upstream about improving MP scalability. Even if it's just something as primitive as forking a child for every ORPort directive in /etc/tor/torrc, it would be much easier than having to keep track of a bazillion individually started tor instances, all with their own configuration files. I guess this (forking one tor instance per ORPort line) sounds a lot simpler than it actually would be. How do you handle ControlPort, HS, DataDir, ExitPolicy and basically any other config option, ... but since I need a solution in the near future I'll probably just go with multiple services on OpenBSD. thanks, Nusenu [1] https://lists.torproject.org/pipermail/tor-relays/2015-April/006741.html -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVHuIaAAoJEFv7XvVCELh03H0QAKpg05vfOS/DTJ6Qhl7TfQV/ pKiAHjVfbWOfBD4vfqMHX0H054l7WfRUUiSz6gZ9DRGwXj7uDXh59kjsNa2ipMvK 4YYvDXjUIh3UBZdDnjLrkRPI5Lws1PuCi6wvnFX+e/weWiWQ18N/2HALaluhyldI 3aiDWA3k0ZnZVkuLLpbkxvbol8HS0upMTkwWlba/QXdWflK3it6sydkIi8EMhMx4 cEfTRCvWjxxU5YguIQ7/NpNFpKvRCtUEoCKBLjXuUGKTvawQ+Xu+XJQeSqE/yOqO Z1lTSQqH4i7JjBGEMxXQP/U7B3gELxv2tRcpfImGQZArLim41VPTVXse2+dPhb4d 0Knl19yYxtd4gjtoMbnv3GEPNgj2xnBr8e2MEYDsRY+rGYFnHEtnPvmJmC5p/vtX NAcuReFLd+y3j2PuB0XJHlGYOLtzvtaXJdiqV6oq42Mu0VHpiGfbTfKi2k8ZMUTw PfLQjx9z3dQ6GleC1mGHdMeJ7bJ7Wk2dJ7dicLF0veY5/Gc7gkYtWibsLXggTwrQ K0IqXnGJ8fWM41ZO4hhpmkkywhXodLzlWlXCxgxDUBsuFci/mVvtfu6ylxh+LCqG y5TxIk1T4/i+atx7jvuMLgrZGf02YgFyCf15Swj+VoDxx8GAxJl9nEQx0jD5d+Zl 206/+0QAI5hksaedorvj =qUCf -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] Globe vs. Atlas - deprecate one in favor for the other?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 IMO, Atlas is has better aesthetics I agree. Perhaps you have a good point? Should we be focusing efforts on either Atlas or Globe, rather than both? Given the scars maintenance resources I wanted to suggest the same thing. -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVGRynAAoJEFv7XvVCELh03vEP/3C0d2lXfZ4Ug36R2H7wFB1e WWNbaB4vxWC68CmIvjOU5e7eHaZhdhJ6ID4Fq7rC3N6uVZO+7UT21m0W6B83a9p8 Ev+Tzs2KDEvcnp/rLYuq7Cl2E6lzcW1kWwtG1aGwYAAZrxtqJbPIm16zlmp3n0hM J9I1P8MLn78yn9reYBLuYMDwvCWFIKR/FcOuwscbhlkaooOBHJ/PBo5JoLHVdWkT JqKd84I73PKMHuWoI02YaE8mzJ1ykNxNApGCr73OkWT/PJZ2ENelpOHyU9sCxYy2 HjVbGCS3z/BL08gyflyhKu8blg2DN+MbM2ah2uvUCikAPVCOAEHJXCLitp+LkHzo GmlcihyzIBugWTZytVRaur1Bw5aEXuFvvvV7SfxGqw776AbtzLj3gxZpOZ620gCH 7HM13yysT56s2iCY4B2IPnGWThKBuKFxHOKsctaHTpCZHRfB90JbIaRwnZmIwUTb LrGzyeRkTJmTnhxr+fr20d4S3HMaz+YXYxoJnnK9wM0hUIbD5qYUJEcMJZ0L6PFs SpzETF4fow4+OtdYKpIOy1UYeURAzLLAmesB5wZb51lq7H4Xj6PljWM8RV7NpyWH Aa2BG8iHhMgoHWILtzWtDnJh8wQJniLAzexzqmIcvWFVvFj/2h/5Uew57IfRt2Uh ECnc0AxKVXokRu/suOLN =o9Zk -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] Globe vs. Atlas - deprecate one in favor for the other?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Well, this is probably difficult to argue about. Personally, I like Globe's interface more. A matter of taste? Yes, definitely. But more importantly, I think Globe has the better code. That's probably a question for real web front-end developers though. (Not saying that this wouldn't apply to other people on this thread, but it certainly doesn't apply to me.) So, maybe we should improve Globe's aesthetics to look more like Atlas' and then focus on Globe. For example, I hear that people complained about Globe using too much whitespace. current situation - - globe lost its maintainer - - atlas is maintained by phw - - globes code might be better according to Karsten - - globes graphs are more powerful (user can choose time span to a certain extent) - - a few people(?) prefer altas' UI over globes due to excessive whitespace in globe Eventually the one actually doing the maintenance will be the one deciding which one will be focused on - I guess. Atlas tickets: https://trac.torproject.org/projects/tor/query?status=acceptedstatus=assignedstatus=needs_informationstatus=needs_reviewstatus=needs_revisionstatus=newstatus=reopenedcomponent=Atlasorder=priority Globe tickets: https://trac.torproject.org/projects/tor/query?status=acceptedstatus=assignedstatus=needs_informationstatus=needs_reviewstatus=needs_revisionstatus=newstatus=reopenedcomponent=Globeorder=priority whichever of the two we focus our efforts on now will soon become the better tool. Looking forward to it! btw: I just found out that globe also supports contact:keyword searches, maybe this should be documented somewhere? And because it has no 40 results restrictions it just became my favorite ;) -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVGUNKAAoJEFv7XvVCELh0MwYP/3gUauB1Wqn8D1sIdJfiqXGB KNnBlEGAOA1u5I2luDd7zYrBSLzNyHcASEGztjlpH214UIKJYNmFCO7Q+0Ll1VVw o/fXSmUcKNcF2sWonSDS5KduM4+zIf+63cRwtZ+XhhyivmHa6/M7aESu8z4piCDY 6crI5RS15HE6cMmgn0P5J6MNcO55AFuLtqbon3niiWH81mHmlhqUeOFxxYv65hWF QpfUrhxNZu1dNKGBimKgaYXGJ7a8J46Ct2TqTJkptLH7OlqssHrSBkr/u6LkLy9p or7lnFEQon4rFswaGJUscAgkwAf3BbZOVuJ2/qt/w+jtwEdEQVeG2C114kyWCgqW tdoWnvsl8Hmyts/e27EP62yBiwoWK7tuRqlkEs+ML0ViGpNxt+QckNMecG5yTcLh JkQqtO8/mWwACJ4FvmNIgReqDfi4ZprwhOfWNQcboLMTldBoqg6cfMe+xTN43XFO w+MOIIoy8t+BSJm5hHGrmBYpeUlFRhNIsoR0lpCKkq8xkO3QPDcNLwx171n+m/dL g/Xv90DNZiU6KVUBBJwUlMJLo5DV9M+aXNPe9JdwBKqGkSp5RGDRF2THew+8ie6u j+MShTi1hJyYY6AKq5kxwXz5IkikVyhZkKW7viBKxSr7OWnC2BJSc3W6N+/E9uMZ aaUm64+YL7gVn/6FfjSm =Dn4/ -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] #14997: canonical path to tor alpha debian repo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 What do you think about #14997? https://trac.torproject.org/projects/tor/ticket/14997 I guess this would not be big effort - simply creating a subfolder for the alpha builds would do it? Ok, I just saw that weasel closed it as a wontfix - the same moment as I wrote this email. weasel wrote: Running the current alpha should always be a deliberate decision. If you can't be bothered to change your sources.list once or twice a year, then you probably should be running stable. Maybe explaining my use case/motivation will make it more clear why this is not about changing the sources.list once a year. I wrote an ansible role [1] where the user can opt-in for alpha releases by setting a boolean. So this is already a user decision. By taking the user's decision into account I generate the appropriate sources.list entry, but if the sources.list entry for alpha releases is not static this will break over time. I could do some lets find out current stable and do stableversion + 1 but that will also break because currently the latest stable is 0.2.6.6 but there is no such repo as https://deb.torproject.org/torproject.org/dists/tor-experimental-0.2.7.x-jessie/ Generally speaking it would just be a lot cleaner on my side if there would be such a static place to go for alpha releases. regards, Nusenu [1] https://github.com/nusenu/ansible-relayor -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVGTq9AAoJEFv7XvVCELh0qE0P/3ettdEXYKEFpMbpM2JNHRmE uCE+B1RhLQcdZEUVno+LbcW1xo2U0mKlFPNQQ+LTQ9ZUsKXuIMhT0VXwsp54UWXx mSXu4AS5V6PCkL5FK3zd2t6v0+TC8oLVk1FgaBsRKsF3LSlCb7gLEmah3yQAAfND iIhIyg2GMDt63La1QBJDvx8Pl4tKyOP9NRH/5oPCdmiiax2R5reaQ2HPS4XhBSBM 2X8BK3Nr172DOV/ZzkeBKV4JfxmqbgbnhL6luKZ2sxfrjH1uNbnYLlhrp2jXLccJ NZY6s5L+Z4NfE8AD/rKPdw16xV+kzANrMJbC10s+EBB0bAo5C+sEtrhyRZVD7Vaf JYH9uLl+0IM2LFXkk1M6uOGuUBSxW2n+cQZHndSMGG7ynH6Gn8spZtv3i8JGrXiU 3MM9yWec9Mw4S/f/CBUoLTa0N1cDo8x7ltMYJUx/ilkSgGGkQExOSNwKSK4X/IST JKgj4m+G6Tuzg3cCx1E196J+bgYxErVJF1vQxDbrQ0XF+uk0Ue/12YajvPy/34Sv i7pTBAfWunA5Jx8I4iIDD817vcW3X3aAt/wyRd614rUzQ9uTcW3DxuJVKxC7e7Vc 9/DgiDflQ4cyCP0NlsTjRjFIrKjHgSnG3zeS8v+KJiSNoWD2kUvrC8MpnhkCZz7b R7Dcq10yzTdfZDPLsIIx =bctM -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] maintenance status of atlas or globe
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, is globe or atlas actively maintained? Does it make sense to create trac entries? (I just want to avoid doing worthless things.) thanks, Nusenu -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVFqYBAAoJEFv7XvVCELh0u1QQAKSai+lYibASpYdqUFnfka7E APq5zGYnkR1I9KGTR8aL9+Z/dlEzl2fCCztwyfFZPYFudh/qzPtSPDUInLvDE/za 3X25hbCHwyW9Q7jQKAYWYuYWACE1S4F62e6TFzoT20gga1EhldBO+FqL943D7DuV 4FPT6lkWuPtZKF5X3gb0tkS6d48o5NYSp3RhFsowX2Y3SfdoRnTa86QbQ+2k9g7K R2W6f53c6jxwUU8MC4W3Tqc2JykojFbZADvwi8QxJ+4KlxWimG6PDshuJoY+sdsX R0n5o0L986uAn9CA5K5s/ANLkl9cYgt/oxptsY4HWSFKAh6xjdQBSYt5qjXI+KxL d1PDPdGXjolePsjUv/md+hnoRVjo4FCjx+5aQw23QhGaCi9Np0E87rF2xuUNmszs y9F/niXvNJMp1OIhVDeTinLm18lkOVCoGz/UkHdbiBj5md/5GTfql3zp2Nssku30 O+hUOEuvTJ0mousMglFeWRiO2UiliU55qTEbIUV5o4YVCK4uWA11v06so6dI4FNh bRwqUTsnzU/PqLdvgDUP3fiZXizVoxQB+KMzwnmroV+QmL+cnAR7ac8hU/PfPH/F nC/lONV5ZiXnmBZXvHTnIUBeHRwtQi48rDWtNLnSQmRN3i8jwP1NiUmuyKXZgA2a 6+cGVMKBA+Xy2sBciw9y =2YsQ -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] #14995: systemd unit files - review
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi weasel, following your comment [1] about your plans to use systemd instead of init.d scripts I prepared unit files [2] - tested with debian jessie. Would be great if you could comment on them. Since it feels a bit as if I would use the wrong communication channel (trac), please let me know if I should move this elsewhere. thanks, Nusenu [1] https://trac.torproject.org/projects/tor/ticket/14995#comment:14 [2] https://trac.torproject.org/projects/tor/ticket/14995#comment:24 https://github.com/nusenu/tor-multi-instance-initscripts/blob/master/debian/tor%40.service https://github.com/nusenu/tor-multi-instance-initscripts/blob/master/debian/tor.service -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVFqosAAoJEFv7XvVCELh0AjgQAIlLflC6f+mqUUiAyvQsTO/4 +fNK1MBFUNJUpEws3gqD/3OQfBnhuV9Po4SiRMPfQo0IHuLSB0jNHslOexVBWzpY s4ypeNAH+Eu58Pomexo9xOMCZTmM7Jmhm8HdCodSXBMSKlK1jMwqqmRRQDnijf3T hYos6yeJydwXnV2yDaeF6AOiuAzIQC2s+Mwu+tynX3ETCIyDzsDcQEOaDiwnmWBX 76kIqz0sF0N7tOeMiLoMvK1J9HhW+sMH4aaGwZFXPCMLEpziIB5spEmgvpa+SoQ0 dG2q3Hd7ryBaac/KSeX/Dyidur8LxheA9slVqwkdcorXWBdQd7Xnom2WTOs/2cSf Dy3ZFJD1vi3/y6Gq0DsWY3Z4XhPPs4gTVOL056Xc/GyZXmPvAVI5mk8EdtU7ezbu NxXqjVoEcX59IWhyMOjh2eaeEZvaxmyfP38ek2f6nH5pZv9FtmjKZ61LwYtL8qJx wEn+qIVXy1Zl+qU/NhUpMeUqn029Ci+mL+6x/JfNpaka81Rtqsb+6SKQQwPwGGu7 2SwsDjM+B6YsWSf3niL3rp23XWaT1mM830QBnTrMpE+kht/4b1ytgs7NV72E30+5 Ibi5y/F/TkTc6yExJd1qxKkpXY0gnEWIgf0l4ik5FOD3DK47lQgKYg4feAcPxLUo qFDT5Y0Fnhezh5DVnRp+ =mtYl -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] onionoo-announces
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Karsten, the latest onionoo update 2.3 triggered a bug in my onionoo client (charset encoding). Even though it is a bug on my side, would you mind announcing future releases/deployments on onionoo-announce [1] including a short changelog? thanks, Nusenu [1] https://lists.torproject.org/pipermail/onionoo-announce/2015/thread.html -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVFeWsAAoJEFv7XvVCELh0aeYP/R9pkcPgMGttspr5cl1W1RM+ qeIutnhNDAMs+DcbHKmB19BzgSRUfzrm4DCqnizWIxdXcF+AQP2nhmP0y+hIWTrK 5ctBQsWMUiwHym0TcKbbIEHrP2BcIoQSIM1GG52G4OWfmoymjbi5J1Jd+KuXYsFr 8GtJlLkjHWcD8wQuCUtMSfq1tTK/XnQES/UfhTUfJ3TMZvR1wxD3BNWZFJSOFMP2 k7cfBLYSG2uRCyRZ8dkoLXnSeJ/aya2PqR41mvU5y+IdUHC8IoVItx3GhC4ZT2v1 YcQyxvVFZh0NEwrdnYIxErNN5CJjqDUyLPWVQPJGvKR1KgFVdtcqsJH8OsyvYW1y ysETJ9AXPReo9os+oAWVJZvFG1HwU6MzS4U7beuVMo3drzNh3433nkZbCX50hS4z WMUdsWjZgUNscAIj76ECI58wiTgYN8Ro5X9wY9LwSwJz7NHtc+a999xSLy3GUuUp vEerRa1k06PqeqpNsZoe/8WVwohZVtRc9oGTcXJgtRF3F3hltsqB6s03hGLsQfXJ roOFglxrUlBaGAVYlyLWHSDiPf2lVnNUF27nsGodjoTLEubsJ1BsxUqT1JTNi3yx k8WTU2ATfbTVKva0N7Ac3yBE8+ZkQ+YbZB839li9ocXuxi173/aNmG3mKOVWWhP2 x0C/WXllxI2ObZY05ryR =IfVc -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] onionoo: grouping families in the backend?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Karsten Loesing: Okay, just in case you change your mind, let's talk more about integrating this into Onionoo. There's already the `family` parameter which I specifically added for Virgil's thing. Yes I'm using the 'family' list as well now - perfectly fits my needs. -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVEC63AAoJEFv7XvVCELh0NfMP/0qLIfBOx3d4IT82+3a1N4m0 PXmBQwOTCJI6lMj7R3yOpBrFz9JAbzWmiP8UquJ0vG5a2DffGL29SoUr3dvOIsnR NLcjOfuPN5ezy41t4C1bzAYUjR9lJNHKx9ZJab35moqkwd5gFSX5JmnD/+jm9ZZ5 /GtAXAFD5/YIXv+hNeFqqdH4zTpju8T7EWwAiSiqbfYP8JUBE+Bhr0smE6xtNWCp yPSo+MbGd/U9KLUKSU7XlTBYxBip0F47JBW1yQ0EEjbxt2D7JndyaTWOiGSaOT5v Z379XBHs+XI178GOkt06j8VqeUjjcaNr51o0H51/R1gVoQQdHdCihDCgg0Rg7+Rw ZKHV6tnHk4dtQiACH2rdpxnBm8Hoew8kOfVma0WgzoZGCWM0GKKR6uximxYxsNV5 ViIbSv41UsJpD/qA9drZbBRkc97pO+GO6dTGSKuBSDlLwZeKHPi9cFzu2nyx9ym3 i7fVr9UGRNIWX/3S4798vmRmqLdOQ3VoRWo+nMvzuSs0C3TS1j8HZQC3T5uljo/y Md0O3G6BQYgbS/xvcnaA/PdotftJDt3aG2G/rjWlit3ko4IWFFMVXx4i1S1ighzN iy4TUlEcRwcyy4me00BJbpyqVDNLhljYXO6Qxqs36aAcqyl0E2PNf3EKgEwsmUxM RafKD5DotGVl/wR8cylo =GKel -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] onionoo: grouping families in the backend?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Nusenu: I figured it might make sense to discuss this in a separate thread. And just in case you were wondering, if you ever have a feature request for Onionoo, I'd be happy to discuss that. In contrast to some of its clients, Onionoo itself is actively maintained. Actually I came to the conclusion that it would make sense to move the myfamily grouping to the backend since any other compass grouping is based on onionoo data and not on data generated by compass itself (grouping key). The MyFamily grouping takes also a bit CPU time. So computing families once per generated details document make a lot more sense than recalculating them in every compass query again. Actually it is be a lot easier then I tough and does not require a backend change at all, so you can ignore this one. -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVECKjAAoJEFv7XvVCELh09csP/1WURzPDEZQ23zo3BzA9K8PY 3ubeSLeh2wecp/l0DNvA+vg4PwslDfFnTLeesyjtGR6Z9M0ab6GoyJvDZPiJ/pUm 8HzOpE81KfdeqCkzBrk4nv0z+KOV3ITrjjr6k5uX3DJ0TVj0DdxtrPSHAh3F5li5 CBPA2XayIuyW3Pg5lQXLQPm+TILjv2PkEfhDElfnvGwp4kH8/desMwYEJ1xVSpiD Un7wSHP0DKxbh17OkxlEBwGqN+5a5EcGrcL/RLRLdDeeyqjIFeQ6kvEReseH+3dN M/9yxVs9yA5Q9HJSO8tg9J47TwUoX43uds6i6pzfezB+gr+HbZviWmJh5PI2V66d fYw/d4Qi4IgwdNseuVzr2Z99+XEWfk/ZrkhmdB50wKxyrUM/9UlKbgqcHmUDifcR SWyF4emygElZjD2zhpQ28HiaCN6Nfq0Kd2bNfuSRn7ek/S5n2JOHjIvpju5Bni+C GVh4Of7NrwoFVK3dexO9C3IwT1D39NDY+NZsK4GSAhw0JGB30eYzKLABaQWUUB0C Ukp8kV6MqmgYqjx88l2VQN7VkrTkhFc/O/QoA/bZefskiOV0utruYCGUM1SbUSQw u0eJUdRAg68UP2ni2jgqw5ND1bj/ZJR5jTdPQN6DaScqNwaG6AZy1ClKTITHuqWn 6J2pWvgsGGfzjTf7mO39 =chND -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] compass is unmaintained
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Karsten, thanks for your reply. -T --by-contact (#6675) (Maybe we should truncate contacts and remove the undefined) I didn't look at the ticket or code, but truncating contacts sounds like it could confuse users more than help them. You can judge by having a look the example that actually truncates contactinfo here: https://raw.githubusercontent.com/nusenu/misc-files/master/biggest_tor_relay_operators_by_MyFamily.txt I can tell, it doesn't look as nice without truncation ;) Again, I didn't look at the code, but you might want to take into account that there's no check whether the platform string says Tor 1.2.3.4-something. You should probably treat platform strings that don't stick to that schema as missing values. Agreed. I also plan to have multiple group-by modes for version (and other properties) using a radio button selections: Group by version [] none [] major version [] exact match Heh, sounds like a hack that will confuse other contributors and the future you in 3 months from now. It's probably worth rewriting this now, as long as you at least know why it's a quick hack. It's going to take less time overall. :) Agreed. I think it's awesome that you picked up Compass development *and* use it to find configuration problems of relay families and other problems. This is really great, thanks for doing this! Thanks for the kind lines. Regarding the tickets and code changes, you should know that Compass doesn't have an active maintainer right now. All I do is keep it running, but I can't work on enhancements nor review submitted patches. So I guess it doesn't make sense to add/modify on any compass tickets in trac(?). I think you should fork Compass, maybe give it a new name, run it on a small VM somewhere, and become the maintainer for that. Ok, I'll investigate the feasibility of self-hosting a fork. thanks, Nusenu -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVEBtUAAoJEFv7XvVCELh0EXsQAKUYctGMwkL7jYU1M0Ejxwss uO4TYiOEby+TyxeheiYTQYFarawxGMG0XLBeABVsco6U6UzPtqXwH1OXPY6S9CH0 Q1MDqzW26i4cYksOWhj+GABPDlOp+NlcfOYoh9b8boiMYU5N/QCPzPZmvcz4Xrdi 5FXRDr1Yd0Ih49J+eteUnQ3PPptf9KvFN+MtglTaof+MbM7XmgfAwiVHsg7SQdJf a4O7Q4IOb6fNK2KmKbF6chJlqF7FUyP1jBGLswjrwB/iQqKzfyCx3kCt7UhoqbRU W1H6rMKub6Rd2oCjzNiszhrTY2uIU72y/tD6SO1Q0pX0JSEcj9MDqblQdz/bdwKG 8pZuv/0/ApHWQuuxS2P+RGFAknNwuTQSznQ+I9MIP5/3d2/r2XZ9adf/24oWZECW Kc2DYP/NdCU8HPL4mQQxtpM8x3mC1Jkfp/BVyRDOAhfp5lqPffg0MCB8/tWzQA8l kHqFEz9VfTeEy9aWSgEgODurYUVdb6/Ch6sS2T3Gq6BrGam4Y/DL9jczPvuySdtp jdVo+2izQ2aDtEg2n53DO6nV46s2keY3wJd0M6GDn6+bEYc4pqBLi8ksrFBa+kHH 0tlBmrWzCsR7R9liM3XNODmWH4OVfMPpE5HO5H+N6aLdjYy3pbV/Q2FtwpCOjwPl LJNBjsO6IIpWBS2TrGmR =DAuk -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] onionoo: grouping families in the backend?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I figured it might make sense to discuss this in a separate thread. And just in case you were wondering, if you ever have a feature request for Onionoo, I'd be happy to discuss that. In contrast to some of its clients, Onionoo itself is actively maintained. Actually I came to the conclusion that it would make sense to move the myfamily grouping to the backend since any other compass grouping is based on onionoo data and not on data generated by compass itself (grouping key). The MyFamily grouping takes also a bit CPU time. So computing families once per generated details document make a lot more sense than recalculating them in every compass query again. Since the MyFamily is subject to change [1] is also relevant here. [1] https://lists.torproject.org/pipermail/tor-dev/2015-March/008516.html -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVEBuLAAoJEFv7XvVCELh05MMP/0Gy6zYQLbZtavXL1wdISLMg X/zdJM9+ZysuFkDj2hl0fP1iXfrNCCCvjCOdCYQJXzD5axrvgzPK/Jql1b2J1tO5 m+fbkLla9/KRCukJKYOjmkeoKAuadRDiZvI9LvePuGPrP53ZmlJmh4PT/Iss8Qh+ ndTBIbz1Kl04cBVS8RW08veFIKyzblkd2bJVj6AIlsvRvNybLJdEatgNAJ0YX6Vk ERuWuI65qP40ATFMAmL+IMsrdJ2WVdhpbbFLNkrZfloXt/UlNvFddMKlJ0k3YUkb ZQsFmZUPPv9+gMGx7Rkca94XmleBxMidjAbDVT0Y+SVyC0HxEOa5UsZ099cVu52F Hf2ZHt2E6vSxICoO4lxFEx82BxuaJLvG/+pQcNmUQk+SeBlcYn/W6PIyYV1bs9sh /pLjikLnMEMpNCls5XNc/wtFJtbnfljmsDhYL+R5jCHfUk5s3XmyEuDitenwZ8Qb 3u4qtnusQqLzW0R2bcnA8OV5RU5N12kBmFnki2lZ+m7VKtHCQVgJP8Rpvfg7G0/6 Js36UnNL2ijMNuDJED70PZEPop8kiuSZq6ePI3lYsPaLLRGLmNyHCgFQFRBox4BK ntAiePf2HtQ1kSLM2j5GLrQK5p59ko9xXrQkRBy60M5oVJkl+Rtf/+79W0Nf9f8Y /rcCkyU4s7XqW0UoHMYQ =ly6d -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] onionoo: grouping families in the backend?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 another good reason to move it to the backend: Virgil (also using MyFamily data to group relays) and any other application using onionoo can also take advantage of that (no need to re-implement it n times). -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVEBzYAAoJEFv7XvVCELh0VcUQALl6VpJkHJH0DSMg7sMfKJ1s ys8d1Kf2xQJm3ygXyYSth0/IB6dF6g5Jc6GEUYaWolNYMPygzncb1s1cVIh470QP SvdBBXEjghmESfyVIUBbINmqHAVwdIzjWPne9azJJm0uc0twF0yx+Lz6WOlBmcH/ OQcOUo2YBz1UMy8rPNdrmEsjMriKGiwfp1F7SXbBj+P08/m2uc3b1Jo7sbCejesX bOKxts0l9wBkiWSu072bLijRVx3Upn13bhYZ8Z/F+XRHRc0+AzCgCwUJcMfFcZmn WrNrIZrcgjIfynb/qM9GkaP39cC1QLnoSJ8NVS1NHQ9GGQNRUGgWsY3WwIGoJYsK g6KsYXydhxDw/shloV/hqHdyLKsBFr9qKymasXQ/BSD2dtyzkv0JncPvICDBcOBx F4nMlYKrAXeS9LPbY/okSQrDygimffFlwmhi8IKc9hW2ZmRyKWzeKVt9/gYvSTgS RF33ZfXGLI8jVlk834xVuv35JmRjhFDXpzhlYXPVKVsqWGJDr8tbRBX2oiZ1Y34L E5OWPs+7l7FKjp4tBpEx3wdJAY6vRd6U0bl/AatpbrXDvGxUgk8BXz5cAPP7gxLV HcdhNac2sfSh7PjMVFPy9GFIU+h9rq+uS1fln7Qp4xWGm6FThaAn/XzZvpwyGWTK E64z79N7+odYxeRrxMWf =CaxB -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] name for compass fork
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Karsten Loesing: maybe give it a new name Is 'aggregator' ok, or should there be no 'tor' in the word at all? -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVEDJZAAoJEFv7XvVCELh0kJAQAIGzub91WhiAmE5qpRe2Y6l3 dYIu9/XvSjF/CchcxKx64nR5/6iSggSb+1anWgWNKDJuSBi1FiOne5aZg9EWI/qN mnqlqSIKAocBrpGWnKF4z84us7EjJXFVCwhF+BEsjJZNy+LFdjxTq06fMy68JcBO nluxXvAanG9SamvsG8Efc3SYV6Wk3vIfANGzI12HKHbvodBEVfE3o7fl4qCwfNJn 1RTCleQIEEevaf2Bm5eviy6UVPlHVhHgHQKK0EiahJPTo3+MIaTTEuZPb4j7SPww OMtk727hPYFDikMsWb42wGwu+iXXfDg58nv694AAJzrkoM8cGtmgEhduCmLf7Roq Azl/QPNvHyGv2NYjb1CjHEyU5h1FWFv+JNinUcSF2jZaOZD4rRwlJV9zGTD4oXR2 rTZMv/5ada/fCPM7y5NUFQSWrGUds+lu3lZh3SFZSzMBqxKOJ1f08LbPErjX20sR 009Qk/uPa4wRG7c3f6sCQ0VRCm+QdBmpOWqSxN6XbinrB9MqEiPZcF5EKRLZZUL1 aGjgb3tPN+qurkp1RIAJZGYUEOP+LK5h3j+y2rssYLomAd2CwmIGeOZSr5zGC8VF V5Q2FgvVpi0xlvKFT51lwa3AAu6IvFgbgQE2haHfGrlTIfR/V4BkvZbZZh77bw0b U8dQg/NVE+54ZPB5mhiK =9tWM -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] onionoo: grouping families in the backend?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Nusenu: Okay, just in case you change your mind, let's talk more about integrating this into Onionoo. There's already the `family` parameter which I specifically added for Virgil's thing. Yes I'm using the 'family' list as well now - perfectly fits my needs. After comparing results of different group by family approaches (expensive vs. simple and fast) I noticed the simple version does not come without a drawback (requiring perfect matches has its consequences), but I'll play around a bit more before coming to a final conclusion or before requesting any backend feature. -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVEHlIAAoJEFv7XvVCELh0tAgP/A4XxnYBAadqfVZheGC9l/N1 8SAAncjjbH6obDMMfCueOCHQwbb5oWWUXN7LSzf66zsmQHxbzauy/giwgWiODIR1 OPMvbPUtQS3tz7Ur6wGuhd+53isUUaR3BlcYSXnyfz9NyMuzlMUd4NZ46Mal6Xcd GkgcKjeyP+WxzG8nFzD1LPm3cb2kQox4RnJlOtsqV1BI3oWy3Xk+ls41JXH2t93e Gem0ZdJ2uXN2p9ay7V+mhcxPS+Eobl/TIoI8RuNyNzNgZO95tusdk4CNbqsk1gFX zI5Y25DiB788LIsWD8eLc1K+BRgeWbow3n7CD7N5+WR3TjMwpoHiZQJIM1rJOEOY AXIUPK9h8/iaBVvTrStZcxs2IrjpxE7R4a3C1Ry/Jll1/5cN2BWPDE/4ObTQyQme AfHDp0qGJK85Lc9w9VLOi4tEUC32FHzvgmNdju2sIbkJUF4fPCFe09nZUtJ4OHjV qbodUZryoQdh7MxOyfv3I391ns6ML2POohcP7+JXhR1CDloowyA8FNrjVe21JkYN lQPhg8i6bWGJqp+jQK9z2KA7jjv8I0IMO2AHNdVoRx0yJ1/xJARAMqWeqBQW8Qaw qPsPwfGqORWkRrHVf16/a4EYlnqni5OYWobPVCulyLxJty+gVZGX+TYLIhANuAfF joHGjhZG8Cs7JQROb+c7 =rPiV -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] compass: new group by options: by-contact, by-OS, by-version
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Karsten, I added a few new grouping options to compass: - -T --by-contact (#6675) (Maybe we should truncate contacts and remove the undefined) - -O --by-os - -V --by-version (#6855) +expose -N options in html (was implemented but not exposed in gui) https://github.com/nusenu/tor-compass For all output I (mis)used the nick column as a quick solution since it is not used otherwise when grouping. Advertised bw is broken for some time. There is no 'advertised_bandwidth_fraction' (This field was removed from onionoo in November 2014.). Is it ok to change this to observed_bandwidth? (which would be a non fraction item)* ? (The MyFamily lookup is also broken) short commit log: - - add new group by ContactInfo option: by_contact (-T, --by-contact) (quick 'n dirty) - - added new grouping -O, --by-os (all BSDs are merged into one group) - - added new grouping by tor version (-V, --by-version) - - tell app.py about new options (by_version, by_os, by_contact) - - expose -N option in html and fix a missing label tag - - include network data in html output when using -N (uses nick column) - - expose by_version, by_os and by_contact options in HTML - - if it is just one item, display the actual value for AS and CC instead of saying (1) What do you think about it? thanks, Nusenu *) while playing with that I found 3 relays from JP that have a suspiciosly high adv bw: https://atlas.torproject.org/#details/F528DED21EACD2E4E9301EC0AABD370EDCAD2C47 https://atlas.torproject.org/#details/8901B1D2D4C0D3398C3F8363247B5AABF31369E4 https://atlas.torproject.org/#details/4EA0464A1B8D4231F176BA2FA1BCBF0A26F128D5 reminded me of SKKU43: https://lists.torproject.org/pipermail/tor-talk/2014-February/032094.html -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVCtlTAAoJEFv7XvVCELh0bY0P/1aJyZncqdy47WZM9I7Y1E4a Sg1luXTqi9VlFZhbUJeFrhidLVPSqQYbMw79sKufU2uw/Jcqr0Ro2O48q9Gj7sL8 lDcM4AgFzm1yTedoXqyNAA5+bBeQTAjEgQU1ADYUZvDx2ULmGG4aD6qCuaFoP+3/ kjJ6r92jLOSYpOVdt8FyNc8IZYpbEwQNMKc4A0uZhQV/WVv6vFiOaXHliPdR6m2+ SU+KTqldWppfeezWIalGl3t7HEnz87JOaWrdnQ8fjLKSsqkex2T5E1MClguM4u2o 5ABPxg6uF/izjPv2VEy/hl42RQbLM5SDazM4CLMFN3mQu6Xa4iZ5R8A6iLDgZBj6 zK2wExcxScc58r4Briv5EKUpC9LTgE52DkPkX+TM3i9ktniYQbb/k/cy85nn+ENa WrZ2WDmaMyQXy6kXDCS4U/3gbv1+Dwq82hg372N2fga6hOXsZPFrxV1TwWlMTzp9 MvpaF6/GZsivrjNklteHxvxgcxTyywaKW5QUdFJdeCZnOrDy29iGKIql10xQ7TXa gTC7OTsDCAPiJn8P5xKhEAlVeJmz0zZN7QhbY/ybIc5KWkOoKyYwkT9ysmpS8rOK mapKbuMXvuA3Sg1F1sK9PEUy+D8ZAe+sBjOEHzqILARA6VXsly0rSJkcnhNKNpmL yxSwWe4uWOVXDmVEl7hQ =jGQe -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
