Make a deb of the Torbrowser and add to repository

added component::community priority::medium severity::normal status::needs-information type::enhancement labels

Unassigning this from myself. Someone else should feel free to take it though.

Trac:
Owner: erinn to N/A
Status: new to assigned

Can you change the status please?

'Assigned enhancement' is misleading as it's currently not assigned to anyone.

I believe there's no way to make the ticket new again (at least, using the web interface). Minus one point for trac.

Okay, here is the plan, (I)

close it
repost it
link the duplicate
add a statement "do not assign to erinn"

Are you okay with that plan?

Replying to cypherpunks:

Feature request for a standalone TB which can be installed with "apt-get install tor vidalia torbrowser"

There is no 'install' of the torbrowser, so apt-get install is incorrect to start. Torbrowser includes tor and vidalia, so installing those two are redundant.

And where would a .deb install to? ~/tor-browser_$(lang)?

Replying to arma:

I believe there's no way to make the ticket new again (at least, using the web interface). Minus one point for trac.

Correct. The ticket has been modified so one cannot set it back to some fake unmodified state.

Replying to proper:

Okay, here is the plan, (I)

close it

repost it

link the duplicate

add a statement "do not assign to erinn"

Are you okay with that plan?

No, this is a silly plan. New has no more preference than any other state in trac.

Trac:
Status: assigned to needs_information

No, this is a silly plan. New has no more preference than any other state in trac. I am sorry for the plan but assure that the motivation was genuine. Assigned implicates "ah, cool, someone is working in it, I can do something else" = no more attention, rotting here without resolution possibly. While new implicates "no on has taken it yet".

Replying to phobos:

Replying to cypherpunks:

Feature request for a standalone TB which can be installed with "apt-get install tor vidalia torbrowser"

There is no 'install' of the torbrowser, so apt-get install is incorrect to start. Torbrowser includes tor and vidalia, so installing those two are redundant.

The question only pops up as portable software for Linux is quite uncommon (compared to portable software for windows, i.e. portableapps.com).

And where would a .deb install to? ~/tor-browser_$(lang)?

Are there any reasons that this wouldn't be a fine solution?

Are there any reasons that this wouldn't be a fine solution?

Yes, dpkg isn't supposed to manage stuff in home. The .deb should install to /usr/bin and so on like any other package.

There is no 'install' of the torbrowser, so apt-get install is incorrect to start. Torbrowser includes tor and vidalia, so installing those two are redundant.

When installing the forked/patched Firefox which we call TorBrowser (as opposed to TorBrowserBundle) via apt-get the user is supposed to have root privs, take care of disk leakage (by using FDE) and install and configure Tor manually. This is not a request for a portable bundle that can be distributed via a .deb instead of a tar archive.

JonDoFox is very similar to Tor Browser. They also offer a .deb including firefox binary and browser profile. Could their method also work for Tor Browser?

Related, but no duplicate: #3994 (moved) "Get TorBrowser in Debian". (#3994 (moved) is about getting Tor Browser into Debian.)

And this ticket is about getting Tor Browser as a standalone into the Tor repository. https://www.torproject.org/docs/debian.html.en

Trac:
Cc: N/A to proper@secure-mail.biz

FWIW, we are working on this at Tails. Packages build and work fine, apparently https://tails.boum.org/todo/replace_iceweasel_with_Torbrowser/#index2h3.

Trac:
Cc: proper@secure-mail.biz to proper@secure-mail.biz, intrigeri@boum.org

Hi, I posted in #3994 (moved) about this, but this ticket seems more appropriate. I think I've come up with a really simple and working solution, and have even made a .deb package as an example. Does anyone see problems with this approach?

Here's my comment in the other ticket:

I've been following this bug, and think I came up with a workable solution. I don't think it could end up in Debian, however, because it does include shipping the result of the TorBrowserBundle build.

But I think it would be great to get this in the deb.torproject.org repository, and have Debian people put in the effort if they want it in the main repository.

