Good morning to you too Ralph! Thanks for the project; I will try it out later today. Best wishes, -k0nsl
On 12/30/2015 10:36 AM, theonionbox@gmx.com wrote:
Good morning!
I've created a tool to monitor a Tor relay "in action". In the end it's a web interface operating with Tor's ConfigPort data. Currently it's not as powerful as arm... but it definitely looks better ;)!
You can find the tool and some instructions to get it running at GitHub: https://github.com/ralphwetzel/theonionbox https://3c.gmx.net/mail/client/dereferrer?redirectUrl=https%3A%2F%2F3c.gmx.net%2Fmail%2Fclient%2Fdereferrer%3FredirectUrl%3Dhttps%253A%252F%252Fgithub.com%252Fralphwetzel%252Ftheonionbox
I would be very happy if people gave it a try and provide feedback to me, especially in case something fails... which probably might happen!
Greetings,
ralph
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hi Ralph,
I will first post url again because yours give me 404 error page: https://github.com/ralphwetzel/theonionbox https://3c.gmx.net/mail/client/dereferrer?redirectUrl=https%3A%2F%2F3c.gmx.net%2Fmail%2Fclient%2Fdereferrer%3FredirectUrl%3Dhttps%253A%252F%252Fgithub.com%252Fralphwetzel%252Ftheonionbox
I will check this week and see.
Thanks for your work and sharing.
On 30 December 2015 at 10:49, k0nsl i.am@k0nsl.org wrote:
Good morning to you too Ralph! Thanks for the project; I will try it out later today. Best wishes, -k0nsl
On 12/30/2015 10:36 AM, theonionbox@gmx.com wrote:
Good morning!
I've created a tool to monitor a Tor relay "in action". In the end it's a web interface operating with Tor's ConfigPort data. Currently it's not as powerful as arm... but it definitely looks better ;)!
You can find the tool and some instructions to get it running at GitHub: https://github.com/ralphwetzel/theonionbox <
https://3c.gmx.net/mail/client/dereferrer?redirectUrl=https%3A%2F%2F3c.gmx.n...
I would be very happy if people gave it a try and provide feedback to me, especially in case something fails... which probably might happen!
Greetings,
ralph
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Still giving 403 error - Ups, hier hat sich ein Fehler eingeschlichen...
Fehler-Code: 403
Would love to check it out :) https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail This email has been sent from a virus-free computer protected by Avast. www.avast.com https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail <#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Wed, Dec 30, 2015 at 6:18 AM, ZEROF security@netmajstor.com wrote:
Hi Ralph,
I will first post url again because yours give me 404 error page: https://github.com/ralphwetzel/theonionbox https://3c.gmx.net/mail/client/dereferrer?redirectUrl=https%3A%2F%2F3c.gmx.net%2Fmail%2Fclient%2Fdereferrer%3FredirectUrl%3Dhttps%253A%252F%252Fgithub.com%252Fralphwetzel%252Ftheonionbox
I will check this week and see.
Thanks for your work and sharing.
On 30 December 2015 at 10:49, k0nsl i.am@k0nsl.org wrote:
Good morning to you too Ralph! Thanks for the project; I will try it out later today. Best wishes, -k0nsl
On 12/30/2015 10:36 AM, theonionbox@gmx.com wrote:
Good morning!
I've created a tool to monitor a Tor relay "in action". In the end it's a web interface operating with Tor's ConfigPort data. Currently it's not as powerful as arm... but it definitely looks better ;)!
You can find the tool and some instructions to get it running at GitHub: https://github.com/ralphwetzel/theonionbox <
https://3c.gmx.net/mail/client/dereferrer?redirectUrl=https%3A%2F%2F3c.gmx.n...
I would be very happy if people gave it a try and provide feedback to me, especially in case something fails... which probably might happen!
Greetings,
ralph
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-- http://www.backbox.org http://www.pentester.iz.rs
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
You mean this one: https://github.com/ralphwetzel/theonionbox
It works for me.
On 30/12/2015 12:28, Jon wrote:
Still giving 403 error - Ups, hier hat sich ein Fehler eingeschlichen...
Fehler-Code: 403
Would love to check it out :) https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail This email has been sent from a virus-free computer protected by Avast. www.avast.com https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail <#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Wed, Dec 30, 2015 at 6:18 AM, ZEROF security@netmajstor.com wrote:
Hi Ralph,
I will first post url again because yours give me 404 error page: https://github.com/ralphwetzel/theonionbox https://3c.gmx.net/mail/client/dereferrer?redirectUrl=https%3A%2F%2F3c.gmx.net%2Fmail%2Fclient%2Fdereferrer%3FredirectUrl%3Dhttps%253A%252F%252Fgithub.com%252Fralphwetzel%252Ftheonionbox
I will check this week and see.
Thanks for your work and sharing.
On 30 December 2015 at 10:49, k0nsl i.am@k0nsl.org wrote:
Good morning to you too Ralph! Thanks for the project; I will try it out later today. Best wishes, -k0nsl
On 12/30/2015 10:36 AM, theonionbox@gmx.com wrote:
Good morning!
I've created a tool to monitor a Tor relay "in action". In the end it's a web interface operating with Tor's ConfigPort data. Currently it's not as powerful as arm... but it definitely looks better ;)!
You can find the tool and some instructions to get it running at GitHub: https://github.com/ralphwetzel/theonionbox <
https://3c.gmx.net/mail/client/dereferrer?redirectUrl=https%3A%2F%2F3c.gmx.n...
I would be very happy if people gave it a try and provide feedback to me, especially in case something fails... which probably might happen!
Greetings,
ralph
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-- http://www.backbox.org http://www.pentester.iz.rs
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Clicking on the nk is wrong some way...
By copy and paste the URL, I was able to get the page to not have an error
On Wed, Dec 30, 2015 at 6:28 AM, Jon torance.ca@gmail.com wrote:
Still giving 403 error - Ups, hier hat sich ein Fehler eingeschlichen...
Fehler-Code: 403
Would love to check it out :)
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail This email has been sent from a virus-free computer protected by Avast. www.avast.com https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail <#151f2dc4632b80f6_DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Wed, Dec 30, 2015 at 6:18 AM, ZEROF security@netmajstor.com wrote:
Hi Ralph,
I will first post url again because yours give me 404 error page: https://github.com/ralphwetzel/theonionbox https://3c.gmx.net/mail/client/dereferrer?redirectUrl=https%3A%2F%2F3c.gmx.net%2Fmail%2Fclient%2Fdereferrer%3FredirectUrl%3Dhttps%253A%252F%252Fgithub.com%252Fralphwetzel%252Ftheonionbox
I will check this week and see.
Thanks for your work and sharing.
On 30 December 2015 at 10:49, k0nsl i.am@k0nsl.org wrote:
Good morning to you too Ralph! Thanks for the project; I will try it out later today. Best wishes, -k0nsl
On 12/30/2015 10:36 AM, theonionbox@gmx.com wrote:
Good morning!
I've created a tool to monitor a Tor relay "in action". In the end it's a web interface operating with Tor's ConfigPort data. Currently it's
not
as powerful as arm... but it definitely looks better ;)!
You can find the tool and some instructions to get it running at GitHub: https://github.com/ralphwetzel/theonionbox <
https://3c.gmx.net/mail/client/dereferrer?redirectUrl=https%3A%2F%2F3c.gmx.n...
I would be very happy if people gave it a try and provide feedback to me, especially in case something fails... which probably might happen!
Greetings,
ralph
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-- http://www.backbox.org http://www.pentester.iz.rs
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
So my medium-term signing key expires tomorrow, and Tor notices.log is all up and down about:
Jan 04 19:22:46.000 [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. But OfflineMasterKey is set, so I won't try to load a permanent master identity key is set. You will need to use 'tor --keygen' make a new signing key and certificate.
Now, that's great and all, so I tossed my master_id_public_key and the master_id_secret_key_encrypted into the folder they were originally generated in, which is: /home/[user]/.tor/keys/ed25519.... Turned off Tor, ran "tor --keygen" Gave my password. It generates a new signing_cert and signing_secret_key in the same directory. And now, no matter what I do, Tor keeps giving the same notice over and over again that the keys are expiring.
The documentation for this feature is slightly lacking. So, if anyone knows what I'm doing wrong, that'd be very helpful.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hello,
Let's recap (hope I am not missing something):
a) you make sure master_id_secret_key is available in /home/[user]/.tor/keys b) you run # tor --keygen and provide the correct passphrase c) you *move* the newly generated ed25519_signing_secret_key and ed25519_signing_cert *FROM* /home/[user]/.tor/keys *TO* /var/lib/tor/keys or wherever your Tor datadirectory is (depending on your OS / distro) and reload or restart Tor. You don't need to shut down Tor while you use --keygen, you can only reload (HUP) or restart after you've moved the new key and cert.
and you still get the same notice that the medium term signing key is going to expire soon?
If yes, can you let me know other details about your setup? Do you use a SigningKeyLifetime parameter in your torrc?
Also, the directory doesn't need to be /home/[user]/.tor/keys if you are willing to pass it with --datadirectory argument (Tor will just need write permission in the target folder):
# tor --datadirectory /some/path --keygen (the master_id_secret_key needs to be inside a keys folder in /some/path, eg: /some/path/keys/ed25519_master_id_secret_key).
The new medium term signing key and cert will be saved in the same folder and you have to manually move them to your working Tor's instance datadirectory folder as explained above.
We are working on making this simpler by allowing to manually set the master id secret key path and ask for a different output folder for the created files.
On 1/4/2016 9:53 PM, 12xBTM wrote:
So my medium-term signing key expires tomorrow, and Tor notices.log is all up and down about:
Jan 04 19:22:46.000 [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. But OfflineMasterKey is set, so I won't try to load a permanent master identity key is set. You will need to use 'tor --keygen' make a new signing key and certificate.
Now, that's great and all, so I tossed my master_id_public_key and the master_id_secret_key_encrypted into the folder they were originally generated in, which is: /home/[user]/.tor/keys/ed25519.... Turned off Tor, ran "tor --keygen" Gave my password. It generates a new signing_cert and signing_secret_key in the same directory. And now, no matter what I do, Tor keeps giving the same notice over and over again that the keys are expiring.
The documentation for this feature is slightly lacking. So, if anyone knows what I'm doing wrong, that'd be very helpful.
Now I'm getting permission denied, still out-dated key, and missing master_id_secret_key errors, which are unsurprisingly fatal.
Jan 04 22:41:33.000 [warn] Could not open "/var/lib/tor/keys/ed25519_signing_secret_key": Permission denied Jan 04 22:41:33.000 [notice] It looks like I need to generate and sign a new medium-term signing key, because I don't have one. To do that, I need to load the permanent master identity key. Jan 04 22:41:33.000 [warn] We needed to load a secret key from /var/lib/tor/keys/ed25519_master_id_secret_key, but couldn't find it. Did you forget to copy it over when you copied the rest of the signing key material? Jan 04 22:41:33.000 [warn] Can't load master identity key; OfflineMasterKey is set. Jan 04 22:41:33.000 [err] Error initializing keys; exiting
Which is funny, because the [user] has permission over signing_secret_key, and the ed25519_master_id_secret_key is totally in /var/lib/tor/keys/.
At this point, I just disabled OfflineMasterKeys because there's just not enough information available for me to go about this. If you know of a way to completely regenerate signing keys, master keys, and whatever other keys I need besides the one for my fingerprint, that'd be nice, because I'm fairly certain things are completely screwed up now since Tor can't find or access the the signing_secret_key or master_id_secret_key. I'll be sure to implement that key regeneration in a week or so when I can correct the keys on this node, until then, I'll leave this exit node off until I'm sure it's using valid keys, because there's no point in having a faulty exit node.
secret_id_key, secret_onion_key, and secret_onion_key_ntor weren't touched (I think). So it's the others keys I need to fix.
I'll try this OfflineMasterKeys thing when more operational information is released about it. Because, not only do I not know what I'm doing, I don't even know what it does at this point. --keygen on the master key and writing it automatically to a [user] directory made it property of [user] instead of debian-tor. Also, what is master_id_secret_key_encrypted used for if Tor says it can't use an encrypted master_id_secret_key?
I'm absolutely a linux noob, and I know that's not helping.
On 4.1.16 16:09, s7r wrote:
Hello,
Let's recap (hope I am not missing something):
a) you make sure master_id_secret_key is available in /home/[user]/.tor/keys b) you run # tor --keygen and provide the correct passphrase c) you *move* the newly generated ed25519_signing_secret_key and ed25519_signing_cert *FROM* /home/[user]/.tor/keys *TO* /var/lib/tor/keys or wherever your Tor datadirectory is (depending on your OS / distro) and reload or restart Tor. You don't need to shut down Tor while you use --keygen, you can only reload (HUP) or restart after you've moved the new key and cert.
and you still get the same notice that the medium term signing key is going to expire soon?
If yes, can you let me know other details about your setup? Do you use a SigningKeyLifetime parameter in your torrc?
Also, the directory doesn't need to be /home/[user]/.tor/keys if you are willing to pass it with --datadirectory argument (Tor will just need write permission in the target folder):
# tor --datadirectory /some/path --keygen (the master_id_secret_key needs to be inside a keys folder in /some/path, eg: /some/path/keys/ed25519_master_id_secret_key).
The new medium term signing key and cert will be saved in the same folder and you have to manually move them to your working Tor's instance datadirectory folder as explained above.
We are working on making this simpler by allowing to manually set the master id secret key path and ask for a different output folder for the created files.
On 1/4/2016 9:53 PM, 12xBTM wrote:
So my medium-term signing key expires tomorrow, and Tor notices.log is all up and down about:
Jan 04 19:22:46.000 [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. But OfflineMasterKey is set, so I won't try to load a permanent master identity key is set. You will need to use 'tor --keygen' make a new signing key and certificate.
Now, that's great and all, so I tossed my master_id_public_key and the master_id_secret_key_encrypted into the folder they were originally generated in, which is: /home/[user]/.tor/keys/ed25519.... Turned off Tor, ran "tor --keygen" Gave my password. It generates a new signing_cert and signing_secret_key in the same directory. And now, no matter what I do, Tor keeps giving the same notice over and over again that the keys are expiring.
The documentation for this feature is slightly lacking. So, if anyone knows what I'm doing wrong, that'd be very helpful.
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 1/5/2016 12:13 AM, 12xBTM wrote:
Now I'm getting permission denied, still out-dated key, and missing master_id_secret_key errors, which are unsurprisingly fatal.
Jan 04 22:41:33.000 [warn] Could not open "/var/lib/tor/keys/ed25519_signing_secret_key": Permission denied Jan 04 22:41:33.000 [notice] It looks like I need to generate and sign a new medium-term signing key, because I don't have one. To do that, I need to load the permanent master identity key. Jan 04 22:41:33.000 [warn] We needed to load a secret key from /var/lib/tor/keys/ed25519_master_id_secret_key, but couldn't find it. Did you forget to copy it over when you copied the rest of the signing key material? Jan 04 22:41:33.000 [warn] Can't load master identity key; OfflineMasterKey is set. Jan 04 22:41:33.000 [err] Error initializing keys; exiting
Which is funny, because the [user] has permission over signing_secret_key, and the ed25519_master_id_secret_key is totally in /var/lib/tor/keys/.
Yes but for security reasons we usually run Tor as a different user than [user]. In Debian for example it's debian-tor in FreeBSD is tor_
So: # chown -R debian-tor:debian-tor /var/lib/tor/keys/*
if you are using debian, if not substitute debian-tor with the user running Tor on your system.
Retry the steps in my previous email with this additional step finally and see what happens.
At this point, I just disabled OfflineMasterKeys because there's just not enough information available for me to go about this. If you know of a way to completely regenerate signing keys, master keys, and whatever other keys I need besides the one for my fingerprint, that'd be nice, because I'm fairly certain things are completely screwed up now since Tor can't find or access the the signing_secret_key or master_id_secret_key. I'll be sure to implement that key regeneration in a week or so when I can correct the keys on this node, until then, I'll leave this exit node off until I'm sure it's using valid keys, because there's no point in having a faulty exit node.
secret_id_key, secret_onion_key, and secret_onion_key_ntor weren't touched (I think). So it's the others keys I need to fix.
I'll try this OfflineMasterKeys thing when more operational information is released about it. Because, not only do I not know what I'm doing, I don't even know what it does at this point. --keygen on the master key and writing it automatically to a [user] directory made it property of [user] instead of debian-tor. Also, what is master_id_secret_key_encrypted used for if Tor says it can't use an encrypted master_id_secret_key?
I'm absolutely a linux noob, and I know that's not helping.
Why do you use offline master key in this case and not simply allow Tor to work with the defaults? Usually the offline master key functionality is for those who have time to attend to the relays and periodically renew keys and also know how to do it.
OfflineMasterKey needs no more information than it already provides: tells Tor never try to generate or load master id secret key.
Hint: when you run # tor --keygen in console the command is run as [user] and files are stored in home/[user]/.tor/keys and are owned by [user].
The Tor instance runs under debian-tor, so debian-tor needs access to /var/lib/tor . Of course [user] also has access in /var/lib/tor because it's above debian-tor most probably in your setup. But when you move the signing cert and medium term signing key from /home/[user]/.tor/keys to /var/lib/tor/keys they are still owned by [user] and debian-tor (Tor instance) can't access them.
Okay, so fixing the permissions fixed the whole problem. At least until it asks where the master_id_secret_key is again when it needs a newer medium-term signing_secret_key.
I know why debian-tor and [user] are separate, I'm just saying that having the [user] move debian-tor files around can make them [user] files now. Particularly when moving them back online.
So, now that OfflineMasterKey is back up and running, what should be the contents of my key folder during normal operation? And, what should be the rough procedure for generating a new key, and putting things where they need to be for Tor to get the new key in, the default, 30 days?
What is the purpose of master_id_public_key, master_id_secret_key, and master_id_secret_key_encrypted?
Remember how tor --keygen was generating keys in [user]/.tor/keys? Yeah, it stopped doing that, even though I didn't specific a datadirectory. I'd say it was generating it inside /var/lib/tor/keys, but I can't be certain. Because now I have two maybe-different sets of master keys, the keys that probably never left /var/lib/tor/keys, which are master_id_public_key, and master_id_secret_key, and the keys that came from [user]/.tor/keys, which are master_id_public_key, and master_id_secret_key_encrypted. Again, how do these fit into the normal operation of /var/lib/tor/keys/ and key regeneration?
Thanks for you help so far with this.
On 4.1.16 18:29, s7r wrote:
On 1/5/2016 12:13 AM, 12xBTM wrote:
Now I'm getting permission denied, still out-dated key, and missing master_id_secret_key errors, which are unsurprisingly fatal.
Jan 04 22:41:33.000 [warn] Could not open "/var/lib/tor/keys/ed25519_signing_secret_key": Permission denied Jan 04 22:41:33.000 [notice] It looks like I need to generate and sign a new medium-term signing key, because I don't have one. To do that, I need to load the permanent master identity key. Jan 04 22:41:33.000 [warn] We needed to load a secret key from /var/lib/tor/keys/ed25519_master_id_secret_key, but couldn't find it. Did you forget to copy it over when you copied the rest of the signing key material? Jan 04 22:41:33.000 [warn] Can't load master identity key; OfflineMasterKey is set. Jan 04 22:41:33.000 [err] Error initializing keys; exiting
Which is funny, because the [user] has permission over signing_secret_key, and the ed25519_master_id_secret_key is totally in /var/lib/tor/keys/.
Yes but for security reasons we usually run Tor as a different user than [user]. In Debian for example it's debian-tor in FreeBSD is tor_
So: # chown -R debian-tor:debian-tor /var/lib/tor/keys/*
if you are using debian, if not substitute debian-tor with the user running Tor on your system.
Retry the steps in my previous email with this additional step finally and see what happens.
At this point, I just disabled OfflineMasterKeys because there's just not enough information available for me to go about this. If you know of a way to completely regenerate signing keys, master keys, and whatever other keys I need besides the one for my fingerprint, that'd be nice, because I'm fairly certain things are completely screwed up now since Tor can't find or access the the signing_secret_key or master_id_secret_key. I'll be sure to implement that key regeneration in a week or so when I can correct the keys on this node, until then, I'll leave this exit node off until I'm sure it's using valid keys, because there's no point in having a faulty exit node.
secret_id_key, secret_onion_key, and secret_onion_key_ntor weren't touched (I think). So it's the others keys I need to fix.
I'll try this OfflineMasterKeys thing when more operational information is released about it. Because, not only do I not know what I'm doing, I don't even know what it does at this point. --keygen on the master key and writing it automatically to a [user] directory made it property of [user] instead of debian-tor. Also, what is master_id_secret_key_encrypted used for if Tor says it can't use an encrypted master_id_secret_key?
I'm absolutely a linux noob, and I know that's not helping.
Why do you use offline master key in this case and not simply allow Tor to work with the defaults? Usually the offline master key functionality is for those who have time to attend to the relays and periodically renew keys and also know how to do it.
OfflineMasterKey needs no more information than it already provides: tells Tor never try to generate or load master id secret key.
Hint: when you run # tor --keygen in console the command is run as [user] and files are stored in home/[user]/.tor/keys and are owned by [user].
The Tor instance runs under debian-tor, so debian-tor needs access to /var/lib/tor . Of course [user] also has access in /var/lib/tor because it's above debian-tor most probably in your setup. But when you move the signing cert and medium term signing key from /home/[user]/.tor/keys to /var/lib/tor/keys they are still owned by [user] and debian-tor (Tor instance) can't access them. _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays@lists.torproject.org
-
12xBTM -
Bernard Tyers -
Jon -
k0nsl -
s7r -
theonionbox＠gmx.com -
ZEROF