Re: [tor-dev] tor 0.2.7.5 make error

[grarpamp]

On Tue, Dec 8, 2015 at 1:10 AM, Tim Wilson-Brown - teor
 wrote:
> What's the version of autoconf / automake?
> https://trac.torproject.org/projects/tor/ticket/17732

added
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] tor 0.2.7.5 make error

[Tim Wilson-Brown - teor]

> On 8 Dec 2015, at 16:47, grarpamp  wrote:
> 
> "Makefile", line : Need an operator
> make: fatal errors encountered -- cannot continue
> 
> 6772:export TESTING_TOR_BINARY=$(top_builddir)/src/or/tor
> 6794:export PYTHON=
> 6795:export SHELL=/bin/sh
> 6796:export abs_top_srcdir=/tmp/tor-0.2.7.5
> 6797:export builddir=.
> 
> This is on a FreeBSD 8.x from early 2014.
> The autotools is probably too old there.
> Haven't got around to supplying a better fix
> than commenting them out of .in and not using
> autoreconf -fiv. 8.x is EOL anyways.

What's the version of autoconf / automake?

We're trying to work out which autotools versions we support in #17732.
https://trac.torproject.org/projects/tor/ticket/17732 


Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Shared random value calculation edge cases (proposal 250)

[Michael Rogers]

On 21/11/15 12:05, George Kadianakis wrote:
>> If there's no consensus on a fresh SRV, why not just use the disaster 
>> recovery procedure?
>>
>> That is:
>>
>># Consensus
>>if majority agrees on SR value(s):
>>put in consensus
>>else:
>>put disaster recovery SR value (based on last round's agreed SR 
>> value, if any) in consensus
>>
>>Output: consensus is created
>>
>>(Proceed like the 16:00 period)
>>
> 
> True. However, if the majority cannot agree on SR values, how can a majority 
> be
> formed to agree on disaster recovery SRVs? The problem here is that the 
> disaster
> SRVs are derived from the previous SRV.

Would it help if we defined the disaster SRV as being derived from the
last SRV for which there was a consensus, rather than from the previous
round's SRV?

That would allow the network to converge on the same sequence of
disaster SRVs, and then switch back from disaster mode to
business-as-usual mode, just by sharing valid consensuses.

>> That way, clients and relays don't need to do anything special: there will 
>> always be a SRV in the consensus.
>>
>> This means that the SR consensus method will always produce a SR value, 
>> which I believe is a much better property than occasionally failing to 
>> produce a value.
>>
> 
> Indeed, that's something very important.
> 
> Yesterday, we were discussing with David how bad it would be if 2-3 SR-enabled
> dirauths drop offline during voting, and the rest dirauths generate a 
> consensus
> without an SR value (because the consensus method requirement for SR failed or
> something).
> 
> In this case, some clients will have a consensus with an SR value, and some
> other clients will have a consensus with no SR value. Those two client sets 
> will
> use a different formula to connect to hidden services, bringing out terrible
> reachability consequences.

When the failed dirauths come back online they should accept the
consensus that was generated in their absence. So in the following
round, all dirauths will vote for an SRV based on the one that was
agreed while the failed dirauths were offline.

Cheers,
Michael

> I wonder what's the solution here. We don't want a single consensus to break
> reachability for all hidden services. I wonder what should we do? Should we 
> just
> make it ultra unlikely that a consensus will be generated without SR values?
> For exmaple, we could require every dirauth to participate in the protocol so
> that we either have a consensus with SR or no consensus at all. This will slow
> down deployment, but it might make the system more bullet proof.
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev



0x9FC527CC.asc
Description: application/pgp-keys


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

Re: [tor-dev] Scaling Tor Metrics, Round 2

[Karsten Loesing]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/12/15 01:07, Spencer wrote:
> Hi,
>> teor: Do David's visualizations already use JavaScript? We could
>> make (another) part of the metrics site use JavaScript.
>> 
> 
> Can the data be processed on the host server and sent to the
> client JS-free?

We briefly discussed making a JavaScript-free Globe a while ago by
using Node.js.  I'm not sure whether this would also work for Metrics.
 It may depend on how interactive graphs are supposed to be.