Basically, we can make a deb package that contains a launcher script and the TBB tarball. When you run the launcher script, it checks if the current user has ~/.torbrowser/

VERSION. If they don't, it extracts the TBB tarball to that folder. Then it runs ~/.torbrowser/

VERSION/start-tor-browser.

Updated versions of the package would just include the new TBB tarball and the $VERSION variable would be changed.

Since this uses the same TBB that others use, it avoids problems with browser fingerprinting recognizing Debian users. It also allows you to have a changable Firefox profile like people are used to, however it will get reset with each upgrade.

I went ahead and made a proof-of-concept that works great: https://github.com/micahflee/torbrowser

Here's the launcher script: https://github.com/micahflee/torbrowser/blob/master/torbrowser-bin

This package I made also includes a "Tor Browser" application launcher that uses the TBB icon to show up in the desktop manager application menu. Could this work?

I posted about this to tor-talk but haven't heard any feedback: https://lists.torproject.org/pipermail/tor-talk/2013-January/027090.html

Trac:
Cc: proper@secure-mail.biz, intrigeri@boum.org to proper@secure-mail.biz, intrigeri@boum.org, micahflee@riseup.net

Trac:
Cc: proper@secure-mail.biz, intrigeri@boum.org, micahflee@riseup.net to proper@secure-mail.biz, intrigeri@boum.org, micahflee@riseup.net, tom+tor-trac@mozilla.com

On tor-talk I finally got some feedback: https://lists.torproject.org/pipermail/tor-talk/2013-January/027165.html

The concerns were about 1) what about home dirs that are shared between i386 and amd64 architectures; 2) handle home directories that are mounted noexec; 3) this doesn't clean up after itself; and 4) there isn't a persistent Firefox profile.

I've never heard of 1 ever happening, and 2 is an edge case that would be good to handle but already isn't supported by TBB. 3 is easy to fix, and 4 also already isn't supported by TBB.

However, a lot of this could be fixed if the TBB could be executed from /usr/lib/torbrowser, and just the Data directory could be in ~/.torbrowser. So I started making this work. It's in a solution2 branch on my git repo:

https://github.com/micahflee/torbrowser/tree/solution2

I got tor and vidalia working fine, but when vidalia opens firefox it doesn't seem to pass in the correct profile directory. I didn't have time to fix it yet, but I'm confident that this is possible, and solves all of the issues above. If anyone else wants to take a look, pull requests are welcome. Otherwise I'll get it working soon.

The first solution, just extracting the TBB tarball to ~/.torbrower, is still available in the solution1 branch:

https://github.com/micahflee/torbrowser/tree/solution1

Another idea I had is to make the Tor Browser launcher script a GTK program that asks for you language the first time and then downloads the correct tarball.

Additional feedback would be great. I'm not even certain that any Tor developers are interested in this approach.

For the record, I have never had any issues with 4 (the profile directory issue). Simply extracting a new TBB tarball over the old directory updates everything and preserves the Data directory. It does reset any prefs you change, but we're working on that independently (#3944 (closed)).

You don't want to go the other way (copying old Data directory over new TBB extraction) as you'll destroy addon updates and pref changes from the new TBB version.

But the /usr/lib/torbrowser option seems better. Normally, we'd frown upon that because it leaves traces of TBB outside a single contained directory on the filesystem, but you're already committing to that with a .deb anyway. You will have to update the user's Data/ directory in each homedir somehow during update, though. Again: overwriting old with new is fine. Overwriting new with old is bad.

Thanks Mike, that's good to know.

I've been thinking about this a lot. Although solution 2 is more Debian-like, I feel like solution 1 is much cleaner. With solution 1 there's no need to modify the config files and undo a lot of work that has been to make TBB portable. But I also understand that it's not really the right way to package software.

So I decided to start working on a completely separate piece of software called Tor Browser Launcher, which is a program that helps you download, upgrade, and run TBB. It's not functional yet, but code so far is here: https://github.com/micahflee/torbrowser-launcher

