- tor-relays - lists.torproject.org

Anyone else getting these? - Fwd: Tor Survey
by Tor Relays at brwyatt.net 12 Jan '12

12 Jan '12

I just got this sent to me, not sure if it is legit or not. I'm going to assume the worst for now, thought I'd send it out here for discussion and as a heads up for anyone who hasn't yet gotten one of these. I'm hesitant to run anything from someone wanting to do a "study" on Tor Relays. Message forwarded below. -------- Original Message -------- Subject: Tor Survey Date: Wed, 11 Jan 2012 11:47:35 +0100 (CET) From: Marco Valerio Barbera <barbera(a)dsi.uniroma1.it> To: tor(a)brwyatt.net Dear Tor Relay Administrator, my name is Marco Valerio Barbera, I am a PhD student in Computer Science at La Sapienza University of Rome and I am currently doing a research study on the security of the Tor Network in collaboration with Angelos Keromytis, head of the Network Security Lab at Columbia University. You are receiving this message because your e-mail address is associated to the Tor Relay(s) with nickname(s) and address(es): brwyatt1 96.226.232.75 It has recently been discovered a new DoS attack that could allow an adversary to stop one or more Tor Relays from participating and providing service to the Tor Network. This kind of attack poses a potential threat to the hundreds of thousands of users around the globe that use Tor every day. For instance, an adversary may be able to shut down a substantial part of the Tor Network, forcing users to surf the web in a traceable way. In an even worse scenario, an adversary may attract a big part of the data flowing through the Tor Network to one or more malicious Tor Relays that could, thus, cooperate in deanonymizing Tor traffic without being noticed by the users. The aim of our study is that of evaluating the amount of resources an adversary would need to perform such an attack and what would be the actual damage that the Tor Network would suffer. At the same time, we are working on a patch to be applied to the Tor software that could mitigate this issue. The reason you are receiving this message is that, to improve our study, we require some extra information about the Relay(s) you are running that, unfortunately, is not publicly available. We would therefore like to ask a very little, but precious, help from your side in collecting this information and sharing it with us. Note that the information we need is *not* related in any way with the traffic that you are relaying in this moment or have relayed in the past, thus it cannot be directly used to affect the privacy of the Tor users. What we are interested in is related to the hardware characteristics (e.g., number of physical CPUs, amount of memory) and with some of the configuration parameters of your Tor Relay (e.g., number of processors the Tor Relay can use, bandwidth limit). In the case you agree to help us, collecting this information won't steal much of your precious time. In order to make it easier for you to get it, you will find on the website linked at the end of this message a small shell script that you can run on the Tor Relay(s) themselves or, if possible, on another machine with the *same* hardware specs. The script doesn't need any special (i.e., root) permission to run, it won't download anything from the network, nor it will install any software on your machine. We also commented it so as to make it easier for you to understand it in case you wanted to check what is the exact sequence of operations it will perform and information it will collect. Any data saved by the shell script will be available in a human readable text format stored in an output directory you will specify. We encourage you to use the public key you will find on the bottom of this message to encrypt the data collected by the script before sending it to us. You ca n get the same public key on the website linked at the end of this message. We would like to assure you that we will take extraordinary care in protecting in the best way we can the privacy of any information you will decide to share with us. We want also to assure you that, in the event it will be published, any data you will provide us will be carefully anonymized and given only in terms of aggregated statistics. Together with the script, you will find a README file containing detailed instructions on how to use it and how to encrypt the results before sending them to us. We thank you for your kind attention. Best regards, Marco Valerio Barbera You can find the script and the public key in any of these locations: https://sites.google.com/site/marcobarbera/tor-survey http://www.dsi.uniroma1.it/~barbera/tor-survey.html -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.11 (Darwin) mQENBE8Fo8gBCADEwO0RNlXfTovI+LLGH8qGyRcDHycFc12URCZdol46sTPnNcrE 2w+KuIK841+QJt40tYBtE9/BT8CerQEGrEteiTIAClpltJcE+6Z04+bbS6EmDzb7 WzpxF0Tv9UrGhGCBncGvFnFbxaJQBu+5KrhJJTrW++778WTqMHoXvEw2LA9QHQB5 qaAgZbvi+2JHrXEB0Cp/OTtGXLz8uej/liifYNh8bYCYIpU8fe+7Q+1ktyPk75g3 1/bTgfywujIVxXoZyo2usSdEZ7KmrISA4E8TlCQwidK8dFEPNwREfcyVNfgrxXyS TpMj/41KWOfymBuR+x0gfpP7eUlzUoObFkaPABEBAAG0L01hcmNvIFZhbGVyaW8g QmFyYmVyYSA8YmFyYmVyYUBkc2kudW5pcm9tYTEuaXQ+iQE4BBMBAgAiBQJPBaPI AhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAUhbbzQCoISDOaCACCtPjq o041Z6urq8SVrlK/I659C1fbRUPVi+DJSEP3yZWIDxgwxDGopgabB/NFMwULiKOv 9WNHWydxrxsFYA/+lwbr9YxbV8ShME/pzhR6K+kbT7AGSmBOefgVfCJywh7JcGb4 kp59KKmX7EnHYEkir3HK3wX34ScPbttge1bTQfQF4bKvGcUbqStIn/rL5mGNfbeR IFUidMF6aa1CcPIvkqD2Gs7rv9hAXFVG7/3TjrrzIAsFdXhU6UIM45jwdUnsbLiD Jz96Qz4HLa9wNU7nuSDAqzz+t15O/Fffg55pcUB1MpFIAhVqLffGfAoGrihAylPU aZIqc9ZJk2nr96KLuQENBE8Fo8gBCADs+hN+b/fir4mlxr9EqycYYvieuwiGWttt ocpWuhk/MxCzCRUA2/0GWdqtgFnmygWAh6HBv0XOZS04n83XGkKMEtoSfR4KXc8m xhtYkeSxH0FUuLE6/R9kHYcE7Eg4Jt0RO+aiCSoY4VDK7n4SpqWKoSVNYXKoYr2L zoXQ/PGJ/7RH9RAzKZDdQ5sgKLbpXiwib8mkWYbtPhNIbW4mF5QNSG+705L0yGh4 2keiPQFRAvc8hnkcKx6OVpmxdYEVTJT1t+ViYptDhtYc8axAB2z2ZBVyeeam3AZ0 3aJcG7PbQB/dmDPAKwULEsPoNWXEDKwZP6LbGo0tTAcklAB+RBOvABEBAAGJAR8E GAECAAkFAk8Fo8gCGwwACgkQFIW280AqCEg6UQgAwqd2TMzE01KWiafP7uIyk92l hgVEahFPulJyeWCpbqzA+4fYtC1rT+kuoDbyHbzbkQZJEHIjGcDlPHpb1zbB7iQy 6HyKhxRQXVcGCgWbsycYbLM+lwXbOn6LFqq6I+wBaMvOpPFNipxenJfjIlXdZyjA DSxI7SNvm+AMSfmVC0SJuTmxZGLdu8NxUohsqf6tpfspM341yQQZ2kUPGcwx/Y4d wvei2cbtTf2jSpU+y6Bara9c7JPjPq8pNsakrFneF/4l2T3cLVI5B95SXY5XTaTI G1VNfyebQCPUS0kKvpbHGxFl+B2STFjMMRbCpiqH3jFhBOcIrBulXhqTz5oLcg== =OsQy -----END PGP PUBLIC KEY BLOCK----- --- NOTICE This is an autonomous study, not supported neither directly nor indirectly by the Tor Project Inc. The Tor Project Inc. is not responsible for any content of this message.

