Sorry I was in bed when you did the refactoring. I tried it and ran into an issue where the variables were not available to tb_preparation. Simply moving tb_preparation to after the argument parsing seems to work and doesn’t seem to interfere with anything else. tb_settings_folder is drawn from directories in tb-starter(/etc/torbrowser.d/) which are not hyphenated. In my fork of tb-starter I didn’t hyphenate the /etc/i2pbrowser.d folder, but if that is preferable I will. For now, I changed that so that it would find the right folder. New pull request should address all that.
tb_run_function tb_parse_cmd_options "$@"
lowest priority: tb_preparation (fallback values if below does nothing)
normal priority: tb_config_folder_parser
highest priority: tb_parse_cmd_options
Do you think we have that still?
Sorry I was in bed when you did the refactoring.
Don’t worry a thing. It’s very cool to have someone check and modify the
tb_settings_folder is drawn from directories in tb-starter(/etc/torbrowser.d/) which are not hyphenated.
No need for hypen.
Actually less and less sure if the config file /etc/torbrowser.d/ should
belong to tb-starter. It’s shared. Furthermore, the reason for a
separate tb-starter package are probably invalid by now.
(Reasons where: 1] tb-updater on Whonix-Gateway for
https://phabricator.whonix.org/T118 without a starter. But even if so -
there are better solutions - such as just using another package to
config-package-dev hide the starter than a separate package. 2]
tb-updater / tb-starter outside of Whonix used by third parties -
anondist - unlikely to happen.)
So perhaps for Whonix 15 we’d merge tb-starter into tb-updater.
I am almost sure that we do(Still function normally as before, but with additional behavior). Moving that function seemed like a potentially huge difference in how the code would work, so I read it and ran it extensively first. Regardless of when it’s called, tb_preparation sets any empty variables to the default values, but it only sets those values if they are blank or invalid because the configured setting points to a path that doesn’t exist. Because of this, and because tb_parse_cmd_options only does the argument parsing and sets things that aren’t default, as far as I can tell, tb_preparation can be called immediately after tb_parse_cmd_options without changing the behavior. No args downloads to $HOME/.tb still, gives all the same messages, and doesn’t do anything unexpected, then I tried it with various combinations of args, they seemed to work too. If it(tb_preparation) is not done after the arg parsing, it appears that the settings folder variables are set only by tb_preparation and the only settings folder which can be read is /etc/torbrowser.d. I don’t know every use case out there, but I don’t think users should notice this change from a purely behavioral perspective.
@Goldstein, please add this line to /etc/privoxy/config for future zeronet compatibility too:
forward .bit 127.0.0.1:43110
I don’t know if it fits there though, have you tested Zeronet?
- Could you please also modify the textual strings
i2psomething when using
Also would be cool to have:
/usr/bin/update-i2pbrowser - simply running
debian folder, postinst script: same mechanism as for Tor Browser (but with an additional config setting to opt-in this first)
All of this is completely optional.
New pull request has it use i2p based names when using --i2p for almost everything but wiki documentation, as that would point to dead links and the update-i2pbrowser script. I’ll do the man pages and the postinstall script shortly.
Merged. So far so perfect.
Next optional steps:
- Merge tb-starter into tb-updater.
- Share code to avoid code duplication. Perhaps a common file with shared functions (these which determine variables, parse cmd).
Hello. I know you have decided against removing features, but a couple of points.
Custom rulesets can be made in HTTPS Everywhere to force connections to eepsites, the same as with onion services. Helps to keep clearnet out of the equation. Example: attempted connections to https://geti2p.net would automatically redirect to http://i2p-projekt.i2p.
I2P uses two transports right now:
NTCP, a Java New I/O (NIO) TCP transport
SSU, or Secure Semireliable UDP
http://i2p-projekt.i2p/en/docs/transport mentions the possibility of pluggable transports and restricted routes (a la guard nodes), but the most recent changes to I2P’s trac tickets were 19 months ago and milestoned at eventually.
Good Point, its not removing features so its fine.
Great, would you like to create this ruleset ?
This isn’t something we should focus on atm, if I2P is blocked we could route it through tor and if tor is blocked I2P will be blocked too with or without pluggable transports.
I can do that. There aren’t too many eepsites with clearnet counterparts, so there aren’t many rules to make. I don’t have any coding experience, but I can paste the extension’s storage.js file with any relevant rulesets… would I aim for any parallel services, or only certain ones?
I know. I wanted to fill in some knowledge for eyedeekay, it wasn’t to imply any need for action on Whonix’s part.
Also, have there been any ideas about how to handle I2P’s (optional) incoming connections at the gateway? Doing that looks to be counter to Whonix’s design policy, but some people (like me) would want to forward them if possible.
great, any parallel service
It should work but i haven’t verified it.
I don’t think it counters Whonix design, but @Patrick probably knows best.
OK, I’ll start compiling the list.
Rulesets can be written as an xml file, but imports/exports are crippled since Firefox’s switch to WebExtension. My idea about Storage.js was no good, hopefully someone knows a way to bring the rules into the browser.
Whonix docs state that opened ports are rarely needed outside of certain use cases, such as relays or onion services. Whonix has mostly been built around Tor at this point, most use cases acting as clients.
AFAIK, Whonix hasn’t incorporated a P2P network into it’s design before this point, so it seems like certain issues haven’t really been experienced yet. I don’t know.
Related wiki page for reference only (no statement for I2P integration):
Opening ports is already easily possible in Whonix-Gateway firewall through config snipped drop-in.
Technically, there are three components here:
- Configuration an open port reachable from Whonix-Gateway side is simple.
- More difficult is how you get the port forwarded from the host to the virtualizer. Virtualizer specific. Undocumented at Whonix. Documented elsewhere for sure.
- Open the port from the - usually NAT router - to the computer running the Whonix-Gateway. Router specific. Undocumented.
Whonix default download version (as it exists at time of writing) shouldn’t ship by default with open ports by default but everything else [*] like opening ports vs not opening ports by opt-in or opt-out is up to the maintainers of this I2P integration.
[*] instructions, helper scripts, packages to install I2P integration, alternative versions [default I2P enabled] or so maybe even downloadable from whonix.org, whatever will be the result of this thread
Good to keep the custom settings in one place IMHO. No haven’t in a while but it is a long term goal on the map.
Alright, 8 eepsite-rulesets have been created. I Started with the rule sets provided by darkweb-everywhere and was able to use some other resources. I’ve (hopefully) accounted for every domain for each ruleset, I2P uses many. Rulesets all verified by HTTPS Everywhere’s ruleset debugger and all syntax should be correct.
rulesets included for:
- I2P, Syndie, and I2P’s official forum
- (2) Rocksolid BBS member sites
- a Cyrillic-language site called ‘Flibusta’
I disqualified some eepsites for various reasons.
(Forum won’t let me upload the tar.gz archive, how should I share it?)
I am aware of Chris Barry’s darkweb-everywhere rulesets, I just didn’t consider updated https-everywhere rulesets an immediate priority yet. Thanks for taking up this task, I honestly had no idea when I’d be able to get to it.
@Patrick I’ll work on all that this week. I’ve got the basics of /usr/bin/torbrowser --i2p and /usr/bin/i2pbrowser ready to go, but I’ve got to find a way to remove Tor Project related markings and ideally, I’d like to replace about:home with an informational page about how contextual identities work differently in i2p than Tor because of less automatic isolation for http clients. Also in order to do /usr/bin/i2pbrowser I need to set use_nontor_proxy from an environment variable, which might be a hard sell.
Alternatively, and this is a kind of crazy idea, but could I sidestep the need for use_nontor_proxy by implementing domain(destination in the context of i2p) isolation in a way compatible with Torbutton? If I’m understanding things correctly I think that would work? I’ve already got the hardest parts to make of such a system, basically what I would have left to build is a sort of funky control port filter that talks to i2p? It’ll take much more time but I think it might be a better solution.
Why do you need to do that? Maybe you shouldn’t focus much on the cosmetic side of things at this point.
I don’t think there’s any way around use_nontor_proxy. It’s funny you mention destination isolation with Torbutton, because I thought it would be a good idea to send a “stop” command to the HTTP client tunnel and starting a new one when pressing “New identity” on TBB. Of course, that would mean allowing the workstation access to I2P’s router console (I do hope you plan on using the Java router) which isn’t good since the router has awareness of it’s physical IP address.