The way GNU/Linux users are supposed to use TBB is by downloading the correct tarball for their architecture and language, extracting it somewhere (probably in their home directory, unless they want to keep it on a USB stick or something), and running it by executing start-tor-browser. Tor Browser Launcher can just handle all of this for the user.

It won't be bundled with any TBB tarballs (it will download them as needed), and it will have a GTK interface when needed to help users download it for the first time or download upgrades. It will extract TBB into a different dir depending on architecture and language, so if someone wants to mount the same home dir on multiple architectures it will work fine. It will also extract upgrades over the previous versions, so bookmarks can get preserved.

I'm also writing it in such a way that it can indeed get included in Debian.

So I decided to start working on a completely separate piece of software called Tor Browser Launcher, which is a program that helps you download, upgrade, and run TBB. It's not functional yet, but code so far is here: https://github.com/micahflee/torbrowser-launcher

Maybe no need to duplicate that effort.

I completed such a script for Whonix. The one in the stable branch is well tested by many people. (Failed once when tpo forgot to update the changelog.) The one in the untested_adre branch is well tested by me.

https://github.com/adrelanos/Whonix/blob/untested_adre/whonix_workstation/usr/local/bin/torbrowser

It can be used as a cli application or with a zenity gui. Also verifies the gpg keys. (Which are better downloaded at build time, not at download time, because of keyserver failure sometimes.) (The code for gpg key download at download time, through Tor time or in the clear, is still in the git log.)

Right now the script is a bit Whonix specific but if you are interested it could be easily mainstreamed. It can either download through Tor or in the clear.

I would be very happy to help with the download, gpg verify and and install script, to let someone else takeover maintenance ship and to see it landing in Debian. License is GPLv3+, but you could talk me into using BSD two clause or even public domain (CC0) or so if required.

You can contact me here or by e-mail if you have questions or requests for that script.

adrelanos at riseup dot net

Trac:
Cc: proper@secure-mail.biz, intrigeri@boum.org, micahflee@riseup.net, tom+tor-trac@mozilla.com to proper@secure-mail.biz, intrigeri@boum.org, micahflee@riseup.net, tom+tor-trac@mozilla.com, adrelanos@riseup.net

FYI: We've now got a patch for #3944 (closed) (the prefs update overwrite issue) which I plan to get into FF17-ESR TBBs (currently TBB-alpha, but soon to become TBB-stable in a week or two). Once that is merged, directly overwriting an old TBB dir with a new tarball extraction shouldn't have any remaining user-visible impact.

Replying to proper:

So I decided to start working on a completely separate piece of software called Tor Browser Launcher, which is a program that helps you download, upgrade, and run TBB. It's not functional yet, but code so far is here: https://github.com/micahflee/torbrowser-launcher

Maybe no need to duplicate that effort.

I completed such a script for Whonix. The one in the stable branch is well tested by many people. (Failed once when tpo forgot to update the changelog.) The one in the untested_adre branch is well tested by me.

https://github.com/adrelanos/Whonix/blob/untested_adre/whonix_workstation/usr/local/bin/torbrowser

It can be used as a cli application or with a zenity gui. Also verifies the gpg keys. (Which are better downloaded at build time, not at download time, because of keyserver failure sometimes.) (The code for gpg key download at download time, through Tor time or in the clear, is still in the git log.)

Right now the script is a bit Whonix specific but if you are interested it could be easily mainstreamed. It can either download through Tor or in the clear.

I would be very happy to help with the download, gpg verify and and install script, to let someone else takeover maintenance ship and to see it landing in Debian. License is GPLv3+, but you could talk me into using BSD two clause or even public domain (CC0) or so if required.

You can contact me here or by e-mail if you have questions or requests for that script.

adrelanos at riseup dot net

That script looks great. Would you be into helping incorporate all of that into Tor Browser Launcher and make it more generic to work on any deb-based distro?

I'm writing the launcher in python so I can easily make a GTK user interface, but I wouldn't mind calling out to bash to do much of the work. Or just re-implementing the same stuff in python.