3 2

Out of the mailing list
by Bruno Kitzis 10 Jan '12

10 Jan '12

Hello, I don't want to receive the TOR-mail anymore. Thank you. Best regards.

2 1

Re: [tor-relays] tor-relays Digest, Vol 12, Issue 9
by Jeffrey Ye 10 Jan '12

10 Jan '12

> From: tor-relays-request(a)lists.torproject.org > Subject: tor-relays Digest, Vol 12, Issue 9 > To: tor-relays(a)lists.torproject.org > Date: Tue, 10 Jan 2012 12:00:02 +0000 > > Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > > Today's Topics: > > 1. Re: consensus update request (grarpamp) > 2. Re: not specified families (Aurel W.) > 3. Re: not specified families (Tor Relays at brwyatt.net) > 4. Re: not specified families (Damian Johnson) > 5. New authority (Sebastian Urbach) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 9 Jan 2012 17:45:51 -0500 > From: grarpamp <grarpamp(a)gmail.com> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] consensus update request > Message-ID: > <CAD2Ti2-Ti1qv4Pb22JsKmpZXMTWPhSPwGyyLtkewYo5Z-U-rJA(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Maybe this is why my client is taking so long to load > at the moment. At first I thought it was my update to > ossl 100f, but after checking 100e again, it's not. Tor > currently sits in the netstatus consensus and missing > dir auth phases for indefinite tens of minutes before > coming online. > > valid-until 2012-01-09 20:00:00 > Mon Jan 9 22:..:.. UTC 2012 > > Is this something that's distributable as a piecemeal > flood into the net as each router is validated. Some > sort of client held table so the scale work and > partitioning is done there with their cpu/disk. > > > ------------------------------ > > Message: 2 > Date: Tue, 10 Jan 2012 00:28:16 +0100 > From: "Aurel W." <aurel.w(a)gmail.com> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] not specified families > Message-ID: > <CAAG-S2FCxKctVtpPj08Gpkyt5b6hvqO+T2EzauBfUMk=iZv59A(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > > Malicious relays trying to de-anonimize people are not going to use > > MyFamily for obvious reasons, and also they will not choose an obvious > > nick sequence like MetallicaFan1, MetallicaFan2,etc > > So it seems to me this option has only theoretical benefit, but in > > practice it's naive. > True, but in theory you also have to consider that nodes could get > compromised and then it is very likely that a whole family is affected > (may be too paranoid for some). > > I also wonder if it gets harder to identify a real threat, of a > malicious attacker operating many nodes, if there are so many other > cases of not-specified families. > > The "MetallicaFan1, MetallicaFan2,.." nodes might not be a problem, > because no one with a malicious attempt would name nodes like that. > But they are an indication, that there might be a bunch of other > nodes, without any such strong sings, but which are also operated by > one single individual. Because obviously, it's a very common mistake > in configuration. > > There might be feasible techniques to find suspicious groups of > relays, but with all this non specified families, this would be rather > pointless. > > aurel > > aurel > > On 9 January 2012 23:39, Javier Bassi <javierbassi(a)gmail.com> wrote: > > On Mon, Jan 9, 2012 at 7:13 PM, Aurel W. <aurel.w(a)gmail.com> wrote: > >> Shouldn't this be treated more seriously? There are literally over 100 > >> high bandwidth relays, which should specify a family but which don't. > >> If you monitor a client, it is very frequently that circuits are built > >> where two relays are clearly controlled by the same person. > >> > >> As a first try I mailed to two contact email addresses, but I haven't > >> got any response. > > > > In the end its the same. Relay operators who are willing to place > > MyFamily in their torrc file are not the ones that are going to try to > > identify you. > > Malicious relays trying to de-anonimize people are not going to use > > MyFamily for obvious reasons, and also they will not choose an obvious > > nick sequence like MetallicaFan1, MetallicaFan2,etc > > So it seems to me this option has only theoretical benefit, but in > > practice it's naive. > > Or maybe I'm missing something > > _______________________________________________ > > tor-relays mailing list > > tor-relays(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > ------------------------------ > > Message: 3 > Date: Tue, 10 Jan 2012 01:21:20 +0000 > From: "Tor Relays at brwyatt.net" <tor(a)brwyatt.net> > To: <tor-relays(a)lists.torproject.org> > Subject: Re: [tor-relays] not specified families > Message-ID: <802693728989435(a)jngomktg.net> > Content-Type: text/plain; charset=UTF-8 > > Wouldn't it be possible to code the Tor clients to not build circuits > using relays in the same /24 or with "similar" names? While that wouldn't > fix ALL possible attack scenarios, that could certainly help, and help > against accidental (or malicious) misconfigured nodes. > > On Tue, 10 Jan 2012 00:28:16 +0100, "Aurel W." <aurel.w(a)gmail.com> wrote: > >> Malicious relays trying to de-anonimize people are not going to use > >> MyFamily for obvious reasons, and also they will not choose an obvious > >> nick sequence like MetallicaFan1, MetallicaFan2,etc > >> So it seems to me this option has only theoretical benefit, but in > >> practice it's naive. > > True, but in theory you also have to consider that nodes could get > > compromised and then it is very likely that a whole family is affected > > (may be too paranoid for some). > > > > I also wonder if it gets harder to identify a real threat, of a > > malicious attacker operating many nodes, if there are so many other > > cases of not-specified families. > > > > The "MetallicaFan1, MetallicaFan2,.." nodes might not be a problem, > > because no one with a malicious attempt would name nodes like that. > > But they are an indication, that there might be a bunch of other > > nodes, without any such strong sings, but which are also operated by > > one single individual. Because obviously, it's a very common mistake > > in configuration. > > > > There might be feasible techniques to find suspicious groups of > > relays, but with all this non specified families, this would be rather > > pointless. > > > > aurel > > > > aurel > > > > On 9 January 2012 23:39, Javier Bassi <javierbassi(a)gmail.com> wrote: > >> On Mon, Jan 9, 2012 at 7:13 PM, Aurel W. <aurel.w(a)gmail.com> wrote: > >>> Shouldn't this be treated more seriously? There are literally over 100 > >>> high bandwidth relays, which should specify a family but which don't. > >>> If you monitor a client, it is very frequently that circuits are built > >>> where two relays are clearly controlled by the same person. > >>> > >>> As a first try I mailed to two contact email addresses, but I haven't > >>> got any response. > >> > >> In the end its the same. Relay operators who are willing to place > >> MyFamily in their torrc file are not the ones that are going to try to > >> identify you. > >> Malicious relays trying to de-anonimize people are not going to use > >> MyFamily for obvious reasons, and also they will not choose an obvious > >> nick sequence like MetallicaFan1, MetallicaFan2,etc > >> So it seems to me this option has only theoretical benefit, but in > >> practice it's naive. > >> Or maybe I'm missing something > >> _______________________________________________ > >> tor-relays mailing list > >> tor-relays(a)lists.torproject.org > >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > _______________________________________________ > > tor-relays mailing list > > tor-relays(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > > ------------------------------ > > Message: 4 > Date: Mon, 9 Jan 2012 18:00:59 -0800 > From: Damian Johnson <atagar1(a)gmail.com> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] not specified families > Message-ID: > <CAJdkzEOp711+5EOscFguTbS3DUDdVi3tEaPOOD3UbUGXtKhihw(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > > Wouldn't it be possible to code the Tor clients to not build circuits > > using relays in the same /24 or with "similar" names? > > Tor already avoids using multiple relays in a given /16 subnet. > https://gitweb.torproject.org/torspec.git/blob/HEAD:/path-spec.txt#l184 > > > ------------------------------ > > Message: 5 > Date: Tue, 10 Jan 2012 05:04:42 +0100 > From: Sebastian Urbach <sebastian(a)urbach.org> > To: tor-relays(a)lists.torproject.org > Subject: [tor-relays] New authority > Message-ID: <20120110040444.AC7731006006A(a)ccc-hanau.de> > Content-Type: text/plain; charset="iso-8859-15" > > Hi, > > freedompenguin v3 orport=9001 AC0AF18E61A3660B1F3BAC9FF9DF061D9E446735 > > May someone add the data to the add_default_trusted_dirservers() > function in config.c, using the syntax "v3ident=<fingerprint>". > > Thanks. > > Btw. i respond pretty fast to server / network issues ;-) > > -- > Mit freundlichen Gr??en / Yours sincerely > > Sebastian Urbach > > -------------------------------------------------------- > Religion is something left over from the infancy of > our intelligence, it will fade away as we adopt > reason and science as our guidelines. > -------------------------------------------------------- > > Bertrand Arthur William Russell (1872-1970), > British philosopher, logician, mathematician, > historian, and social critic. >

1 0

Authority sigs needed
by Sebastian Urbach 10 Jan '12

10 Jan '12

Hi all, Could all authority admins on this list please consider signing my new installed authority system. Just got 1 sig and i need at least 4 more to help with the service. Fingerprint. freedompenguin v3 orport=9001 AC0AF18E61A3660B1F3BAC9FF9DF061D9E446735 Thanks in advance. -- Mit freundlichen Grüßen / Yours sincerely Sebastian Urbach -------------------------------------------------------- Religion is something left over from the infancy of our intelligence, it will fade away as we adopt reason and science as our guidelines. -------------------------------------------------------- Bertrand Arthur William Russell (1872-1970), British philosopher, logician, mathematician, historian, and social critic.

2 1

New authority
by Sebastian Urbach 10 Jan '12

10 Jan '12

Hi, freedompenguin v3 orport=9001 AC0AF18E61A3660B1F3BAC9FF9DF061D9E446735 May someone add the data to the add_default_trusted_dirservers() function in config.c, using the syntax "v3ident=<fingerprint>". Thanks. Btw. i respond pretty fast to server / network issues ;-) -- Mit freundlichen Grüßen / Yours sincerely Sebastian Urbach -------------------------------------------------------- Religion is something left over from the infancy of our intelligence, it will fade away as we adopt reason and science as our guidelines. -------------------------------------------------------- Bertrand Arthur William Russell (1872-1970), British philosopher, logician, mathematician, historian, and social critic.