But before we look more into this: do we really have no JavaScript at
all?  The High Security level in Tor Browser says that JavaScript
performance optimizations are disabled and that JavaScript is disabled
on all non-HTTPS sites, but in theory, Metrics runs on HTTPS, so the
bubble graphs should work in Tor Browser.  A possible deal breaker
might be that we're fetching data from Onionoo for the bubble graphs.
 Would we be able to put JavaScript on Metrics if we load data from
https://metrics.torproject.org/ instead of
https://onionoo.torproject.org/?

>> Or are we waiting to choose a language before doing any new
>> work?
>> 
> 
> What are the options?

I think the main option is to keep rendering graphs on the server.
Right now, we're using R/ggplot2 for that, but we could switch to
server-side JavaScript or really anything else.  The main downside is
lack of real interactivity.

Thanks for the feedback!

All the best,
Karsten

-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJWZT/sAAoJEJD5dJfVqbCrjEwH/2aeydyl4QhxNubSzj0liQQc
37ajKKePhGNwRGFlna+KccSpZRA4yZg6/Rqejl7sylPdXEHF9joyUyX+2u2Bq6Lp
IfuN5LAnohio2TAC8HRlNMUgEZUwmTVrtGMM+mf+iUu3z0c9RQWlusdqv3pUy36J
nVZKHazEs4u0ZdiKJwPTGecNkzgw00zkufwMUtuuBSmMvmSjlpmKrbs1swoXRt1a
ltVpj24QQv5igQBHpTuFdBAMHS0F4dGwGWSYHYxwo4ZaAQPD3SnVlNDqk3FXS22/
nMQj+Smp5I9qyplPTHTofcZKWenInDdV69J+j3WOk96WhWmk+qgVrjv+/5Bhgts=
=R8ud
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Scaling Tor Metrics, Round 2

[Tim Wilson-Brown - teor]

> On 7 Dec 2015, at 19:14, Karsten Loesing  wrote:
> 
> On 07/12/15 01:07, Spencer wrote:
> > Hi,
> >> teor: Do David's visualizations already use JavaScript? We could
> >> make (another) part of the metrics site use JavaScript.
> >>
> >
> > Can the data be processed on the host server and sent to the
> > client JS-free?
> 
> We briefly discussed making a JavaScript-free Globe a while ago by
> using Node.js.  I'm not sure whether this would also work for Metrics.
> It may depend on how interactive graphs are supposed to be.

There are privacy advantages to doing the Globe processing on the client using 
JavaScript.
It's a design that means that user queries are never seen by the server.

> But before we look more into this: do we really have no JavaScript at
> all?  The High Security level in Tor Browser says that JavaScript
> performance optimizations are disabled and that JavaScript is disabled
> on all non-HTTPS sites, but in theory, Metrics runs on HTTPS, so the
> bubble graphs should work in Tor Browser.


The Medium-High level disables JavaScript on non-HTTPS sites.
The High level disables JavaScript on all sites.
(In either case, users can enable it on a site-by-site basis.)

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Graphs - Estimated Traffic Capacity

[Tim Wilson-Brown - teor]

> On 22 Nov 2015, at 02:55, David Goulet  wrote:
> 
> On 21 Nov (16:26:31), Tim Wilson-Brown - teor wrote:
> ...
>> It would be great to have some stats for typical path lengths, is there an 
>> open ticket for this, or should I create one?
> 
> That would help us have a better estimate of network capacity for sure but I
> wonder if it worth the efforts versus having a real privacy oriented
> statistics gathering system that could give us a much more accurate number of
> the used and unused capacity of relays.
> 
> In other words, question comes down to should we put effort in a bigger larger
> system or continue cherry-picking small stats here and there? (huge work once
> vs small/medium-ish effort multiple time :)

I've created ticket #17768 for this.
https://trac.torproject.org/projects/tor/ticket/17768 


Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Better relay uptime visualisation

[Tim Wilson-Brown - teor]