Any help with the gpg verify part would be great. I'd also like to make this really user friendly, with a GUI progress bar for the downloads. I'd also like to figure out a way to optionally download TBB tarballs over Tor, but that would require Tor being installed system-wide, and the Tor Project recommends installing tor from deb.torproject.org instead of the Debian/Ubuntu repos, so it could be tricky.

Would you be into helping incorporate all of that into Tor Browser Launcher and make it more generic to work on any deb-based distro?

I make it work on Debian and I think a test on Ubuntu will show that it works as well. Don't know about other distros.

We need some design decision...

gpg:

a) Ship the gpg keys with the deb package and the packager keeps the keys updated? Or, b) hardcode the gpg fingerprints and download it from the keyserver? c) somehow magically phrase the tpo verification page

I think b) and c) are just more likely to break.

a) and b) are equally secure. - The maintainer can hardcode a legit key or a legit fingerprint.

I prefer a), because if a keyserver is offline this causes lots of support requests or it would have to fallback to other keyservers from the pool. Does Debian policy allow to ship the public keys with the package?

A clean solution would be: #5606 (closed): "deb package with all torproject.org signing pgp keys" - but that requires help from tpo.

...or the TBB bundles get signed with the tpo archive signing keys instead of the individual account holders.

Dependencies:

What should the script depend on? Is curl fine? I like curl because it can enforce https with TLS. Is a dependency on bash ok with Debian policy? I'd hate caring about sh compatibility.

Download through Tor:

Download through Tor or clearnet? Download through Tor to allow obfsproxy (or similar) users to hide that they are using Tor? Download through Tor is a bit difficult so or so, since it would require Tor to be installed and another instance of Tor comes with the TBB package. Downloading Tor with apt-get wouldn't hide Tor anyway. I think it probable should download through clearnet unless someone has a better idea.

Debian policy:

Debian is against code duplication... So the script itself wouldn't be a code duplication, but the result download would result in duplicate code for Firefox and Tor. I personally find this policy odd and there should be exceptions.

Progress bar:

The script already has a zentiy progress bar, which generally works well. Unfortunately it stops at 50% because I didn't manage to phrase the curl progress bar to output usable by zenity. Can you help out here?

Once this is decided I could remove the Whonix specific parts. Shouldn't take long.

Replying to proper:

gpg:

a) Ship the gpg keys with the deb package and the packager keeps the keys updated? Or, b) hardcode the gpg fingerprints and download it from the keyserver? c) somehow magically phrase the tpo verification page

I like a) the best. It seems simple and unlikely to break.

A clean solution would be: #5606 (closed): "deb package with all torproject.org signing pgp keys" - but that requires help from tpo.

...or the TBB bundles get signed with the tpo archive signing keys instead of the individual account holders.

https://www.torproject.org/docs/signing-keys.html.en says "Erinn Clark (0x63FEE659) signs the Tor Browser Bundles, Vidalia bundles, and many other packages."

I think it would be fine to include Erinn's public key in the package, and have the downloader also download and verify the sigs (like https://www.torproject.org/dist/torbrowser/linux/tor-browser-gnu-linux-x86_64-2.3.25-2-dev-en-US.tar.gz.asc). If Erinn ever stops signing the TBB tarballs, we can update Tor Browser Launcher and include the new signing key.

Dependencies:

What should the script depend on? Is curl fine? I like curl because it can enforce https with TLS. Is a dependency on bash ok with Debian policy? I'd hate caring about sh compatibility.

I think curl is fine. I don't know about bash dependency and Debian, but I think it's fine to start with it and if it turns out to be an issue refactor bash out of it.

The GUI stuff I've been programming depends on python-gtk2. I've never used zentity before, and that might be a simpler approach. I guess that's a design decision to make too:

a) Do it all in python b) Do it all in bash and reuse much of the Whonix code c) Use both python and bash