1 0

Re: [tor-relays] not specified families
by Tor Relays at brwyatt.net 10 Jan '12

10 Jan '12

Wouldn't it be possible to code the Tor clients to not build circuits using relays in the same /24 or with "similar" names? While that wouldn't fix ALL possible attack scenarios, that could certainly help, and help against accidental (or malicious) misconfigured nodes. On Tue, 10 Jan 2012 00:28:16 +0100, "Aurel W." <aurel.w(a)gmail.com> wrote: >> Malicious relays trying to de-anonimize people are not going to use >> MyFamily for obvious reasons, and also they will not choose an obvious >> nick sequence like MetallicaFan1, MetallicaFan2,etc >> So it seems to me this option has only theoretical benefit, but in >> practice it's naive. > True, but in theory you also have to consider that nodes could get > compromised and then it is very likely that a whole family is affected > (may be too paranoid for some). > > I also wonder if it gets harder to identify a real threat, of a > malicious attacker operating many nodes, if there are so many other > cases of not-specified families. > > The "MetallicaFan1, MetallicaFan2,.." nodes might not be a problem, > because no one with a malicious attempt would name nodes like that. > But they are an indication, that there might be a bunch of other > nodes, without any such strong sings, but which are also operated by > one single individual. Because obviously, it's a very common mistake > in configuration. > > There might be feasible techniques to find suspicious groups of > relays, but with all this non specified families, this would be rather > pointless. > > aurel > > aurel > > On 9 January 2012 23:39, Javier Bassi <javierbassi(a)gmail.com> wrote: >> On Mon, Jan 9, 2012 at 7:13 PM, Aurel W. <aurel.w(a)gmail.com> wrote: >>> Shouldn't this be treated more seriously? There are literally over 100 >>> high bandwidth relays, which should specify a family but which don't. >>> If you monitor a client, it is very frequently that circuits are built >>> where two relays are clearly controlled by the same person. >>> >>> As a first try I mailed to two contact email addresses, but I haven't >>> got any response. >> >> In the end its the same. Relay operators who are willing to place >> MyFamily in their torrc file are not the ones that are going to try to >> identify you. >> Malicious relays trying to de-anonimize people are not going to use >> MyFamily for obvious reasons, and also they will not choose an obvious >> nick sequence like MetallicaFan1, MetallicaFan2,etc >> So it seems to me this option has only theoretical benefit, but in >> practice it's naive. >> Or maybe I'm missing something >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

