Opened 8 years ago

Closed 6 years ago

#3920 closed defect (duplicate)

macos tbb too big for gmail

Reported by: arma Owned by:
Priority: Very High Milestone:
Component: Applications/GetTor Version:
Severity: Keywords:
Cc: erinn Actual Points:
Parent ID: #8542 Points:
Reviewer: Sponsor:

Description

I can imagine two options:

A) Figure out how to make it smaller. What got so big about it? Do some of its components include two different archs but not need to? Is something not stripped that should be, or we have extra debugging symbols in?

B) Split it into two pieces. (I don't think we need to split it into 20 pieces -- that can't be fun to download.) This would be a sad choice to make, since it adds complexity for the receiving user. But if "A" doesn't do it, then "B" is it.

Unless there's a third option we should explore?

Child Tickets

Change History (15)

comment:1 Changed 8 years ago by erinn

The thing that made it bigger is Firefox's XUL (libxul.so in Linux). It is 10 megabytes bigger than the old one. :/ We only build for one arch, I think the universal packages are twice the size of ours.

I'm not sure there's any way to make it smaller, but I can look into more restrictive build options and disabling more things, but I do have debug disabled, among other things (https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/build-scripts/config/mozconfig-osx-i386) Otherwise I think splitting the package is our only option.

comment:2 Changed 8 years ago by erinn

More detail: The XUL in the x86_64 bundle is actually 48mb. The i386 one is 25mb. It might require a heroic effort to get the x86_64 bundles down to a one-piece gmailable size, but I will focus on the i386 ones right now since they work everywhere.

Assuming I am able to do that, should gettor offer only one? (For now?) I make x86_64 bundles on OSX primarily for people who care about things like DEP/ASLR which is only available there. Which seems like a good thing to offer to everyone, but I can imagine offering "one big package or this other one that you have to reassemble but also has cooler security properties and only works on some systems" might be a bit confusing.

comment:3 Changed 8 years ago by kaner

I don't think we should reduce the options of packages GetTor offers, even if current GMail and Yahoo email service providers don't allow for those to be received as an attachment. Maybe there are users with bigger attachment options out there. We shouldn't block them from getting Tor packages just because GMail and Yahoo don't allow their users to get those.

comment:4 Changed 8 years ago by kaner

I tried poking at a third option pointed out to me by Runa, upx: http://upx.sourceforge.net/

I tried unpacking Linux and OSX TBB packages, compressing the binaries and libs with upx and re-packing them:

In a nutshell, I did (similar with OSX package):

tar xzf tor-browser-gnu-linux-i686-1.1.14-dev-fa.tar.gz
cd tor-browser_fa
find | xargs upx -9
cd ..
tar czf -9 tor-browser_fa.tgz tor-browser_fa/

What sounded quite promising on upx' website turned out to be not so fantastic after all (The first package is *before* upx, the latter one *after* upx):

Linux:

-rw-r--r-- 1 kaner kaner  24M Aug 28 15:26 tor-browser-gnu-linux-i686-1.1.14-dev-fa.tar.gz
-rw-r--r-- 1 kaner kaner  24M Sep  4 12:17 tor-browser_fa.tgz

OSX:

-rw-r--r-- 1 kaner kaner  25M Aug 28 02:14 TorBrowser-1.0.24-dev-osx-i386-fa.zip
-rw-r--r-- 1 kaner kaner  25M Sep  4 12:21 TorBrowser_fa.app.zip

So unless I've done something wrong packaging, no new option here.

comment:5 in reply to:  2 Changed 8 years ago by arma

Replying to erinn:

More detail: The XUL in the x86_64 bundle is actually 48mb. The i386 one is 25mb. It might require a heroic effort to get the x86_64 bundles down to a one-piece gmailable size, but I will focus on the i386 ones right now since they work everywhere.

Assuming I am able to do that, should gettor offer only one? (For now?) I make x86_64 bundles on OSX primarily for people who care about things like DEP/ASLR which is only available there. Which seems like a good thing to offer to everyone, but I can imagine offering "one big package or this other one that you have to reassemble but also has cooler security properties and only works on some systems" might be a bit confusing.

Giving users the option to get a package which they will fail to receive is bad for usability. We should narrow the choices to the ones that are likely to actually work.

comment:6 Changed 8 years ago by arma

Priority: normalcritical

One stopgap measure in the meantime would be to recognize that gmail users can't get osx or linux packages, and tell them so in the email we send. There's no reason gettor's responses need to ignore the domain that they're answering.

If we want to get slightly fancier, once we have split osx / linux packages, we could automatically send the split ones when responding to a gmail or yahoo account. But we don't have split packages yet, so that's not relevant yet.

In any case we need to do *something*. We've told everybody to mail gettor from their gmail account, and now those are bad instructions.

comment:7 in reply to:  6 Changed 8 years ago by arma

Replying to arma:

But we don't have split packages yet

For reference, that's #1705.

comment:8 in reply to:  6 Changed 8 years ago by runa

Replying to arma:

In any case we need to do *something*. We've told everybody to mail gettor from their gmail account, and now those are bad instructions.

Can we please do something soon? If we don't split the package, can we at least tell the users where they can email from to receive the bundle?

comment:9 Changed 8 years ago by runa

