Even though the source is minimal & concise for practitioners, paper tiger enmus feels compelled to regurgitate FUD filled misinformation despite failing to understand or implement this solution nor read the source. Thus, I’ll try to provide a high level overview for those who don’t know how to read and/or understand SaltStack.
A debian based template (TemplateVM) is created
A user friendly frontend to i2p services (i2pd-qt) is installed in the TemplateVM created (1)
An autostart configuration is put in place to allow the i2p frontend to start on boot
A disposable template (AppVM) is created based on the aforementioned (1) template
A disposable VM (DispVM) is created from the disposable template in (3)
This is the ONLY VM/Qube that need be activated/started in order to use
An allow rule is created in dom0 to bind the listening proxy port of the DispVM (4) to any VM/Qube.
The desired proxy port is available via localhost as if the proxy were running locally
To browse to an i2p site, as an example:
Open a browser application in your favorite disposable VM/Qube
Change the NetVM to use the DispVM (4)
Configure the http proxy setting to something like:
127.0.0.1:4444
Enter/browse to i2p URL
To browse to clearnet again, simply disable the proxy setting
Welcome to the forum and thanks for the nice contrib.
Some things to point out to users here:
This will not install i2p, but i2pd-qt (GUI for i2pd).
It will do it on debian-11-minimal.
Nothing wrong so far, but you might want to consider this and maybe to name it according to the facts.
it claims it will install debian-11-minimal from repo qubes-templates-itl-testing, while it isn’t there, but in qubes-templates-itl (only fedora-37s are in testing at the moment)
It will create sys-i2p named dispVM, will give it 512MB RAM and set sys-firewall as its netVM.
Nothing wrong so far, but you might want to consider to chain it to your(s) sys-whonix/sys-VPN prior to sys-firewall. Also you might want to consider to set additional prefs like meminfo-writer off, or appmenus-dispvm ' ', just in case.
It will create file and corespondent policy entries in 30-user-networking.policy, so if you already have your 30something policy file, you might want to consider to customize this to attach the line to your already existing custom file.
It will create a dvm-template which provides network and whose netVm will be sys-firewall.
This I don’t understand at all. What this is for? Can @cayce explain this please? What any dvm-template would provide network for? I am not claiming anything or judging, but am genuinely interested in.
Thanks once again.
A) Before voicing opinions on a solution without experience, it’s more often than not best to try the solution.
B) Since you took more time to spell out your confusion than implement this turnkey solution; let’s clear up your many misstatements for future readers …
Ought sys-firewall be renamed to sys-iptables?
This implementation provides an easy to use DispVM providing i2p routing services in a user friendly, Qubes manner. Feel free to make a PR or name whichever Qubes to your liking.
This formula clonesdebian-11-minimal to an easily identifiable name of sys-i2p-template.
I don’t quite understand what you mean by “name it according to facts” … One of the many great things about DevOps is users have the option to choose their own naming/organization schemes. Users aren’t bound to any standard with Qubes. Feel free to rename (according to whatever unnecessarily rigid standard you’ve dreamed up) via CLI, GUI or, go wild and modify the source with your favorite text editor!
I already had the debian-11-minimal template installed so, this one got past me during the test drive. That said, I’ve gone ahead and removed the fromrepo artifact. I believe debian-11-minimal is now in the main repo for both 4.0 & 4.1 so, the fromrepo specification is not necessary.
As the outbound path routing ought be chosen at the discretion the user based on the use-case at hand, sys-firewall is the best default choice. sys-VPN is not a standard; nor is sys-proxy, sys-ips, sys-wifi, sys-bluetooth, sys-gprs, sys-modem, sys-3G, sys-4G, sys-5G, sys-satcom, sys-pigeon or many of the other outbound possibilities a user may have implemented. Qubes is very flexible as, it allows users to change the NetVM easily via CLI or GUI. How a user chooses to architect the routing of their traffic is outside of scope.
The command used to add the allow policy is:
tee -a
For your enlightenment & per the man page for this command:
-a, --append
append to the given FILEs, do not overwrite
sys-i2p-dvm is never started; sys-i2p is a DispVM of sys-i2p-dvm thus, inheriting it’s properties.
Hey @cayce , thanks for your response, but I think you all got it wrong. I clearly addressed statements to you and to the users who will deploy it.
To you, I addressed only two statements:
Thanks, twice.
About dvm-template.
All other statements were for the users what to consider to customize and what to consider when deploying it.
Now, again one more for the users to consider when customizing/deploying it:
I find it extremely dangerous to allow all VMs to connect to sys-i2p over TCP without being aware of potential risks of such a decision.
And one for you, after you clarified about dvm-template.
Regardless of the fact if dvm-template is ever started or not (you never wrote of that) this is not the way how you create sys-qubes, the ones that provides network in this case.
So there’s absolutely no need to attach netVM and enable provides_network True for the dvm-template.
I clearly addressed statements to you and to the users who will deploy it.
The only thing I see you clearly addressing is your lack of experience & understanding.
I’m certain I’ve not got it “all wrong” as you’ve opinied because this is a sound working solution (which you have not implemented) that is above and beyond the one you’ve provided. It’s obvious from your statements/arguments you’re a bit of beginner with *nix, networking and threat assessment in general who’s failing miserably at flexing your technical prowess. So, I’ll say it again, implement the solution; then trash talk it, with PRs or a fork and stop derailing the conversation with your personal delusions. Welcome to computing, there is not a singular “right” way to achieve the goal, there is not and will not be a single solution that fits all user needs but, by all means go ahead and provide something better. You’re clearly a “know it all” that actually knows very little despite the exorbitant amount of time you waste on this forum, full of both yourself and misinformation whom, I haven’t the time the web-argue with.
I find it extremely dangerous to allow all VMs to connect to sys-i2p over TCP without being aware of potential risks of such a decision.
This FUD filled statement is laughable. Are you in sales or something? Please provide an example of the “extremely dangerous” scenario you are imagining. Something like the C2 traffic (from malware that’s somehow been installed on a VM that you control) being able to find it’s way outbound via the i2p http proxy port 4444?
If you think that there is some risk in consciously allowing VMs that a user has control over to contact a single outbound port on another VM which the user also has control over, you’ve clearly got bigger issues than the allow rule and, maybe it’s time for you to put down the internet altogether. You’re lack of computing experience and security experience is really loud right now.
So there’s absolutely no need to attach netVM and enable provides_network True for the dvm-template.
sys-i2p-dvm is an AppVM which serves as a template for disposable which is NEVER used. It’s sole purpose is to provide the template for the sys-i2p DispVM. To assist you in your neurosis about the “right” way to “do it”, what YOU want to do with YOUR fork is apply the NetVM & Provides Network settings on the DispVM. But, you’d have to understand SaltStack to do that.
So there’s absolutely no need to attach netVM and enable provides_network True for the dvm-template.
For this use-case, there’s absolutely no reason not to; aside from appeasing you. Thanks for playing!
Thanks for derailing the entire post to make it about your (incorrect) self but, that seems to be all you do here.
Good thread, and I appreciate some work on sys-i2p. However why the passive-aggressive stance towards @enmus ? As far as I can tell from reading this thread here, he is being hospitable to your work.
@tanky0u Not passive at all, 100% aggressive against valueless, uneducated, uninformed FUD.
@MrA Meaning well and doing well are very different things. Ask any Native American (or countless populations around the globe) how the “well meaning” efforts of invaders has worked out.
@enmus
Misinformation will do that, especially when something of value is offered to a community in good faith free of charge. That a Kali “user” like yourself doesn’t even understand the -a flag of the tee command baffles me.
I find it extremely dangerous to allow all VMs to connect to sys-i2p over TCP without being aware of potential risks of such a decision.
Hey @cayce, I just think I wasn’t clear enough (I won’t say you didn’t understand my remark) with
I said here, if the user have 30_user.policy, instead creating additional file with your script, she could customize your script and put there 30_user.policy instead. This is indeed trend with new Qubes RPC policy system - to have them all in one file.
I hope I clarified now what was written there.
It is good that you edited OP to give people some more info, since lacking this initially and on Github, I tried to do it in a way in my first post here.
I will not respond anymore on this, until I create and publish sys-i2pd.
Totally my fault for affording you the benefit of doubt that you could read.
Won’t be holding my breathe, I’m certain that someone of your caliber won’t provide a more usable solution. When you do copy left, be sure to publish with attribution per the license terms.
Could you also publish sys-iptables & sys-usbipcore? Ya know, just to be thorough for clarity.
The package (spec file in parent dir) is still missing (so package is not yet published) but I was wondering (have not compared solutions, just read this thread) of the differences between implementations from @unman’s implementation with this sys-i2p?
I hadn’t seen @unman work on this until now so, thanks for this @Insurgo! I’ve only reviewed Unman’s solution quickly now so, apologies in advance if there’s any misstatements following …
The fundamental difference being the QT GUI frontend built from source pulled from github via autostart which is leveraging i2pd in order to support on-the-fly config changes for those that enjoy extra dock icons. From the looks of things, Unman’s implementation uses i2p from the official debian repos of the i2p project supplemented with firefox-esr to provide a frontend. Additionally, this implementation uses RPC allow rule(s) to support TCP connectivity while, Unman’s uses nft/iptables rules. As well, I’m sure I’ve missed a few things.
That said, Unman is THE man and, I’ve got nothing but respect and gratitude for dude. He’s a legend for sure. I trust his work over mine any day so, I’ll probably see how I can make improvements or ditch it altogether depending on how useable Unman’s is for me.
In lieu of Unman’s effort, the project/repo have been renamed to sys-i2pd in order to avoid confusion. Most references to i2p within this thread, made by myself can effectively be replaced with i2pd (ie: sys-i2p would become sys-i2pd).
Great! Things are definitely getting better and improving. Two more left. I hope they’ll come soon, so users in the know wouldn’t need to customize them themselves (dvm-template and policy). Thanks again for this nice and quick solution.
Two more what? Please STOP posting in this thread before you’ve tested the solution and without value. From the handful of days I’ve been signed up on this forum, I’m amazed that moderators let you sink the overvalue time and time again.
If I understand @enmus points, outside of trying to interpret FUD or jump in non-constructive criticism, without having tested your solution nor @unman and having passed literally less then 5 minutes comparung codebases:
@cayce this would be @enmus first point (I agree with this one if an additional policy file is created instead of modifying central 30 user policy file. Otherwise it created confusion for other projects already which I guess is base of what I see as constructive criticism) .
@cayce that would be @enmus second criticism which without testing/deeper review, I cannot comment on as of now. But my curiosity is poked, I will do check and comment later. Hope constructive comments are welcome, since the tone of this thread is not that welcoming for others to comment?
This contribution is welcome @cayce ! No doubt there!
Edit: @cayce you should modify links in OP to point to renamed project
From the looks of things, Unman’s implementation uses