Remove 192.0.0.0/24 from rebinding prevention list
ipv4only.arpa resolves to 192.0.0.170 and 192.0.0.171. This is required for DNS64 prefix detection (RFC7050).
|1 day ago|
|.github/ISSUE_TEMPLATE||5 months ago|
|Keywords||1 year ago|
|Mk||5 days ago|
|Scripts||9 months ago|
|contrib||3 months ago|
|src||5 hours ago|
|work||3 years ago|
|+POST_INSTALL||7 months ago|
|+PRE_DEINSTALL||1 year ago|
|.editorconfig||2 years ago|
|.gitignore||1 year ago|
|CONTRIBUTING.md||3 months ago|
|LICENSE||1 week ago|
|Makefile||4 days ago|
|README.md||1 year ago|
|plist||2 weeks ago|
|ruleset.xml||4 months ago|
The OPNsense project invites developers to start contributing to the code base. For your own purposes or – even better – to join us in creating the best open source firewall available.
The build process has been designed to make it easy for anyone to build and write code. The main outline of the new codebase is available at:
Our aim is to gradually evolve to a new codebase instead of using a big bang approach into something new.
To create working software like OPNsense you need the sources and the tools to build it. The build tools for OPNsense are freely available.
Notes on how to build OPNsense can be found in the tools repository:
You can contribute to the project in many ways, e.g. testing functionality, sending in bug reports or creating pull requests directly via GitHub. Any help is always very welcome!
OPNsense is and will always be available under the 2-Clause BSD license:
Every contribution made to the project must be licensed under the same conditions in order to keep OPNsense truly free and accessible for everybody.
The repository offers a couple of targets that either tie into tools.git build processes or are aimed at fast development.
A package of the current state of the repository can be created using this target. It may require several packages to be installed. The target will try to assist in case of failure, e.g. when a missing file needs to be fetched from an external location.
Several OPTIONS exist to customise the package, e.g.:
Options are passed in the following form:
# make package CORE_NAME=my_new_name
Update will pull the latest commits from the current branch from the upstream repository.
Upgrade will run the package build and replace the currently installed package in the system.
Fetch changes from the running system for all known files.
Run serveral syntax checks on the repository. This is recommended before issuing a pull request on GitHub.
Run the PSR2 and PEP8 style checks on MVC PHP code and Python, respectively.
Run Linux Kernel cleanfile whitespace sanitiser on all files.