I can confirm that Mac OS TBB is too big for gmail, yahoo, hotmail and verizon.net. Are there any email providers out there that can actually deliver the package?

comment:10 Changed 8 years ago by arma

I looked at the Tor mirror page and sent them three or four URLs to dist mirrors that use https and are run by people I know. That seemed to work for folks in Iran.

comment:11 Changed 8 years ago by kaner

Related to #4166

comment:12 Changed 8 years ago by kaner

Since 1ebe00e786a5a36856cd8db6c3ea54e8c0681907, GetTor will tell GMail/Yahoo users that their email provider doesn't allow large enough attachments if someone requests the OSX or Linux bundle. See #4166, #2520

Unsure if this closes this bug.

comment:13 Changed 8 years ago by fpietrosanti

Hi all,

made the following tricks that you can find attached to reduce the size
of TBB/OSX from 32MB to 23MB .

With this tricks it's possible to send TBB/OSX via Gmail using Gettor.

It goes from:

32M /tmp/TorBrowser-2.2.34-3-dev-osx-x86_64-en-US.zip

to

23M /tmp/TorBrowser-7z-wrap2.2.34-3-dev-osx-x86_64-en-US.zip

Probably it would require some better cleanup and integration, that's
just a working poc.

-naif

osx_tbb_reduce.txt
# Reducing TBB from 32MB to 23MB

# PRE-REQ
# Download TBB OSX
cd /tmp/
wget https://www.torproject.org/dist/torbrowser/osx/TorBrowser-2.2.34-3-dev-osx-x86_64-en-US.zip
# Size is 32MB
# du -sh /tmp/TorBrowser-2.2.34-3-dev-osx-x86_64-en-US.zip

32M /tmp/TorBrowser-2.2.34-3-dev-osx-x86_64-en-US.zip

# Install p7zip binary on system
# we use brew https://github.com/mxcl/homebrew
brew install p7zip

# Unzip TBB

unzip TorBrowser-2.2.34-3-dev-osx-x86_64-en-US.zip

cd TorBrowser_en-US.app/Contents/MacOS
cp -pr /usr/local/Cellar/p7zip/9.20.1/ p7zip

# Strip strippable files (-1MB of uncompressed size)

find . -type f -exec strip -S -x -X {} \; 2> /dev/null

# Compress Firefox.app, Vidalia.app and tor
# Using those parameters we can save 1.5MB of additional size

p7zip/lib/p7zip/7z a -mx=9 -md=64m -mfb=256 Firefox.app.7z Firefox.app
p7zip/lib/p7zip/7z a -mx=9 -md=64m -mfb=256 Vidalia.app.7z Vidalia.app
p7zip/lib/p7zip/7z a -mx=9 -md=64m -mfb=256 tor.7z tor

# Delete the uncompressed version

rm -rf tor Vidalia.app Firefox.app

# Modify the Shell Script wrapper of TorBrowserBundle
# To add automatic 1st launch 7zip decompression

vim TorBrowserBundle

# Decompress at first run
# Move to TorBrowser_en-US.app/Contents/MacOS/ directory
WORKDIR=dirname $0
cd $WORKDIR

echo "Verifying if TBB still need to uncompress itself..."
if -f tor.7z && -f Vidalia.app.7z && -f Firefox.app.7z && -f p7zip/lib/p7zip/7z ?;

then

echo "Files tor.7z - Vidalia.app.7z - Firefox.app.7z available"
echo "Decompressing files..."
echo -n "...tor.7z..."
p7zip/lib/p7zip/7z x tor.7z
echo -n "...Vidalia.app.7z..."
p7zip/lib/p7zip/7z x Vidalia.app.7z
echo -n "...Firefox.app.7z..."
p7zip/lib/p7zip/7z x Firefox.app.7z
echo "Deleting archives..."
rm -f tor.7z
echo -n "...tor.7z..."
rm -f Vidalia.app.7z
echo -n "...Vidalia.app.7z..."
rm -f Firefox.app.7z
echo -n "...Firefox.app.7z..."

else

echo "Compressed files not found: TBB already uncompressed"

fi

# Make a new ZIP image (better to use DMG)

cd ../../../

# Current size with built-in 7zip compressed app

du -sh TorBrowser_en-US.app
35M TorBrowser_en-US.app

# Create compresed archive
zip -r -9 TorBrowser-7z-wrap2.2.34-3-dev-osx-x86_64-en-US.zip TorBrowser_en-US.app

# New size of Compressed file

du -sh TorBrowser-7z-wrap2.2.34-3-dev-osx-x86_64-en-US.zip
23M TorBrowser-7z-wrap2.2.34-3-dev-osx-x86_64-en-US.zip

# Now move the file in some other place and just download and run it as usual
# The first run will compress and delete the internal .7z file transparently

I tried sending via GMAIL and it works fine.

I am confident that playing another little bit, using this method and going further, it would be possible to make additional reduction in size.

comment:14 Changed 8 years ago by kaner

Are we going to integrate this into the TBB build process at some point?

comment:15 Changed 6 years ago by sukhbir

Parent ID: #8542
Resolution: duplicate
Status: newclosed

#8542 discusses this problem in detail and proposes a solution that we would like to go with. Please refer to that for more discussion.

Note: See TracTickets for help on using tickets.