Hi folks, I’ve recently joined the Tor Project and I have been running a non exit relay for a few days. I’m also a Puppet user and, more in general, I try to make deploying applications on the servers I administer as easy as possibile, Tor included. I think Tor documentation to install on a Debian server is quite good, but I still prefer to have Puppet doing that for me, and I’m quite sure every Puppet user out there would think the same. This is the work-in-progress version of the module I’m currently using to manage my relay: https://github.com/shaftoe/puppet-tor/tree/fixes I’m open to any feedback on how to improve it and eventually publish it to the Puppet forge (make it easier for other Puppet users to use it); maybe adding some decent disclaimer on top of the README? I can also drop the whole idea if someone convince me is a bad one... -- Alexander Fortin http://about.me/alexanderfortin
Hi Alexander, thanks for starting this. bigger relay operators running multiple servers with many nodes will probably like this (just saying 'MyFamily' updates ;) Which brings me to my first question: Does the module support running multiple tor instances on a single server? This is something that probably every major relay operator is doing to cope with tor's inability to scale well across multiple cpu cores.
On 15. Juni 2014 at 14:41:24, Nusenu (bm-2d8wmevggvy76je1wxnpfo8srpzt5yghes@bitmessage.ch) wrote:
Hi Alexander,
thanks for starting this.
bigger relay operators running multiple servers with many nodes will probably like this (just saying 'MyFamily' updates ;)
Sorry, still quite new here, the MyFamily concept has yet to come in my knowledge base :)
Which brings me to my first question:
Does the module support running multiple tor instances on a single server?
No. Or better, not yet.
This is something that probably every major relay operator is doing to cope with tor's inability to scale well across multiple cpu cores.
I started this mainly as a personal project, just because I wanted to deploy a Tor relay on a already “puppetized” VPS I have, then I got some feedback on #tor about how I was doing it wrong, so I thought it was a good idea to spend a little more time to make it available for a general use. I’ll try now to understand what’s involved in having multiple instances running on the same node, but I guess there’s the need for a radical different approach (i.e. not following https://www.torproject.org/docs/debian.html.en#ubuntu as I did for building the module in the first place) -- Alexander Fortin http://about.me/alexanderfortin
I’ll try now to understand what’s involved in having multiple instances running on the same node, but I guess there’s the need for a radical different approach (i.e. not following https://www.torproject.org/docs/debian.html.en#ubuntu as I did for building the module in the first place)
see https://www.torservers.net/wiki/setup/server#multiple_tor_processes for a start.
Did you take a look at the existing projects? https://github.com/search?q=tor+puppet Maybe you should merge your project with one of the existing ones? Some things I would do/change: * add a license ohterwise we can't contribute * colorize the examples in the readme (```puppet) * add a modulefile so people can use librarian-puppet etc. * add tests Regards Philipp On 15.06.2014 13:31, Alexander Fortin wrote:
Hi folks,
I’ve recently joined the Tor Project and I have been running a non exit relay for a few days.
I’m also a Puppet user and, more in general, I try to make deploying applications on the servers I administer as easy as possibile, Tor included.
I think Tor documentation to install on a Debian server is quite good, but I still prefer to have Puppet doing that for me, and I’m quite sure every Puppet user out there would think the same.
This is the work-in-progress version of the module I’m currently using to manage my relay:
https://github.com/shaftoe/puppet-tor/tree/fixes
I’m open to any feedback on how to improve it and eventually publish it to the Puppet forge (make it easier for other Puppet users to use it); maybe adding some decent disclaimer on top of the README? I can also drop the whole idea if someone convince me is a bad one...
-- Alexander Fortin http://about.me/alexanderfortin _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Did you take a look at the existing projects?
https://github.com/search?q=tor+puppet
Maybe you should merge your project with one of the existing ones?
Is anyone at torservers & partners or anyone else using puppet to manage multiple relays and could share their experience? https://www.torservers.net/partners.html
Hi We are not using puppet but a selfmade script. On 2014-06-15 17:22, Nusenu wrote:
Did you take a look at the existing projects?
https://github.com/search?q=tor+puppet
Maybe you should merge your project with one of the existing ones? Is anyone at torservers & partners or anyone else using puppet to manage multiple relays and could share their experience?
https://www.torservers.net/partners.html
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 15. Juni 2014 at 15:56:29, Philipp Borgers (borgers@mi.fu-berlin.de) wrote:
Did you take a look at the existing projects?
https://github.com/search?q=tor+puppet
Maybe you should merge your project with one of the existing ones?
Yeah, but it’s usually easier said then done. I had a look on the forge to see if there was something suitable, but couldn’t find. As for GitHub, there are 3 pages of them. I can spend some time to go through them and see if there’s one fitting my use case, then get in touch with the developer and see if it’s interested in collaboration, but usually it’s much much faster for me to write my own, test it locally, and ship it to my puppet master. As I already said, this was meant to be an easy way for me to start with Tor on a server I had, I didn’t think about making it suitable for public usage at that time. Anyway, I’ll try to follow the advise and see if there’s some other module I could merge into, but it will take some time.
Some things I would do/change:
* add a license ohterwise we can't contribute
True that. I’ll go for the same Tor is using, I guess GPL
* colorize the examples in the readme (```puppet)
Right
* add a modulefile so people can use librarian-puppet etc.
Right. Also, puppetlabs/apt module is actually already a dependency (only if you set a certain parameter when declaring the class though)
* add tests
Also can be done. I’m still not 100% convinced by the whole TDD idea for Puppet manifests, but I understand it will make it easier to adopt, so no big deal to add them. @all, thanks for your feedback, very appreciated. -- Alexander Fortin http://about.me/alexanderfortin
Hi Alexander, On 06/15/2014 01:31 PM, Alexander Fortin wrote:
This is the work-in-progress version of the module I’m currently using to manage my relay: https://github.com/shaftoe/puppet-tor/tree/fixes
Thank you for this. I've come across several Puppet and Ansible recipes for Tor over time, but sadly have not found time to properly review or even use them for our own servers yet. https://github.com/shaftoe/puppet-tor/blob/fixes/manifests/apt.pp key => '886DDD89' You should never rely on short key IDs for anything. They can be forged within minutes. When you look at https://www.torproject.org/docs/debian.html.en , it fetches the key using the short key ID, but only imports a key that matches the whole fingerprint. I found keys.gnupg.net to be unreliable sometimes, it would be good to have some fallback options. Tor generates key material, the default location is /var/lib/tor. I always wondered if it was possible to pregenerate the necessary files locally, and then push them to the relays, where /var/lib/tor is on a ramdisk. Personally, I think it would be great to not only have puppet modules spread out somewhere across the Internet, but a full-fledged guide/wizard that makes it easy for people to locally configure relays without knowing anything about Tor configuration options. In my dream world, it would not only support Debian: Right now, most of the Tor network runs on Debian, which is not ideal. We need more *BSD and Solaris! And FreeDOS! :) -- Moritz Bartl https://www.torservers.net/
On Mon, Jun 16, 2014 at 4:40 AM, Moritz Bartl <moritz@torservers.net> wrote:
Thank you for this. I've come across several Puppet and Ansible recipes for Tor over time, but sadly have not found time to properly review or even use them for our own servers yet.
Thank you for the feedback. I'm new in the Tor land but I think a well crafted CM module could definitely help the adoption, so I'm happy to see there's some discussion here.
https://github.com/shaftoe/puppet-tor/blob/fixes/manifests/apt.pp key => '886DDD89'
You should never rely on short key IDs for anything. They can be forged within minutes. When you look at https://www.torproject.org/docs/debian.html.en , it fetches the key using the short key ID, but only imports a key that matches the whole fingerprint.
Ok
I found keys.gnupg.net to be unreliable sometimes, it would be good to have some fallback options.
Maybe add this fallback options to https://www.torproject.org/docs/debian.html.en too?
Tor generates key material, the default location is /var/lib/tor. I always wondered if it was possible to pregenerate the necessary files locally, and then push them to the relays, where /var/lib/tor is on a ramdisk.
I've been told on #tor that the secret_id key is more to be thought as a 'state' more then as a configuration, and if a Tor relay has to be moved on a different server, it's best practice to just start a new one from fresh. Or better said, there's no actual need of keeping a fingerprint consistent.
Personally, I think it would be great to not only have puppet modules spread out somewhere across the Internet, but a full-fledged guide/wizard that makes it easy for people to locally configure relays without knowing anything about Tor configuration options. In my dream world, it would not only support Debian: Right now, most of the Tor network runs on Debian, which is not ideal. We need more *BSD and Solaris! And FreeDOS! :)
Yeah, I share the dream too :) It should be as easy as include 'tor' to install a relay with the most common configurations default (in my case, a non exit relay), regardless of the platform. -- http://about.me/alexanderfortin
On 16. Juni 2014 at 08:56:20, Alexander Fortin (alexander.fortin@gmail.com) wrote:
On Mon, Jun 16, 2014 at 4:40 AM, Moritz Bartl wrote:
You should never rely on short key IDs for anything. They can be forged within minutes. When you look at https://www.torproject.org/docs/debian.html.en , it fetches the key using the short key ID, but only imports a key that matches the whole fingerprint.
Ok
Done. There's a bug on the latest version of puppetlabs/apt (1.5.0) that’s currently limiting the key name to 8 or 16 digits: https://github.com/puppetlabs/puppetlabs-apt/pull/314 so I’m currently forcing the dependency to version 1.4.2 I've also added missing LICENSE and Modulefile files (for automatic dependency resolution via librarian-puppet or similar). I’m going to add the missing RSpec files in the next days.
I found keys.gnupg.net to be unreliable sometimes, it would be good to have some fallback options.
Maybe add this fallback options to https://www.torproject.org/docs/debian.html.en too?
I also checked the latest version of the apt module but unfortunately there’s no default mechanism to fall back in case of a non responsive default GPG server. Anyway, the worst case scenario is that Puppet agent will fail because of the timeout (i.e. not installing anything until the key is fetched), so security should not be compromised. Latest version: https://github.com/shaftoe/puppet-tor/tree/fixes -- Alexander Fortin http://about.me/alexanderfortin
On Sunday, June 15, 2014, Moritz Bartl <moritz@torservers.net> wrote:
Personally, I think it would be great to not only have puppet modules spread out somewhere across the Internet, but a full-fledged guide/wizard that makes it easy for people to locally configure relays without knowing anything about Tor configuration options.
+1; this would be great for Tor Cloud users.
In my dream world, it would not only support Debian: Right now, most of the Tor network runs on Debian, which is not ideal. We need more *BSD and Solaris! And FreeDOS! :)
Why is this not ideal? I'm not following. Also, do you mean Debian or Debian-like? If the latter, Tor Cloud (Ubuntu) probably accounts for a fair bit of that inbalance.
On 06/17/2014 02:49 AM, Alex Jordan wrote:
In my dream world, it would not only support Debian: Right now, most of the Tor network runs on Debian, which is not ideal. We need more *BSD and Solaris! And FreeDOS! :) Why is this not ideal? I'm not following. Also, do you mean Debian or Debian-like? If the latter, Tor Cloud (Ubuntu) probably accounts for a fair bit of that inbalance.
If there's a problem with one implementation, an attacker can easily take over the parts that are based on that implementation. Diversity of relay operation systems helps against single points of failure (like the Debian OpenSSL issue, or even the 1.x Heartbleed). -- Moritz Bartl https://www.torservers.net/
On Sun, Jun 15, 2014 at 7:31 AM, Alexander Fortin <alexander.fortin@gmail.com> wrote:
I’ve recently joined the Tor Project and I have been running a non exit relay for a few days.
I’m also a Puppet user and, more in general, I try to make deploying applications on the servers I administer as easy as possibile, Tor included.
I think Tor documentation to install on a Debian server is quite good, but I still prefer to have Puppet doing that for me, and I’m quite sure every Puppet user out there would think the same.
Hey, thanks for doing this! I have kinda wanted to put something similar together for a while but haven't had the time. Here are some thoughts, in no particular order: Why do you disable directory mirroring? It's my understanding that this should basically always be on. It would be nice if exit-relay mode enabled an HTTP "exit notice" as described at https://blog.torproject.org/blog/tips-running-exit-node-minimal-harassment. Tor relays get pounded on by the script kiddies -- a degree of hardening is appropriate. I don't know if there are any stock Puppet "tighten security" modules but these are the things that I remember having done to mine. Note that my relays serve no other traffic and have no non-root user accounts; some of these configuration choices may be inappropriate for multi-use machines. - install fail2ban and ufw; firewall incoming traffic to ports other than 9001, 9030, and 22 (ssh) (I don't think the marginal benefit of moving ssh to a nonstandard port is worth the hassle). - sshd_config configuration tuning: beware that this will lock out any user account with no SSH authorized_keys! Protocol 2 UsePrivilegeSeparation yes PermitRootLogin without-password PasswordAuthentication no ChallengeResponseAuthenticatio n no HostbasedAuthentication no IgnoreRhosts yes StrictModes yes X11Forwarding no Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com - install logcheck and nullmailer; set /etc/nullmailer/adminaddr and /etc/nullmailer/remotes to values assigned in Puppet configuration; symlink /etc/nullmailer/helohost to /etc/hostname. (ufw and sshd will emit a great deal of chatter due to people knocking on the machine. I have custom ignore.d.server files to shut them up - basically I've set it to mail me only on *successful* logins. Let me know if you want 'em.) - install unattended-upgrades and configure it to auto-upgrade everything. Unfortunately, the unattended-upgrades documentation is at pains to avoid explaining how to do that; this is what I have in /etc/apt/apt.conf.d/50unattended-upgrades: Unattended-Upgrade::Origins-Pattern { "o=Debian,a=stable"; "o=Debian,a=stable-updates"; "o=TorProject,a=stable"; }; Unattended-Upgrade::Remove-Unused-Dependencies "true"; Unattended-Upgrade::Automatic-Reboot "true"; Unattended-Upgrade::Mail "root" Unattended-Upgrade::MailOnlyOnError "true"; - I'd *like* to recommend pulling libssl from testing, but right now that also means upgrading libc, which seems unwise. - I'd also like to recommend a kernel enhanced-security module, but I was unable to get SELinux to the point where I could turn enforcement on without breaking boot (and when I finally gave up and purged it, the relay I was testing that on sped up by 15%!), AppArmor seems too half-assed to actually be worth it, and Debian doesn't have grsec kernel packages. zw
On 17. Juni 2014 at 23:56:43, Zack Weinberg (zackw@cmu.edu) wrote:
Why do you disable directory mirroring? It's my understanding that this should basically always be on.
Not sure why, I think at the beginning I wanted to use the ‘minimal’ config, and I didn’t even now about directory services, but please keep in mind I’m still missing the big Tor picture and many things are new to me That’s actually one of the reasons for this thread: if you think such and such configuration should be defaulted, or available as a custom parameter, well, please say so :)
It would be nice if exit-relay mode enabled an HTTP "exit notice" as described at https://blog.torproject.org/blog/tips-running-exit-node-minimal-harassment.
Point 4 says: "If you run your DirPort on port 80”. Should it be enabled only when DirPort = 80?
Tor relays get pounded on by the script kiddies -- a degree of hardening is appropriate. I don't know if there are any stock Puppet "tighten security" modules but these are the things that I remember having done to mine. Note that my relays serve no other traffic and have no non-root user accounts; some of these configuration choices may be inappropriate for multi-use machines.
I don’t know of any such ‘security silver bullet module’ I am afraid :) About the security enhancements, they are definitely interesting, but to me seems they are out of the scope of the ‘install relay’ Puppet module itself, and also against the usual modular approach of Puppet modules. First, my understanding is that having a node with only Tor running is suggested, but not mandatory, but in any case, those enhancements are more suitable for a separate 'tor-security’ like module that one may or may not be interested in. -- Alexander Fortin http://about.me/alexanderfortin
On Wed, Jun 18, 2014 at 3:01 AM, Alexander Fortin <alexander.fortin@gmail.com> wrote:
On 17. Juni 2014 at 23:56:43, Zack Weinberg (zackw@cmu.edu) wrote:
It would be nice if exit-relay mode enabled an HTTP "exit notice" as described at https://blog.torproject.org/blog/tips-running-exit-node-minimal-harassment.
Point 4 says: "If you run your DirPort on port 80”. Should it be enabled only when DirPort = 80?
Best practice as I understand it is that you should have an exit notice on all exit relays. What I'm not sure of is whether "DirPort 80 + DirPortFrontPage" is the recommended way to accomplish that. The CMU Tor exit uses a separate lighttpd install, I think primarily because we didn't know about DirPortFrontPage when we set it up. I can make a case either way - less software = less attack surface; separate install = compartmentalization. As long as we're talking about exits, a nice touch would be to include the reduced exit policy as an option ( https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy ); the ideal would be a three-way choice of not an exit / wide-open exit / reduced exit (no email or BitTorrent) plus a place to add local exit rules.
Tor relays get pounded on by the script kiddies -- a degree of hardening is appropriate. I don't know if there are any stock Puppet "tighten security" modules [...]
I don’t know of any such ‘security silver bullet module’ I am afraid :)
I poked around in the Puppet module archive and found some; I'm not sure how good they are, though.
About the security enhancements, they are definitely interesting, but to me seems they are out of the scope of the ‘install relay’ Puppet module itself, and also against the usual modular approach of Puppet modules. First, my understanding is that having a node with only Tor running is suggested, but not mandatory, but in any case, those enhancements are more suitable for a separate 'tor-security’ like module that one may or may not be interested in.
Yeah, I think if I were building this (regrettably, I don't have time to help more than I already have) there would be a "just install the software with configuration X" module, and then a "image this entire machine as a Tor relay" module that set up everything one might want. zw
On 18. Juni 2014 at 16:26:38, Zack Weinberg (zackw@cmu.edu) wrote:
Best practice as I understand it is that you should have an exit notice on all exit relays. What I'm not sure of is whether "DirPort 80 + DirPortFrontPage" is the recommended way to accomplish that. The CMU Tor exit uses a separate lighttpd install, I think primarily because we didn't know about DirPortFrontPage when we set it up. I can make a case either way - less software = less attack surface; separate install = compartmentalization.
I understand the 'less software’ benefit; I’m currently reading https://en.wikipedia.org/wiki/Compartmentalization_(information_security) but still not sure if I understand correctly the reference to the ‘compartmentalization' in this case.
As long as we're talking about exits, a nice touch would be to include the reduced exit policy as an option ( https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy ); the ideal would be a three-way choice of not an exit / wide-open exit / reduced exit (no email or BitTorrent) plus a place to add local exit rules.
Yes, makes sense, and should not be too complex to implement, I’ll try to add this and get back here for some review. Thanks for the feedback -- Alexander Fortin http://about.me/alexanderfortin
On 18. Juni 2014 at 19:49:26, Alexander Fortin (alexander.fortin@gmail.com) wrote:
Yes, makes sense, and should not be too complex to implement, I’ll try to add this and get back here for some review. Thanks for the feedback
https://github.com/shaftoe/puppet-tor/tree/fixes#exit-relays-policies -- Alexander Fortin http://about.me/alexanderfortin
On Wed, Jun 18, 2014 at 1:49 PM, Alexander Fortin <alexander.fortin@gmail.com> wrote:
On 18. Juni 2014 at 16:26:38, Zack Weinberg (zackw@cmu.edu) wrote:
Best practice as I understand it is that you should have an exit notice on all exit relays. What I'm not sure of is whether "DirPort 80 + DirPortFrontPage" is the recommended way to accomplish that. The CMU Tor exit uses a separate lighttpd install, I think primarily because we didn't know about DirPortFrontPage when we set it up. I can make a case either way - less software = less attack surface; separate install = compartmentalization.
I understand the 'less software’ benefit; I’m currently reading https://en.wikipedia.org/wiki/Compartmentalization_(information_security) but still not sure if I understand correctly the reference to the ‘compartmentalization' in this case.
If the process listening on port 80 is the Tor process, then any vulnerability in the HTTP service it presents to port 80 can be exploited for a direct attack on the relay itself. If port 80 service is provided by a separate program (e.g. lighttpd) running under a different user ID, then an exploit of *that* program may not be able to affect the relay. That's all I meant. (The Wikipedia article is talking about a related thing, but not really the same.) If you turn DirPort on at all, that exposes Tor's built-in HTTP server to the Internet -- perhaps on a nonstandard port, but still -- so I'm not sure the compartmentalization is really buying anything in this case. zw
On Wed, Jun 18, 2014 at 9:34 PM, Zack Weinberg <zackw@cmu.edu> wrote:
If the process listening on port 80 is the Tor process, then any vulnerability in the HTTP service it presents to port 80 can be exploited for a direct attack on the relay itself. If port 80 service is provided by a separate program (e.g. lighttpd) running under a different user ID, then an exploit of *that* program may not be able to affect the relay. That's all I meant. (The Wikipedia article is talking about a related thing, but not really the same.)
Yes, clear now, thanks for the explanation. -- http://about.me/alexanderfortin
On 17. Juni 2014 at 23:56:43, Zack Weinberg (zackw@cmu.edu) wrote:
Tor relays get pounded on by the script kiddies -- a degree of hardening is appropriate
I was thinking a little more about this point, and I’m wondering how running a Tor relay is increasing the likeliness of being hit by script kiddies attacks. I mean, usually I just consider *any* server with a public IP already open to such kind of attacks. -- Alexander Fortin http://about.me/alexanderfortin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 06/17/2014 02:09 PM, Zack Weinberg wrote:
Tor relays get pounded on by the script kiddies -- a degree of hardening is appropriate. I don't know if there are any stock Puppet "tighten security" modules but these are the things that I remember
I don't have any Puppet modules or Chef recipes, but I do have a Git repo of some basic hardened Ubuntu config files (v12.04 and v14.04) that might be a good place to start: https://github.com/virtadpt/ubuntu-hardening
- install fail2ban and ufw; firewall incoming traffic to ports other than 9001, 9030, and 22 (ssh) (I don't think the marginal benefit of moving ssh to a nonstandard port is worth the hassle).
I do both on some of my machines and it's helped a lot. It definitely cut down on the "portscan the box, resume pounding on SSH like woodpeckers on meth."
- install logcheck and nullmailer; set /etc/nullmailer/adminaddr and /etc/nullmailer/remotes to values assigned in Puppet configuration; symlink /etc/nullmailer/helohost to /etc/hostname. (ufw and sshd will emit a great deal of chatter due to people knocking on the machine. I have custom ignore.d.server files to shut them up - basically I've set it to mail me only on *successful* logins. Let me know if you want 'em.)
I'm curious; never used nullmailer before though I do use logcheck pretty heavily.
- install unattended-upgrades and configure it to auto-upgrade everything. Unfortunately, the unattended-upgrades documentation is at pains to avoid explaining how to do that; this is what I have in
`sudo dpkg-reconfigure -plow unattended-upgrades` - -- The Doctor [412/724/301/703] [ZS] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ Sometimes the only thing more dangerous than a question is an answer. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTohRaAAoJED1np1pUQ8RksAEP/i+6F5xN7c5igxBauTVO8wQ9 sDh6R3RHjWZeKDLbFruM4JuEE/GpV9HrugNelx7rkE3XxXw/yeanExlrFKh045sw jU1PiHYbSx0kpSi3BBWpf3ty2abUf8dPA0iMX+/S+cfG3XKw2/Aq4FRqjZ1OanXV GMbn2y75dEDihD8EcFaWhYBaWWZH4un2mMpf++lrUGaAdszD954/gSytFcZva/5E q/aZm+cumOtBrxq/XpokxlPgLtXau2q51RD/8J0PFTIHbC8jyXpnIrug5jxN9K9a kyZg1Qkfqqr9Q05U4sMeiAwDxeRQH2plpc/AloDXtcgxPTu932GhXcnYDY9e7wY4 WWEvGDZdaG2Kzm4XBote/vd6YcpCwNNC8bO3NdGCkEZPfEO9jsYXVtsNH0RdbT6s ZaNVO1hIeBxmPlNa1PlKoHY8pq3rfL7qn4OcZN2u7dc+ciu31Ccr8q0KSgOL5JTR DiLygwQQ72akU8CUjdkHhcNEO1CHL3htq0wglXeg4bw+K547oWJkWrsPkEanVuEq p5P0Dt1Mk6lktwmm93Rxpx2LBuAxlE11BSn+1zYx2JhguWBinIhKF9445x77g0xJ dic3EZUR+ds7n4/OjPk+9xtGw/vKlm12X4/8r94VlqRcoubRnAQFlKkNyZ0ABmYX bmsGL/zY2yoTanTu9b+K =DBov -----END PGP SIGNATURE-----
participants (9)
-
Alex Jordan -
Alexander Fortin -
I -
Moritz Bartl -
Nusenu -
Philipp Borgers -
The Doctor -
Tyler Durden -
Zack Weinberg