> On 8 Dec 2015, at 10:43, Tom Ritter  wrote:
> 
> On 7 December 2015 at 13:51, Philipp Winter  > wrote:
>> I spent some time improving the existing relay uptime visualisation [0].
>> Inspired by a research paper [1], the new algorithm uses single-linkage
>> clustering with Pearson's correlation coefficient as distance function.
>> The idea is that relays are grouped next to each other if their uptime
>> (basically a binary sequence) is highly correlated.  Check out the
>> following gallery.  It contains monthly relay uptime images, dating back
>> to 2007:
>> > >
>> 
>> If you aren't familiar with this type of visualisation: Every image
>> shows the uptime of all Tor relays that were online in a given month.
>> Every row is a consensus and every column is a relay.  White pixels mean
>> that a relay was offline and black pixels means that a relay was
>> online.  Red pixels are used to highlight suspiciously similar clusters.
> 
> That's really cool.  It seems to imply that the majority of the tor
> network stop operating halfway through the month though... Do the
> other tor graphs take into account hibernating relays?  For example, I
> would expect the time-to-download graph would be somewhat affected:
> https://metrics.torproject.org/torperf.html?graph=torperf=2015-10-01=2015-10-31=all=5mb
>  
> 
Hibernating relays run from the start of their first period to gauge load.
Then they start at a random time during the day/month, but early enough that 
they think they'll still use all their bandwidth.

I wonder if we're seeing another phenomenon? (daily / monthly server restarts?)
Or we could be seeing hibernation failing to work as intended.

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Scaling Tor Metrics, Round 2

[Karsten Loesing]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/12/15 12:10, Tim Wilson-Brown - teor wrote:
> 
>> On 7 Dec 2015, at 19:14, Karsten Loesing 
>> wrote:
>> 
>> On 07/12/15 01:07, Spencer wrote:
>>> Hi,
 teor: Do David's visualizations already use JavaScript? We
 could make (another) part of the metrics site use
 JavaScript.
 
>>> 
>>> Can the data be processed on the host server and sent to the 
>>> client JS-free?
>> 
>> We briefly discussed making a JavaScript-free Globe a while ago
>> by using Node.js.  I'm not sure whether this would also work for
>> Metrics. It may depend on how interactive graphs are supposed to
>> be.
> 
> There are privacy advantages to doing the Globe processing on the
> client using JavaScript. It's a design that means that user queries
> are never seen by the server.

Well, queries are still seen by the Onionoo server.

>> But before we look more into this: do we really have no
>> JavaScript at all?  The High Security level in Tor Browser says
>> that JavaScript performance optimizations are disabled and that
>> JavaScript is disabled on all non-HTTPS sites, but in theory,
>> Metrics runs on HTTPS, so the bubble graphs should work in Tor
>> Browser.
> 
> 
> The Medium-High level disables JavaScript on non-HTTPS sites. The
> High level disables JavaScript on all sites. (In either case, users
> can enable it on a site-by-site basis.)

You're right.  Thanks for clarifying this.

All the best,
Karsten

-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJWZYNPAAoJEJD5dJfVqbCrkSEIAJl9jgfXUXGpqG3BRoGIWFZX
8rrajfUz8mOYKBBFZZBHmFQC2vMsexAqH9XBYAPjRvWVHG6HcPq/C9ng6+xYDjQN
SDYCt6v7PdrhyPHA1h31XdNmo1CQ6Tn+YUuwyWhIHRGYSOaTJ8vr46mTswKQUXQd
1cIl7zPmD3dR+YBPhcgL/OL06YLVKOdPt1RMvnIghTKimgd9DQ3iHSwFQ23ZMhyM
necMSkespRPgeWjrICHgVWKKITQTRewbvuj93aNZrzvSNLSpXkpRo94q1KoEifrW
PqIB4CVPYkwKKOCnCphyT5hYbjgEfaAy8DQB8rw6KRnN9yXVP6xKy46eV+nsJrA=
=9Gax
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Better relay uptime visualisation

[Philipp Winter]

I spent some time improving the existing relay uptime visualisation [0].
Inspired by a research paper [1], the new algorithm uses single-linkage
clustering with Pearson's correlation coefficient as distance function.
The idea is that relays are grouped next to each other if their uptime
(basically a binary sequence) is highly correlated.  Check out the
following gallery.  It contains monthly relay uptime images, dating back
to 2007:


If you aren't familiar with this type of visualisation: Every image
shows the uptime of all Tor relays that were online in a given month.
Every row is a consensus and every column is a relay.  White pixels mean
that a relay was offline and black pixels means that a relay was
online.  Red pixels are used to highlight suspiciously similar clusters.
A nice example is the Heartbleed incident:

The huge red block on the left shows all the relays that were removed by
the directory authorities because they didn't rotate their key pairs in
time.

The downside of single-linkage clustering is that it takes longer to
compute.  On my laptop, I can create an image covering one month in
under three minutes, so it's tolerable.

Another practical problem is that it's cumbersome to learn the relay
fingerprint of a given column.  I'm looking into JavaScript/HTML tricks
that can show text when you hover over a region in the image.  Perhaps
somebody knows more?

[0] 
[1] , Section 2

Cheers,
Philipp
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Better relay uptime visualisation

[David Fifield]

On Mon, Dec 07, 2015 at 02:51:23PM -0500, Philipp Winter wrote:
> I spent some time improving the existing relay uptime visualisation [0].
> Inspired by a research paper [1], the new algorithm uses single-linkage
> clustering with Pearson's correlation coefficient as distance function.
> The idea is that relays are grouped next to each other if their uptime
> (basically a binary sequence) is highly correlated.  Check out the
> following gallery.  It contains monthly relay uptime images, dating back
> to 2007:
> 

How about just taking the XOR of two sequences as the distance?

It would be interesting to know if there are any near-perfect
anticorrelations; i.e., one relay starts when another stops.

> Another practical problem is that it's cumbersome to learn the relay
> fingerprint of a given column.  I'm looking into JavaScript/HTML tricks
> that can show text when you hover over a region in the image.  Perhaps
> somebody knows more?

One way is to set an onmousemove handler that inserts text into a
preexisting element. For example (untested):




var OUTPUT_ELEM = document.getElementById("output");
/* Get an event's coordinates relative to a given element. */
function elem_coords(event, elem) {
var rect = elem.getBoundingClientRect();
/* http://stackoverflow.com/a/872537 */
if (typeof pageXOffset !== "undefined") {
scrollLeft = pageXOffset;
scrollTop = pageYOffset;
} else if (document.documentElement !== undefined && 
document.documentElement.clientHeight !== undefined) {
scrollLeft = document.documentElement.scrollLeft;
scrollTop = document.documentElement.scrollTop;
} else {
scrollLeft = document.body.scrollLeft;
scrollTop = document.body.scrollTop;
}
var x = event.pageX - (scrollLeft + rect.left);
var y = event.pageY - (scrollTop + rect.top);
return { x: x, y: y };
}
function onmousemove_callback(event) {
var c = elem_coords(event, img_element);
OUTPUT_ELEM.innerText = get_text_for_coordinates(c.x, c.y);
}
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Better relay uptime visualisation

[nusenu]

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] https://nymity.ch/sybilhunting/uptime-visualisation/slide_2014-12.html



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

Re: [tor-dev] Better relay uptime visualisation

[David Fifield]