I like the idea of using python and GTK because then we can have nicer user interfaces. Like, a choose your language dropdown if we want it, and we can build more of a wizard interface for first run and upgrades. However, maybe zentity can do everything we need, and it might simplify things.

Also, it's easier to do some logic, such as automatically determining which language to use, in python than bash (and that's logic that I've already committed to the repo).

Download through Tor:

Download through Tor or clearnet? Download through Tor to allow obfsproxy (or similar) users to hide that they are using Tor? Download through Tor is a bit difficult so or so, since it would require Tor to be installed and another instance of Tor comes with the TBB package. Downloading Tor with apt-get wouldn't hide Tor anyway. I think it probable should download through clearnet unless someone has a better idea.

I agree, we should download it without Tor. Maybe in the future downloading through Tor can be added if we come up with a good way.

Debian policy:

Debian is against code duplication... So the script itself wouldn't be a code duplication, but the result download would result in duplicate code for Firefox and Tor. I personally find this policy odd and there should be exceptions.

I think this project arguable doesn't count as code duplication. Or at least, there's a good argument that this doesn't count.

Progress bar:

The script already has a zentiy progress bar, which generally works well. Unfortunately it stops at 50% because I didn't manage to phrase the curl progress bar to output usable by zenity. Can you help out here?

I only briefly read through the script, but I should try actually running it and see how it looks.

Once this is decided I could remove the Whonix specific parts. Shouldn't take long.

The other decision to make is the directory structure. Here's what I'm thinking:

$HOME/.torbrowser -- all Tor Browser Launcher files live here $HOME/.torbrowser/version -- text file with current installed version $HOME/.torbrowser/download -- where tarballs get downloaded to $HOME/.torbrowser/tbb/ARCH/LANG -- where TBB gets extracted to

So running, for exmaple, ~/.torbrowser/tbb/x86_64/en-US/start-tor-browser would launch it for me. And as long as I'm still using x86_64 and my language is still en-US, updates would overwrite that.

Each time torbrowser-launcher gets run it checks it's hardcoded TBB version against what's in ~/.torbrowser/version to see if an update it required.

Does this seem reasonable?

And of course all the GUI stuff should be localized into all the languages supported by TBB as well.

I've been spending a lot of time on this and have to get back to other work. If you want to clone my existing repo and make it work more with bash and zenity, I'll gladly merge your work back in.

What about Whonix and/or Tails compatibility?

Alexandre Allaire (0x4279F297) and Sebastian Hahn (0xC5AA446D) sign Obfsproxy Tor Browser Bundles, and sometimes Sebastian signs the Tor Browser Bundles.

So we should include these two keys as well.

I've never used zentity before, and that might be a simpler approach. I guess that's a design decision to make too:

Or not. Zenity is too limited. Can't really make powerful gui's. A python gui will be much better.

Do you believe a CLI interface should remain?

a) Do it all in python

Fine with me, but I don't speak it.

b) Do it all in bash and reuse much of the Whonix code

Also fine with me.

c) Use both python and bash

Also fine with me. :)

Also what about obfsproxy bundles?

I am still not sure if the new way, the download script, is the better way to do. Trying to grasp the major cons of the "real package solutions". I am sure the profile error can be fixed.

Commenting on https://github.com/micahflee/torbrowser/blob/master/torbrowser-bin

Things like mv $DATA_DIR/Tor/torrc $DATA_DIR/Tor/torrc.bak might not be required.

If the start-tor-browser gets patched, a standalone Tor Browser version can be made of the script. See https://github.com/adrelanos/Whonix/blob/untested_adre/whonix_workstation/usr/local/share/whonix/start-tor-browser for the patched version. It also doesn't have the profile error.

Checking https://github.com/micahflee/torbrowser ...

https://github.com/micahflee/torbrowser/commits/master/start-tor-browser - when upstream cooperates there will be no need to modify that file. Could be solved with a environment variable, marker file or so.