2 1

Re: [tor-relays] not specified families
by Tor Relays at brwyatt.net 10 Jan '12

10 Jan '12

Probably just misconfigured. If there are emails attached to the nodes you could try mailing them directly about it. brwyatt On Fri, 6 Jan 2012 01:29:42 +0100, "Aurel W." <aurel.w(a)gmail.com> wrote: > Hi, > > when I browse through the list of relays I find many router names, > which correlate in some way, but which don't specify a family in their > descriptors. > > Just to name a few: > * 2* c5VycfOP > * 3* c516a > * Caldron, Caldron2, Caldron3 > * BlgTOR2, BlgTOR > * DwarfHappy, DwarfSleepy, DwarfSneezy, DwarfDopey > * DONATIONxTORx0 - DONATIONxTORx7 > and so on,... > > is there a reason, why there is such a high number of relays, which > fail to specify a family, since this seams rather striking? > > aurel > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

5 7

Re: [tor-relays] consensus update request
by Scott Bennett 09 Jan '12

09 Jan '12

Thanks, Sebastian, for the very quick reply. On Sun, 8 Jan 2012 15:12:25 +0100 Sebastian Hahn <mail(a)sebastianhahn.net> wrote: >On Jan 8, 2012, at 3:09 PM, Scott Bennett wrote: > >> The last consensus document expired about 15 hours ago. I understand >> that the authority operators and tor developers are probably occupied with >> fixing whatever is the trouble, but if someone in that group of individuals >> can spare a moment to fill us in on what is happening, I, for one, would >> greatly appreciate it. >> FWIW, I think a page on the torproject.org web site for very brief >> status updates on extraordinary situations like this one would be a good >> and helpful addition. >> Thanks much, and best of luck getting things working right again. > >People are indeed working to restore service. Currently it looks like Glad to know that. >two authorities are completely offline, and a couple others are too >overloaded to function properly wrt voting. Hmm. Will this situation, then, result in a renewed effort to find a few more people to run authorities? > >In the meantime you might like >https://metrics.torproject.org/consensus-health.html which monitors the >consensus. Thanks for that, too. It's not what I had in mind, but it is interesting, nonetheless. Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************