On Tue, Dec 08, 2015 at 10:47:08AM +1100, Tim Wilson-Brown - teor wrote:
> 
> On 8 Dec 2015, at 10:43, Tom Ritter <[1]t...@ritter.vg> wrote:
> 
> On 7 December 2015 at 13:51, Philipp Winter <[2]p...@nymity.ch> wrote:
> 
> I spent some time improving the existing relay uptime visualisation
> [0].
> Inspired by a research paper [1], the new algorithm uses 
> single-linkage
> clustering with Pearson's correlation coefficient as distance 
> function.
> The idea is that relays are grouped next to each other if their uptime
> (basically a binary sequence) is highly correlated.  Check out the
> following gallery.  It contains monthly relay uptime images, dating
> back
> to 2007:
> <[3]https://nymity.ch/sybilhunting/uptime-visualisation/>
> 
> If you aren't familiar with this type of visualisation: Every image
> shows the uptime of all Tor relays that were online in a given month.
> Every row is a consensus and every column is a relay.  White pixels
> mean
> that a relay was offline and black pixels means that a relay was
> online.  Red pixels are used to highlight suspiciously similar
> clusters.
> 
> 
> That's really cool.  It seems to imply that the majority of the tor
> network stop operating halfway through the month though... Do the
> other tor graphs take into account hibernating relays?  For example, I
> would expect the time-to-download graph would be somewhat affected:
> [4]https://metrics.torproject.org/torperf.html?graph=torperf=
> 2015-10-01=2015-10-31=all=5mb
> 
> 
> Hibernating relays run from the start of their first period to gauge load.
> Then they start at a random time during the day/month, but early enough that
> they think they'll still use all their bandwidth.
> 
> I wonder if we're seeing another phenomenon? (daily / monthly server 
> restarts?)
> Or we could be seeing hibernation failing to work as intended.

Relays turn on or off all the time. Of all the descriptors seen in a
year, less than 10% are continuously running the whole time. The rest
either started at some time or stopped at some time or both. See an
example here for 2014:

https://people.torproject.org/~dcf/graphs/microdescs/microdescs-2014-short.png
All we're seeing is the distributions of the dates at which the subset
of relays that stopped during the month actually stopped, which seems
pretty uniform. I'll bet that if you look at those relays in the
previous month, they are running at the end of the month, not
hibernating.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Better relay uptime visualisation

[grarpamp]

Can a one be generated covering each year and maybe a five year one.
And three other check sets but sorted left to right by
first online date
FP
AS

As to the actual FP's, all I can think of is including a second text file
with pixel number to FP mappings. Or some "maps" style online zooming.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Better relay uptime visualisation

[Philipp Winter]

On Mon, Dec 07, 2015 at 05:43:01PM -0600, Tom Ritter wrote:
> On 7 December 2015 at 13:51, Philipp Winter  wrote:
> > I spent some time improving the existing relay uptime visualisation [0].
> > Inspired by a research paper [1], the new algorithm uses single-linkage
> > clustering with Pearson's correlation coefficient as distance function.
> > The idea is that relays are grouped next to each other if their uptime
> > (basically a binary sequence) is highly correlated.  Check out the
> > following gallery.  It contains monthly relay uptime images, dating back
> > to 2007:
> > 
> >
> > If you aren't familiar with this type of visualisation: Every image
> > shows the uptime of all Tor relays that were online in a given month.
> > Every row is a consensus and every column is a relay.  White pixels mean
> > that a relay was offline and black pixels means that a relay was
> > online.  Red pixels are used to highlight suspiciously similar clusters.
> 
> That's really cool.  It seems to imply that the majority of the tor
> network stop operating halfway through the month though... Do the
> other tor graphs take into account hibernating relays?  For example, I
> would expect the time-to-download graph would be somewhat affected:
> https://metrics.torproject.org/torperf.html?graph=torperf=2015-10-01=2015-10-31=all=5mb

What I forgot to mention:  In all diagrams, I removed relays that were
always online, because an all-online uptime sequence isn't useful to
find Sybils.  In Nov 2015, for example, we had 10,984 unique relays by
fingerprint and 3,202 (29%) were always online, and are not shown in the
visualisation.

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/ -uptime

Cheers,
Philipp
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Tor Messenger 0.1.0b4 is released

[Sukhbir Singh]

We are pleased to announce another public beta release of Tor Messenger. This
release addresses a number of stability and usability issues, and includes the
default bridge configurations for pluggable transports.

The initial public release [0] was a success in that it garnered a lot of
useful feedback. We tried to respond to all your concerns in the comments of
the blog post [1] but also collected and aggregated a FAQ of the most common
questions [2].

* Before Upgrading

Before upgrading to the new release, you will need to backup your OTR keys or
simply generate new ones. Please see the following steps to back them up [3].

In our eagerness to build on work done by Tor Browser, we made the decision to
store your profile directory inside the application bundle. This complicates
matters when you want to use the same accounts and keys across updates,
especially while we don't have an automatic updater [4].

