Apparently gwrap will not compile with guile-2.2 [1], even though the
news for version 1.9.15 says it "allows" Guile 2.2 [2]:
> it will _not_ compile using 2.2
Furthermore, it seems like it isn't being developed anymore either [1]:
> Also note that g-wrap itself is not being further developed anymore,
> it is recommended for new projects to use Guile's dynamic FFI.
Also, guile-gnome-2.16.5 is apparently compatible with guile-2.2 [3],
but I'm not sure how they built it with guile-2.2 because gwrap 1.9.15
(latest release) apparently doesn't build with guile-2.2. (And certainly
when I try to build gwrap 1.9.15 with guile-2.2 it doesn't work. Maybe
it can be made to work with certain compile flags, but I haven't pursued
that further due to [1] anyway.) This is why guile-gnome is still on
2.16.4 here. Because, although 2.16.5 can still (apparently) build with
guile-2.0.14, guile_2_0 is only at guile-2.0.13.
So to update guile-gnome to 2.16.5, guile_2_0 would first have to be
updated to 2.0.14.
[1]: http://lists.nongnu.org/archive/html/g-wrap-dev/2016-08/msg00001.html
[2]: http://www.nongnu.org/g-wrap/news.html
[3]: https://www.gnu.org/software/guile-gnome/news.html
The original browser bundle expects to run from a bundled directory,
typically under user's home. This version creates a firefox distribution
with preloaded extensions and settings that functions more like an
ordinary firefox installation.
The approach used here could be generalized to allow specification of
custom firefox distributions. Eventually, the code will be factored so
that the tbb is just an instance of that more general construct (firefox
base + extensions + prefs).
Currently, we use the latest upstream versions of extensions and so on.
Eventually we want to track the upstream bundle more closely and ideally
use the exact same inputs (firefox source, extension sources).
To avoid mixing up profile data, all runtime state is stored under
$XDG_DATA_HOME/tor-browser.
Major TODO items
- Pluggable transports
- Upstream TBB version parity
- Avoid fetchgit
- Build NoScript from source (no upstream source repo, however, must rely
on third-parties)
- Improved notation for packaging extensions
- Feature parity with the binary bundle (apulse and runtime purity, in
particular)
Add testssl.sh which is a nice utility for testing TLS/SSL
capabilities of servers without having to use any kind of
web-service. It's very useful for testing setups of services before
deployment and such.