5 4

Internal server error while fetching from dizum
by Klaus Layer 09 Jan '12

09 Jan '12

Hi, my relays are getting 500 error while fetching data from authority dizum. Can someone explain what is happening with this tor authority? Regards, Klaus 14:25:51 [WARN] Received http status code 500 ("Internal Server Error") from server '194.109.206.212:80' while fetching "/tor/server/d/C539CB98343680892C46D0A70770E6D0A4A39564+E5A7994519731C2C3349AAA4C2A38CED2CE74457+E8507D31268490E9E4E8A2110E371F1537156C75+E8BCD670FFB8ADF73195BDB9362ACDDB28F704A5+E94B92087B4614CB7F1C9CC1191C383- 7D890C60E+EA71B375FC45F026C854C903887D981CF19B7326+EA9DE146A13B316D2F3D5C2ACF491C068B93FF9D+EB896E11C16C0531D83560D3CBBEF97AF2FFF4D5+ECEBAAF01CA177EEB68A8A6838E4A16- BD54749F6+ED5A60237FDCA188DF30DC380536754DFBF01404.z". I'll try again soon.

2 3

consensus update request
by Scott Bennett 08 Jan '12

08 Jan '12

The last consensus document expired about 15 hours ago. I understand that the authority operators and tor developers are probably occupied with fixing whatever is the trouble, but if someone in that group of individuals can spare a moment to fill us in on what is happening, I, for one, would greatly appreciate it. FWIW, I think a page on the torproject.org web site for very brief status updates on extraordinary situations like this one would be a good and helpful addition. Thanks much, and best of luck getting things working right again. Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************

2 1