-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi Ondrej,
I filed a bug regarding the rpm packages [1]: hardcoding config
options in torctl.
Please let me also know what you think about migrating to systemd.
thanks!
[1] https://trac.torproject.org/projects/tor/ticket/12834
-BEGIN PGP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Nusenu:
Hi Ondrej,
I filed a bug regarding the rpm packages [1]: hardcoding config
options in torctl.
Please let me also know what you think about migrating to systemd.
While reading fedora's tor.spec [1], I noticed #8368 [2] and the fact
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I've searched, but didn't find anything regarding how we can
interact with Tor API (through the Administration Port).
Would be nice if you could provide some link :).
If you are talking about tor's ControlPort:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Ondrej Mikle:
If possible, I'd like to avoid the if-defs. Do you perhaps have a
tip how to make the spec file nice and have it work both with
old startup script and systemd? Maybe some patch?
I would not mind having clean separated
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Ondrej Mikle:
If possible, I'd like to avoid the if-defs. Do you perhaps have
a tip how to make the spec file nice and have it work both
with old startup script and systemd? Maybe some patch?
I would not mind having clean separated
/ certificate pinning for yum.)
Could you elaborate on your issue regarding repo_gpgcheck not showing
fingerprints? (It does show the gpg key fingerprint on a fc20 system
after adding repo_gpgcheck=1 and running 'yum update' [3]).
thanks for providing and maintaining the RPM repo,
Nusenu
[1] https
not generate any tor debug loglines.
What capability would one have to add to the list to make it work with
CapabilityBoundingSet?
thanks,
Nusenu
testing with: tor 0.2.6.4, jessie/systemd 215
[1]
https://gitweb.torproject.org/tor.git/tree/contrib/dist/tor.service.in#n26
-BEGIN PGP SIGNATURE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi Nick,
thanks for your answer.
What capability would one have to add to the list to make it work
with CapabilityBoundingSet?
It probably depends on what's in your configuration.
torrc file while testing:
User debian-tor
DataDirectory
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
so the somewhat obvious fix was to add CAP_KILL.
after reading:
man capabilities:
Bypass permission checks for sending signals (see kill(2)). This
includes use of the ioctl(2) KDSIGACCEPT operation.
I'm not entirely sure since that sounds
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
'systemctl reload tor' fails due to hardening restrictions in tor's
systemd service file [1]:
CapabilityBoundingSet = CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE
This configuration restricts not only the service (tor) but also the
ExecReload
gets released.
thanks!
Nusenu
[1] https://trac.torproject.org/projects/tor/ticket/14995
[2]
https://github.com/nusenu/tor-multi-instance-initscripts/blob/master/debian/tor
[3] https://trac.torproject.org/projects/tor/ticket/14996
https://lists.torproject.org/pipermail/tor-relays/2015-March/006605
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Zack Weinberg:
On Tue, Mar 17, 2015 at 12:55 PM, Nusenu nus...@openmailbox.org
wrote:
I had:
Log debug file /var/log/tor/log
but it is not being written to.
This is *probably* because one of the missing privileges is the
ability to write
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I'll prepare a unit file for this and add it to the trac entry.
a first version is there
https://bugs.torproject.org/14995
Weasel wrote:
Tor trac is not the place to discuss Debian packaging
enhancements
Right. In the specific case of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
intrigeri:
Nusenu wrote (16 Mar 2015 14:09:13 GMT) :
many relay operators run multiple tor instances to overcome
certain limitations. Currently the official deb packages do not
come with an easy configurable way to run multiple tor
instances
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
The MyFamily lookup is also broken
It actually works, I just expected to see more then an empty set when
entering a torservers FP.
-BEGIN PGP SIGNATURE-
iQIcBAEBCgAGBQJVCztzAAoJEFv7XvVCELh04bIP/0a8ncpIKzAAJu6sjF+9y9Jo
, status=227/NO_NEW_PRIVILEGES)
2) and when actually starting the daemon
thanks,
Nusenu
I'm testing with
0.2.5.10-1~d70.wheezy
minimal test torrc used:
User debian-tor
DataDirectory /var/lib/tor
Log debug file /var/log/tor/log
[1]
https://gitweb.torproject.org/tor.git/tree/contrib/dist/tor.service.in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hello Zack,
thanks for your answer.
Zack Weinberg:
Could you please put
Log debug /tmp/tor-startup.log
I had:
Log debug file /var/log/tor/log
but it is not being written to.
(I disabled ExecStartPre for now).
in your torrc, try to start
-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
-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
/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
-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
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
-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 -
-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
.
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
-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
-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-
-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
?
thanks,
Nusenu
[1]
https://lists.torproject.org/pipermail/onionoo-announce/2015/thread.html
-BEGIN PGP SIGNATURE-
iQIcBAEBCgAGBQJVFeWsAAoJEFv7XvVCELh0aeYP/R9pkcPgMGttspr5cl1W1RM+
qeIutnhNDAMs+DcbHKmB19BzgSRUfzrm4DCqnizWIxdXcF+AQP2nhmP0y+hIWTrK
-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
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
-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
space one would probably need for a non-public onionoo instance?
thanks,
nusenu
-BEGIN PGP SIGNATURE-
iQIcBAEBCgAGBQJVNq3SAAoJEFv7XvVCELh02xIP/14QAycUAcAhun36WyzhpsC/
gb8Ta0ryCzEBW3zT4//9pyrz3VO08ryLI6Kg/OgrwOSUfVxQtTkhrnYG9GZlr89Z
fPW3PgnilPFAikaH4iJzxbvVS8FrZdG3d93QM6uDsMHOfwuZZJg
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
-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.
-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
-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
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
-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:
.)
* 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
-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-
-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
-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-
:
- - (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
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
-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
-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
-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
-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
-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
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
-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
-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
-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)
-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
-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
-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.
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
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
-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
-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
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:
-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=
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
-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/
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:
"
>> 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
--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
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
>> 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
> 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
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
>> 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
> 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
> 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
> 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
>> 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
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
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
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:
> 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
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
> 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/
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]
(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
> 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
>
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
> 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
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
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
ecret_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://g
ell 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
>> 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?
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,
>>> 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:
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
>>
>> 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,
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
> 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
1 - 100 of 317 matches
Mail list logo