https://github.com/micahflee/torbrowser/blob/master/torbrowser - "I started out making trying to modify start-tor-browser with a bunch of grep and sed, but it got really hacky..." - same here. The required changes could be up streamed with if - then.

I believe if there is a profile error in https://github.com/micahflee/torbrowser/blob/master/start-tor-browser it can be fixed see: https://github.com/adrelanos/Whonix/blob/untested_adre/whonix_workstation/usr/local/share/whonix/start-tor-browser

Any issues left?

You still need to either bundle a TBB tarball with the package, or have the launcher script download one. And the big issues I see with bundling a TBB tarball in a .deb are:

It is pretty hacky.
It won't get approved by Debian, because "The Debian policy states that a package should not contain any embedded code copy. So simply shipping the result of TorBrowserBundle build is not an option."
There are different TBB tarballs for each architecture and language. Since TBB for GNU/Linux supports 2 architectures and 14 languages, if we wanted a single package that shipped all the tarballs (which obviously would be insane), it would need 28 tarballs, and take up about 868mb.

As long as we're basing this off of already published TBB tarballs, I think we'd have to build a download system.

However this could be significantly less hacky, avoid the not getting in Debian problem, choose languages dynamically, etc., if we could build it off of a TBB source distribution instead.

It still wouldn't work to get in Debian unless we deal with iceweasel/iceweasel-src issues, but it might be a good solution for ending up in deb.torproject.org. The related bug, #3994 (moved), might have more reasons making this hard to end up in Debian. But I don't think having it in Debian is the very most important.

However, going forward with the Tor Browser Launcher program to help you download and update TBB avoids all of these problems, I believe could make it into Debian, and seems a lot simpler, and also doesn't require getting any changes in upstream.

14 languages

Actually the differences in the language packages are minor. If I remember correctly it's only about adding a language addon.

Getting this into Debian as a real package (non-downloader) is a lost cause anyway due to the anti code duplication and no-dotfiles policy. The TBB profile folder has no right for existence the Tor Browser would have to create it after starting - this would require getting many patches merged by Mozilla and they are neither interested nor review patches at a reliable speed.

But maybe one thing could be done for Debian... A package called "add torproject.org deb repository and torproject.org signing key"? So as first step the user could install the deb package, update package lists, then install Tor Browser form tpo repository.

Replying to proper:

14 languages

Actually the differences in the language packages are minor. If I remember correctly it's only about adding a language addon.

Yeah, but those differences are included in 14 different tarballs. To deal with this, we could bundle it with just one tarball and the 14 different language addons, and then after setting up someone's ~/.torbrowser/ folder copy in the correct language addon. But it definitely adds complication.

Replying to proper:

Getting this into Debian as a real package (non-downloader) is a lost cause anyway due to the anti code duplication and no-dotfiles policy. The TBB profile folder has no right for existence the Tor Browser would have to create it after starting - this would require getting many patches merged by Mozilla and they are neither interested nor review patches at a reliable speed.