Also, as was vociferously pointed out by some of our early adopters, this
probably isn't a very intuitive user experience. Copying the extracted
application to someone else's computer would unknowingly transfer your
accounts and OTR keys. It's unclear if this is commonly done and we'd love
feedback on this point to understand the urgency of the issue.

In future releases, we plan on revisiting this decision. The number one item
on our roadmap is porting Tor Browser's updater patches [5] so that keeping
Tor Messenger up-to-date is seamless and automatic. We also plan to add a UI
to make importing OTR keys and accounts from Pidgin, and other clients, as
easy as possible [6].

* Downloads

Please note that Tor Messenger is _still in beta_. The purpose of this release
is to help test the application and provide feedback. *At-risk users should
not depend on it for their privacy and safety*.

Linux (32-bit)

https://dist.torproject.org/tormessenger/0.1.0b4/tor-messenger-linux32-0.1.0b4_en-US.tar.xz

Linux (64-bit)

https://dist.torproject.org/tormessenger/0.1.0b4/tor-messenger-linux64-0.1.0b4_en-US.tar.xz

Windows

https://dist.torproject.org/tormessenger/0.1.0b4/tormessenger-install-0.1.0b4_en-US.exe

OS X (Mac)

https://dist.torproject.org/tormessenger/0.1.0b4/TorMessenger-0.1.0b4-osx64_en-US.dmg

sha256sums.txt
https://dist.torproject.org/tormessenger/0.1.0b4/sha256sums.txt

sha256sums.txt.asc
https://dist.torproject.org/tormessenger/0.1.0b4/sha256sums.txt.asc

The sha256sums.txt file containing hashes of the bundles is signed with the
key 0x6887935AB297B391 (fingerprint: 3A0B 3D84 3708 9613 6B84 5E82 6887 935A
B297 B391).

* Changelog

Here is the complete changelog since v0.1.0b2:

Tor Messenger 0.1.0b4 -- November 22 2015
  All Platforms
Bug 17492: Include default bridges configuration
Use tor and the pluggable transports from tor-browser 5.0.4
Bug 17552: Instantbird should handle XMPP message stanzas with subjects
ctypes-otr
  Bug 17539: Pass username when interpolating resent string
  Bug 15179: Add an OTR Preferences item to the Tools menu
Use the FIREFOX_42_0_RELEASE tag on mozilla-release
Use the THUNDERBIRD_42_0b2_RELEASE tag on comm-release
Bug 16489: Prevent automatic logins at startup
Update Tor Messenger logo in Tor Launcher
  Mac
Bug 16476: Themes preference is positioned incorrectly
Bug 17456: Application hang when navigating the preferences menu

Tor Messenger 0.1.0b3 -- October 30 2015
  Windows
Bug 17453: Fix Tor Messenger crash when starting up in Windows

[0] - https://blog.torproject.org/blog/tor-messenger-beta-chat-over-tor-easily/
[1] - 
https://blog.torproject.org/blog/tor-messenger-beta-chat-over-tor-easily/#comments
[2] - https://trac.torproject.org/projects/tor/wiki/doc/TorMessenger/FAQ
[3] - 
https://trac.torproject.org/projects/tor/wiki/doc/TorMessenger/FAQ#WherearemyOTRkeysstoredHowcanIpreservethemacrossupdates
[4] - https://bugs.torproject.org/13861
[5] - https://bugs.torproject.org/14388
[6] - https://bugs.torproject.org/16526

-- 
Sukhbir


signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] tor 0.2.7.5 make error

[grarpamp]

"Makefile", line : Need an operator
make: fatal errors encountered -- cannot continue

6772:export TESTING_TOR_BINARY=$(top_builddir)/src/or/tor
6794:export PYTHON=
6795:export SHELL=/bin/sh
6796:export abs_top_srcdir=/tmp/tor-0.2.7.5
6797:export builddir=.

This is on a FreeBSD 8.x from early 2014.
The autotools is probably too old there.
Haven't got around to supplying a better fix
than commenting them out of .in and not using
autoreconf -fiv. 8.x is EOL anyways.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev