# Inject custom firewall rules into whonix_firewall
I would be happy if we could add some suitable hook mechanism to whonix_firewall or add some if/then code to whonix_firewall to simplify that code. Sed injection doesn't look future proof. (Done.)
Create a file /etc/whonix_firewall.d/32_qubes with a content like this:
GATEWAY_IPv4_DROP_INVALID_INCOMING_PACKAGES_POST_HOOK=`/path/to/script`
Then you can add your injected rules there instead of using sed to edit /usr/bin/whonix_firewall.
Done,
provide hook after drop ipv4 invalid packages through variable GATEWAY_IPv4_DROP_INVALID_INCOMING_PACKAGES_POST_HOOK:
https://github.com/Whonix/whonix-gw-firewall/commit/5ebca43416269a5fd42c98a80af1b0b3d38adecf
I feel much better having this built into the whonix_firewall. On the surface it looks great!
What version is this slated for? I am not changing the qubes-whonix code at this point to include the fix since I am prepping it for the 9.6 release unless this will be included in that release.
Can you remove the qubes tag and move it either to qubes-next or qubes-10 (or whatever version your fix will be available in?) so at that point I will not forget to implement it?
What version is this slated for?
Whonix 10.0.0.3.2-developers-only / whonix-gw-firewall 0.8-1
I am not changing the qubes-whonix code at this point to include the fix since I am prepping it for the 9.6 release unless this will be included in that release.
Sure. I suggest creating a development git branch where such features go.
Can you remove the qubes tag and move it either to qubes-next or qubes-10 (or whatever version your fix will be available in?) so at that point I will not forget to implement it?
I think anything related to Qubes should be tagged with "Qubes". Just as a general catch all to be able to find everything ever related to Qubes.
What about a Qubes 9.6 and Qubes 10 tag?
You can create new tags using Create Task -> Create New Project. And then just add additional tags to the existing tickets which are already tagged Qubes.
Maybe a tag qubes-whonix would be useful for everything related to the qubes-whonix package.
And maybe a tag qubes-whonix 10, qubes-whonix 11 and so forth.
The tag format of Qubes 9.6 and Qubes 10 don't really seem to make sense, since it could be easily confused as a Qubes OS version.
Using qubes-whonix 9.6 etc, or just using both Qubes and Whonix 9.6 together maybe.
I prefer qubes-whonix-next for anything 9.X related
I have been used to using the -next in previous projects which is good, since items can get bumped again to -next if needed on next minor version update (remain in -next)
and
qubes-whonix-development maybe for 10.X? <-- not so sure about this one though
qubes-whonix-[10|future|proposed|unstable] ???
Unless there are other opinions, I'm fine with qubes-whonix-next.
I like qubes-whonix-future for the latter one, as the term balances conceptually with the qubes-whonix-next tag. As in "the very next .X release" versus "future major release". Or something conceptually similar to that being represented.
I find next confusing. Have more like "next major version" in mind.
What about qubes-whonix-stable and qubes-whonix-devel? The former would be for 9.6 while the latter would be for 10.x or later. Are those any worse or would those equally well work for you?
Not sure if next and future, or stable and devel would work that good. I mean, now there is the 9.6 stable release. Whonix 10 doesn't look that far away. I am already beginning to assign some tickets to the Whonix 11 tag while we are finishing the Whonix 10 milestone. Some tickets from the Whonix 10 milestone are postponed to the Whonix 11 milestone. I think versioned milestones are a lot better.
You got the last word, since it's you who maintains it. Just trying to prevent confusion by newcomers.
I can see the type of issues that Patrick is mentioning.
Versioned milestones are more explicitly meaningful, especially to other people looking in.
Also, I tried adding on these qubes-whonix-next and qubes-whonix-future tags as part of the Qubes project in the tracker and they seem to collapse their usage into the primary Qubes tag. Seems there would have to be a new dedicated project in the tracker for each? Which seems like a logically "heavy" solution.
I can also see that a next and future convention takes less time to think about making use of, instead of hunting for version numbers, needing them to already be in place for the tracker, in order to sort the way @nrgaway wants.
Long-term we should be looking towards creating a shared development process with conventions and procedures that support more people in the mix. Yet, for now, @nrgaway is taking the primary lead on code development with the qubes-whonix package and switching small conventions like this later shouldn't be too bad.
Also, I wonder if intended usage of these tags might bleed over beyond the scope of the qubes-whonix package, where other Whonix components become involved.
I also wonder if relying too much on these personal tagging conventions for the qubes-whonix package might cause you @nrgaway to miss out on other people's more generic usage of tags? Maybe predicting this requires better understanding of the tracker software.
Just expressing some thoughts that come to mind. No need to answer these. I don't have strong preferences at this time. No problem for me either way.
I'll go with whatever Patrick thinks is best. I personally do not like too much clutter when developing and prefer to have quick access to what needs to be done. If a feature is put off to the next version, I don't want to see it again until I begin working on that version. That way people will also have a better understanding when something may be implemented.
A 'develop' should work fine for any development in current release 9.X cycle then you could use the 'next' tag for 10.X+ ? Then once qubes-whonix 9.6 is officially released, action items can be moved to 'develop' if it can be foreseen to be completed in that release cycle.
Another thing to note is that the email notifications I receive do not seem to have a proper return email address so a reply can be made from email to a subject tag. The return address displays as 'noreply@phabricator.example.com' in my email reader.
Ok. I think qubes-whonix 9.6, qubes-whonix 10, qubes-whonix 11 etc. is best. Since we can add an "unlimited" amount of tags, you could always add additional tags if that helps.
I personally do not like too much clutter when developing and prefer to have quick access to what needs to be done. If a feature is put off to the next version, I don't want to see it again until I begin working on that version. That way people will also have a better understanding when something may be implemented.
The tag scheme I suggest would work for that, I think.
Another thing to note is that the email notifications I receive do not seem to have a proper return email address so a reply can be made from email to a subject tag. The return address displays as 'noreply@phabricator.example.com' in my email reader.
Created T185 for it.
On topic:
Do we need to use a hook at all? Why not just add this to whonix-gw-firewall /usr/bin/whonix_firewall for Whonix 10? It's just a short snippet. Wouldn't decrease readability of /usr/bin/whonix_firewall a lot. As long as it has a safe "if running in Qubes" mechanism (such as if [ -f /usr/lib/qubes-whonix ]; then ..., then I don't think it would be a problem.
Not using a hook has one disadvantage: firewall rules for Qubes could not be updated without updating the whonix-gw-firewall package.
You tell me which way you find better. Feel free to either use the hook or to make a pull request for whonix-gw-firewall.
I am trying to figure out how to add this to qubes-whonix 10. Any advice is welcome :)
In the upper right, click click the big + and choose project. As name, choose qubes-whonix 10 or so.
Then reload (or just go back) to this page, press edit task, and add to projects - or - above the Comments field, choose Action Associate Project and add the newly created project (tag) there.