My solution 2 above (https://github.com/micahflee/torbrowser/tree/solution2) doesn't require any dotfiles that it doesn't create on it's own. If you don't have a ~/.torbrowser, it creates it for you and then copies the TBB Data folder into it and slightly modifies it.

But the code duplication is a problem, since TBB obviously shares code with iceweasel.

I have a working (and pretty polished) first version of Tor Browser Launcher. The code is all here: https://github.com/micahflee/torbrowser-launcher

Here are screenshots, and descriptions of each step: http://imgur.com/a/Mvpwl

Here's how it works:

~/.torbrowser/download/ -- where TBB .tar.gz and their signatures get downloaded to ~/.torbrowser/gpgtmp/ -- a directory to temporarily use to verify TBB signatures ~/.torbrowser/tbb/ARCHITECTURE/tor-browser_LANGUAGE/ -- where TBB gets extracted to

When you run, if TBB isn't installed it downloads the .tar.gz and the .tar.gz.asc and verifies the signature. If the signature is good, it extracts and then runs. If the signature is bad, it displays an error with the option to re-download.

If TBB is installed, it just runs it.

If TBB is out of date, it pops up an interface to download the update, then verifies it, extracts it, and runs it. It extracts it over the old TBB directory, so bookmarks get preserved.

Getting TBB by apt-get installing torbrowser-launcher will be a more secure way of install TBB also, since it verifies the signature. My guess is barely anyone manually verifies the signature.

I think this could get accepted into Debian.

Right now, Tor Browser Launcher knows what version the current version is because it's hard-coded in the source code. That means each time a new version comes up, I'll need to update Tor Browser Launcher with the new current version, and there will be a gap between the time that TBB gets released and the updated package lands in Debian. That isn't good.

I have an idea for how to fix it, but it will require the TBB maintainers to update a file at torproject.org that states the current version and maybe a timestamp. It could be something like https://www.torproject.org/download/current_version, and possibly also a signature of that file.

If this could happen, then Tor Browser Launcher wouldn't need constant maintenance. It could just check for the current version each time it starts. Of course, the request that checks for the current version wouldn't go over Tor.

But if there were a consistent way to check for the current version it would be possible to actually download updates over Tor without requiring an extra tor dependency. I could write a Tor Browser Launcher Firefox extension. After extracting the tarball, I can install the extension into the Firefox profile. All it will do is, as soon as you launch TBB, check to see if there are updates available (over Tor). If there are, it can popup an update dialog. Then, this extension can download the new .tar.gz and .tar.gz.asc files, put them in ~/.torbrowser/download, and then ask you to restart. After restarting, the launcher could verify the signature, extract, and run the new version.

Do you think this current version file is something Tor Project could maintain?

Screenshots look good!

Can you add sebastian's key please? The verify page says he sometimes also signs the builds.

    if 'Good signature' in output:

Not sure if that opens up for anything weird. gpg has exit codes.

A different example, clearsign a file, tamper with the clearsigned file and the gpg --decrypt.

$ gpg --decrypt xx.asc 
Good signature
f
gpg: Signature made Mon Feb 18 04:57:51 2013 UTC
gpg:                using RSA key 0x9C131AD3713AAEEF
gpg: BAD signature from "adrelanos <adrelanos at riseup dot net>" [ultimate]

In this case matching Good signature wouldn't be good. Doesn't work in this case, just wanted to note, that reading the exit codes is better.

heya micah - I've added some commits to a git repo locally. I'll read everything over and suggest some improvements. I think overall that your approach is reasonable and if we start with what you have, we should use it as a base for future iteration.

As a side note - does anyone know if it is possible to make a deb that is signed in a way that includes the signature internally? Basically, a way to make dpkg open a deb but only install it if it is signed? like .sdeb or something similar?

I think I found a security bug: https://github.com/micahflee/torbrowser-launcher/issues/1

That bug is actually: https://github.com/micahflee/torbrowser-launcher/issues/1

Micah - I've pushed a few minor branches to my github:

https://github.com/ioerror/torbrowser-launcher/branches

It's my first pass and it was very quick. Something to get it started:

Counting objects: 34, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (29/29), done.
Writing objects: 100% (29/29), 11.86 KiB, done.
Total 29 (delta 17), reused 1 (delta 0)
To git@github.com:ioerror/torbrowser-launcher.git
 * [new branch]      codereview -> codereview
 * [new branch]      doc-formatting -> doc-formatting
 * [new branch]      gpg-keys -> gpg-keys
 * [new branch]      image-fixups -> image-fixups

Replying to micahlee:

I'd also like to figure out a way to optionally download TBB tarballs over Tor, but that would require Tor being installed system-wide, and the Tor Project recommends installing tor from deb.torproject.org instead of the Debian/Ubuntu repos, so it could be tricky.

Not in my understanding. Please read https://www.torproject.org/docs/debian again. "Do not use the packages in Ubuntu's universe. In the past they have not reliably been updated. That means you could be missing stability and security fixes." that's about it.

Replying to proper:

Screenshots look good!

Can you add sebastian's key please? The verify page says he sometimes also signs the builds.

{{{ if 'Good signature' in output: }}}

Not sure if that opens up for anything weird. gpg has exit codes.

A different example, clearsign a file, tamper with the clearsigned file and the gpg --decrypt.

{{{ $ gpg --decrypt xx.asc Good signature f gpg: Signature made Mon Feb 18 04:57:51 2013 UTC gpg: using RSA key 0x9C131AD3713AAEEF gpg: BAD signature from "adrelanos " [ultimate] }}}

In this case matching Good signature wouldn't be good. Doesn't work in this case, just wanted to note, that reading the exit codes is better.

Thanks, I added a bug for this here: https://github.com/micahflee/torbrowser-launcher/issues/3

Replying to ioerror:

Micah - I've pushed a few minor branches to my github:

https://github.com/ioerror/torbrowser-launcher/branches

It's my first pass and it was very quick. Something to get it started:

Thanks! I've been opening new issues on github for things that need to be done. So I'll look through those branches and add new issues as needed. You're welcome to also.

Replying to ioerror:

Micah - I've pushed a few minor branches to my github:

https://github.com/ioerror/torbrowser-launcher/branches

It's my first pass and it was very quick. Something to get it started:

{{{ Counting objects: 34, done. Delta compression using up to 4 threads. Compressing objects: 100% (29/29), done. Writing objects: 100% (29/29), 11.86 KiB, done. Total 29 (delta 17), reused 1 (delta 0) To git@github.com:ioerror/torbrowser-launcher.git

[new branch] codereview -> codereview

[new branch] doc-formatting -> doc-formatting

[new branch] gpg-keys -> gpg-keys

[new branch] image-fixups -> image-fixups }}}

I've merged the changes into the develop branch from doc-formatting, gpg-keys, and image-fixups. And I've opened bugs for issues you pointed out in codereview:

https://github.com/micahflee/torbrowser-launcher/issues/9 https://github.com/micahflee/torbrowser-launcher/issues/1 https://github.com/micahflee/torbrowser-launcher/issues/3 https://github.com/micahflee/torbrowser-launcher/issues/10 https://github.com/micahflee/torbrowser-launcher/issues/11

Set all open tickets without a severity to "Normal"

Trac:
Severity: N/A to Normal

Isn't this fixed now that there is the launcher?

Trac:
Sponsor: N/A to N/A
Reviewer: N/A to N/A

No, it's not. It's a different thing. The absence of a deb is a major complication for deb based operating systems for both users (inconsistent installation, update and integrity verification process) as well as for linux distribution maintainers (I am a maintainer of Whonix).

Hah, I inherited flasmark's cc...

Trac:
Cc: proper@secure-mail.biz, intrigeri@boum.org, micahflee@riseup.net, tom+tor-trac@mozilla.com, adrelanos@riseup.net to proper@secure-mail.biz, intrigeri@boum.org, micahflee@riseup.net, adrelanos@riseup.net

We don't have plans to pick this up, but maybe someone from the community...

Trac:
Component: Applications/Tor bundles/installation to Community

unassigning from myself.

anarcat, I just saw this ticket and saw that you are tracking #3994 (moved)

They seem to be related?

Trac:
Cc: proper@secure-mail.biz, intrigeri@boum.org, micahflee@riseup.net, adrelanos@riseup.net to proper@secure-mail.biz, intrigeri@boum.org, micahflee@riseup.net, adrelanos@riseup.net, anarcat

Trac:
Cc: proper@secure-mail.biz, intrigeri@boum.org, micahflee@riseup.net, adrelanos@riseup.net, anarcat to proper@secure-mail.biz, intrigeri@boum.org, micahflee@riseup.net, adrelanos@riseup.net, anarcat, boklm

They seem to be related?

As mentioned earlier here, the point of this ticket is to get a package on deb.torproject.org, while #3994 (moved) is about getting it in debian proper.

I'm not sure why/if we should keep those tickets open if no one is working on them, that said...