I’ve already addressed this within the salt formula (which a certain somebody can’t seem to bother reading before postulating), policy file is created if non-existent and appended when present. As stated previously, if existing; the policy is simply updated via the tee -a (append) command. What @enmus would like is an automagical script that determines any user’s customization of policy files and modify that. Because an existing, alternately named policy file would be an indication of an “advanced user”, modifying the source to accommodate such is left up to said “advanced user”.
I already tried but, ability to edit seems to be disabled after some days. For now, I’ve done what I can to highlight the issue by changing the thread’s “solution”. I’ve already flagged it for moderation with an explanation of the desired changes. Hoping the request will be seen soon than later.
Hope constructive comments are welcome, since the tone of this thread is not that welcoming for others to comment?
Of course it is but, I probably won’t be sticking around/contributing too much longer based on the lack of moderation. It’s just holiday season so, kind of bored and trying to make myself useful somewhere. If I wanted interaction like what I’ve seen over the past few days, I’d be on 4chan.
Even if something could be read like this in what I wrote, it wasn’t my intention and I apologize. I was rather referring to official docs, for which I am sure you read it too.
You can summon @deeplow to do that for you, or better, to create wiki from the OP, so it could be modified accordingly.
You did it. I already kindly asked you not to give up. Because you have things to offer. I sincerely hope it won’t pass another 5-6 years to your next Github repo.
Again, you are continuing with your uninformed, disrespectful arrogance wasting bandwidth. If you had the wherewithal to bother implementing the solution or reading the source you would already know that the policy IS in fact updated. If any user has chosen another location for policy updates, they are free to adjust the source with their favorite text editor to achieve said goal.
What you did is suggest is that a solution wasn’t in place which, in fact is which, you would know if you posted based on understanding & comprehension as opposed to uniformed ignorance.
As I and many others have asked you countless time publicly & privately, STOP posting without value.
Trust me when I make it clear to you that you are NOT a motivator, quite literally the opposite.
Hmm checked both codebases quickly and it seems that @unman’s implementation is actually never calling in.sh script to open up ports.
I got curious, on my phone here waiting for christmas people to arrive and checked, but trying (failing now) to get away of screen for a forced retreat.
But I might try both implementations.
The thing I like about unman’s approach is that even if he said he would never package salt recipes, he’s actually doing it. What makes it amazing is that one can actually (not for i2p now as said above) normally install/uninstall/update salt policies deployed directly from dom0 which eases UX next level, which is quite needed now. Its nice to simply read a spec file to understand what salt recipes are called, how and when to quickly jump into the recipes themselves and then inspect code and do review online.
As said I will try to take the time to test both implementations. I’m getting sick of tor for personal reasons and would love alternatives to get more accessible. And those projects are exactly that.
@cayce Not sure Bob and timestamps to 1999 are relevant. Other commment: I love unman"s approach with in.sh (if it was called) where http proxy only seems limited, yet again last time I played with i2p was years ago, and “play” is the right term, considering it as a toy back then. Those projects make it easier to deploy and use, if bar to deployment was eased. I would invite you to challenge unman’s implementation through github issues if you will from your common experience this i2p deployment would be definitely more solid and enjoyable from a UX perspective.
There are a few points available for hardening within the solution I posted. This being one of them.
This would have been made clear in the git Wiki by now had I not had to exhaust soooooo much time addressing your ignorance.
Yet again, you CONTINUE posting out of ignorance. The example you’ve copy/pasted from the docs speaks to a qube with the name of untrusted which, I nor others very well may NOT have implemented thus, would NOT work out of the box for many.
How a user would like to tighten this up would be something more like:
Upon initial testing this failed to work as, this convention doesn’t seem to work for source. nor did @dispvm.
Because which VM a user would like to leverage is an unknown, @anyvm was chosen as default to allow users to get up and running, leaving the exercise of the selection of which hosts to allow access to the i2p proxy.
The only threat I could imagine is malware phoning home to C2 via the i2p proxy but, this would be a task for the user’s IDS to identify. If this were the case; said user has bigger issues with supply chain than a single outbound port being poked.
Furthermore, despite the allow rule being @anyvm; the only VMs which are actually able to pass traffic successfully through the open proxy are those which have sys-i2p (now sys-i2pd) selected as the NetVM. Thus, I’m comfortable with managing the risk by only attaching this NetVM to designated minimal DispVMs.
I prefer Ansible over SaltStack for deployment management but, maybe I’ll work on adding a spec file per your request if it could improve the informed user experience. The existing install.sh/uninstall.sh ought to offer the clarity & control you are after.
I encourage you to try the solution out and provide some feedback. Thus far, for browsing it works a treat out of the box and, as I stated upthread, I’m comfortable with the threat profile.
It’s unfortunate that this thread has derailed so much. Holday season doesn’t help much. I have taken the time to read the full thread, but I haven’t explored the technical bits to verify the accuracy of comments. Thanks for the ones who flagged this discussion for moderator attention (except for the uncalled for mass flag, which clogged our moderator review queue )
My conclusion is that even though perhaps @enmus criticized some things without full justifications, some other criticisms made sense to others. As a security-focused project, adversarial criticism is a tenant of the Qubes project. For the most part @enmus has framed these positively and and used welcoming and inclusive language for your posts (which fits very much into the CoC standards)
So, from what I’ve observed, @enmus has acted in good faith. @cayce you don’t have to address every single piece of criticism especially if they come only from one person and you feel it’s just justified.
However, what do so see is that @cayce has done a considerable number of personal attacks against enmus, which actually constitute a violation of the code of conduct.
My criticism/feedback for @enmus would be to (1) slow down the responses and let others participate in the thread, (2) not demanding improvements (we’re in a FOSS environment driven in large part by volunteers – nobody owes anything to anybody – all you can do is encourage participation),
Lastly, I’d like to encourage @cayce to keep the code public and not to let one bad experience (from your perspective) with one individual, stop others from contibuting / using your contribution.
Being respectful of differing viewpoints and experiences
This one should perhaps have been framed in a more friendly manner: instead of “This is not how do it”, it should be framed as “This is not the correct way of doing X because Y, please check the docs here.”
It turns out this issue in the end was a miscommunication and @enmus was making a reference to the new Qubes policy format. However, @cayce you interpreted this as the lack of knowledge of how to append to a file. Please don’t assume malice and if someone doesn’t know something, try to educate them without the uncalled for insult (“for your enlightenment”)… Everbody here has had to learn stuff at some point. So either teach or ignore – but don’t insult for not knowing.
Personal attacks
However, I do see some condescending attacks against @enmus, which are uncalled for
Can anyone explain how the following commands to implement the policy do NOT follow the “Policy files” guidelines outlined in the referenced blog post above?
Install:
echo "qubes.ConnectTCP +4444 @anyvm sys-i2pd allow" | sudo tee -a /etc/qubes/policy.d/30-user-networking.policy
Uninstall:
sudo sed -i 's/qubes.ConnectTCP +4444 @anyvm sys-i2pd allow//g' /etc/qubes/policy.d/30-user-networking.policy
90-default.policy clearly states:
## Do not modify this file, create a new policy file with lower number in the
## filename instead. For example 30-user.policy
Are comments in the absence of investigating the “technical bits” really useful?
Most definitely.
@deeplow Moderate however you see fit (delete this and all my posts if it suits you but I appreciate @cayce contributions.) Watching the devolution of this forum is very disheartening.
)