Re: [tor-dev] Should cloud-hosted relays be rejected?

> Does anyone know which attacks were carried out via relays running on cloud > platforms? The Lizard Squad thing from last year was substantially Google Cloud (GAE/GCE), if I recall correctly (there's a list from consensus-health here[0]). Lots of research takes place on EC2, but it doesn't seem

Re: [tor-dev] Should cloud-hosted relays be rejected?

My sense of tor-relays is that "end users" as relay operators (which presumably operate most relays, with places like torservers doing the rest) just go looking for VPS accounts. ie: compute platforms aren't their thing. Which leaves the only real users of compute to be attackers and researchers.

Re: [tor-dev] Where are the GetTor downloads (e.g. GitHub)?

On Mon, Aug 31, 2015 at 10:07:17PM -0300, ilv wrote: > Hi David, > > > > > My question is, is there a static URL on GitHub or similar that has the > > latest downloads? That is, one that people can access even without > > having used GetTor? Such a URL would be more useful than a typical > > mirr

Re: [tor-dev] Where are the GetTor downloads (e.g. GitHub)?

Hi David, > > My question is, is there a static URL on GitHub or similar that has the > latest downloads? That is, one that people can access even without > having used GetTor? Such a URL would be more useful than a typical > mirror for many users. > Yes, you can find the latest Tor Browser ver

Re: [tor-dev] Should cloud-hosted relays be rejected?

Philipp Winter transcribed 2.6K bytes: > > The harm caused by cloud-hosted relays is more difficult to quantify. > Getting rid of them also wouldn't mean getting rid of any attacks. At > best, attackers would have to jump through more hoops. > Does anyone know which attacks were carried out via

Re: [tor-dev] Should cloud-hosted relays be rejected?

Tim Wilson-Brown - teor transcribed 11K bytes: > > > On 1 Sep 2015, at 07:45, Philipp Winter wrote: > > > > There are also cloud-hosted bridges. Tor Cloud, however, has shut down, > > and the number of EC2 bridges is declining: > >

Re: [tor-dev] Should cloud-hosted relays be rejected?

>> On 1 Sep 2015, at 07:45, Philipp Winter > > wrote: >> >> The harm caused by cloud-hosted relays is more difficult to quantify. >> Getting rid of them also wouldn't mean getting rid of any attacks. At >> best, attackers would have to jump through more hoops. >> >> If we

Re: [tor-dev] Should cloud-hosted relays be rejected?

> We sometimes see attacks from relays that are hosted on cloud platforms. > I have been wondering if the benefit of having cloud-hosted relays > outweighs the abuse we see from them. I don't think banning GCE, AWS and MS Azure is an efficient method to significantly increase the cost of attacks

Re: [tor-dev] Should cloud-hosted relays be rejected?

> On 1 Sep 2015, at 07:45, Philipp Winter wrote: > > 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. > > To get an idea of the benefit, I analysed the bandwidth

[tor-dev] Should cloud-hosted relays be rejected?

We sometimes see attacks from relays that are hosted on cloud platforms. I have been wondering if the benefit of having cloud-hosted relays outweighs the abuse we see from them. To get an idea of the benefit, I analysed the bandwidth that is contributed by cloud-hosted relays. I first obtained th

Re: [tor-dev] New Onionoo version 2.6 adds new "alleged_family" and "indirect_family" fields

> The current "family" field will stay available until Atlas and Globe > are updated. If I should also wait for other clients to be updated, > please let me know. If someone is actually going to adjust atlas/globe/compass it would be great if that someone could also take this enhancement request

Re: [tor-dev] New Onionoo version 2.6 adds new "alleged_family" and "indirect_family" fields

> The current "family" field will stay available until Atlas and Globe > are updated. If I should also wait for other clients to be updated, > please let me know. Please do not forget about compass before removing the 'family' field, thanks. signature.asc Description: OpenPGP digital signature

[tor-dev] [Measurement Team] Next IRC meeting happens on Wednesday, Sep 2, 14:00 UTC in #tor-project

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello list, This is an announcement/reminder that there will be an IRC meeting of the Measurement Team on Wednesday, September 2, 2015, 14:00 UTC in #tor-project https://www.timeanddate.com/worldclock/fixedtime.html?iso=20150902T14 Talk to you on

[tor-dev] New Onionoo version 2.6 adds new "alleged_family" and "indirect_family" fields

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Onionoo users, I just merged and deployed Onionoo protocol version 2.6 which adds two new fields related to relay families and marks the current "family" field as deprecated. The idea of adding three fields for relay families is that we want to

[tor-dev] Where are the GetTor downloads (e.g. GitHub)?

Someone IRL asked me about mirrored downloads of Tor Browser on services like GitHub. I know that such services are planned (or already implemented?) for GetTor, and I know about these tickets: Integrate cloud services that are not blocked in mainland China https://bugs.torproject.

Re: [tor-dev] Remove NULL checks for *_free() calls

Original Message From: Zack Weinberg To: tor-dev@lists.torproject.org Subject: Re: [tor-dev] Remove NULL checks for *_free() calls Date: Mon, 31 Aug 2015 10:29:31 -0400 > > But you did find some places they forgot to assign NULL after free. > > Unfortunately, setting pointers t

Re: [tor-dev] Remove NULL checks for *_free() calls

On Sun, Aug 30, 2015 at 10:37 PM, Mansour Moufid wrote: > On Sun, Aug 30, 2015 at 8:13 PM, Michael McConville > wrote: > >> free() is specified to be NULL-safe, and I don't know of any >> implementations that violate this. > > I think those NULL checks are meant to avoid double-free bugs. If you

Re: [tor-dev] Remove NULL checks for *_free() calls

On Sun, 30 Aug 2015 23:24:07 +, Michael McConville wrote: > Mansour Moufid wrote: > > Michael McConville wrote: ... > > > error: > > > - if (x509) { > > > -X509_free(x509); > > > -x509 = NULL; > > > - } ... > > But you did find some places they forgot to assign NULL after free. > >