Menu

Release of KMyFirewall 1.0beta1

Release of KMyFirewall 1.0beta1

Important: As the file format used to save the rulesets has changed, rulesets
created with KMyFirewall < 1.0beta1 WILL NOT work, don't even try it!

During the last year KMF has been completely rewritten in order to be even more
flexible and on the other hand easier to use.

New plugin framework

Most parts of the application has been rewritten introducing a plugin framework
that allows to add new IPTables rule option editors to be written within a few
hours (well maybe days depends on the options complexity :). This will allow
us (and contributors) to easily implement the fast growing number of IPTables
ruleoptions without the need of understanding the whole application.

The backend generating the IPTables rules itself has been extended to allow the
registration of new rule options by defining them in an XML description file.
For a detailed description about how to write such plugins have a look at the
application handbook in the current CVS version. So feel free to contribute
plugins, there are lots of options still not implemented.

New Easy-To-Use platform independent interface

As I often got mails complaining about the to complex nature of KMF and the
very limited possibilities the wizard provides i simply removed the wizard and
implemented a completely new interface.

Features of the new Interface

As the new interface works on an abstract descrioption of the generated rules
the new plugin structure allows us top implement script compilers that support
other firewalling backends than just netfilter/iptables.

To support a new tool kit it is required to write a compiler and an installer
plugin for the new framework. Currently just the iptables/linux compiler and
installer is implemented. As with the rule option plugins of the IPTables
interface it shouldn't bee too much work to develop those plugins.

IPTables vs. Generic interface

The main difference between those two interfaces is that the new Generic
Interface is OS and toolkit independant while the IPTables interface is an
improved version of the well known KMF GUI and therefore tight bound to the
netfiler/iptables toolkit and can therefore only be used with Linux as
operating system.

Why two different interfaces?

Especially when concerning security related applications you (as developer)
need to decide if you like to build an application used by expert users (e.g.
experienced system administrators) or if you like to provide a tool that
everybody can handle.

It hasn't been an easy decision to implement one interface for each user group
but after pondering about concepts to merge those two requirements into one
interface we decided that it is much better to separate them. This allows us
to concentrate on the wishes and wanted features for each of the user groups.

Changes:
0.9.6.2 -> 1.0beta1
* KMFIPTCompiler plugin now also compiles the KMFIPTDoc class
* added -v|--version switch for making script not to noisy
* Moved init script generation to the installer plugin
* removed unused KMFCompilerPlugin
* added KMFPluginFactory which handles the plugin lookup & initialisation
* removed obsolete class KMFRuleEditInterface was unused but i forgot to remove them.
* removed class KMFIPTInstaller from kmyfirewall/installer/ was unused but i forgot to remove it.
* Some more API documentation in the core library
* Code cleanups.
* Added KEditToolBar.
* Fixed bug in IPTChain::loadXML(...) Now corectely loads chain attributes.
* Added table, user_defined and builtin icon
* changed some icon positions in ListView
* Moved the object documentation dialog to kmfwidgets
* Added possibility to document the whole ruleset
* New KMFRuleEditInterface class as base for KMFRuleEdit to aviod linking the option edit plugins against the libkmfruleeditorpart.la no more "linking against loadable library is not portable warnings"
* Moved KMFApp to core/
* Fixed "linking against loadable library is not portable warnings" for libkmyfirewall.la
* Removing unused kmyfirewall_part.* files and libkmyfirewall.la target
* Moved kmfinstall.sh to installer/linux/ - fits much better there
* Adding "name" attribute to the KMFDoc class
* Adding Open Template dialog showing the sescription and the name of the templates available
* Added dialog for editing document name anmd description
* GenericInterfaceProtocol seems to work now
* lots of fixes in KMFNetZone & KMFNetHost
* KMFIPTInstallerPlugin can handle genericDoc now
* KMFIPTCompiler: ConvertToIPDoc and View works now. Shows all tables.
* KMFIPTCompiler: now compiles genericDoc zones & protocols honoring limit and logging
* KMFIPTCompiler: adds default connection tracking rule
* KMFIPTCompiler: finshed rule creation for in & out zones
* KMFIPTCompiler: finshed rule creation for trstedHosts, malicious hosts, trusted servers & clients
* KMFNetHost: fixed bug in loadXML(...) no more duplicate protocol entries
* Refactored KMFIPTablesCompiler.
* New class KMFIPTablesScriptGenerator - creates an iptables script from a KMFIPTDoc instance
* New class KMFIPTablesDocumentConverter - generates a KMFIPTdoc from a KMFGenericDoc instance
* KMFIPTCompiler: finisehd NAT rules creation
* KMFIPTCompiler: finisehd ICMP rules creation
* KMFIPTCompiler: finisehd LOGGING rules creation
* KMFConfigDialog: Interface detection, Plugin listview shows comment now
* KMFCompilerInterface: adding new methods for getting the name of the os and backend
* KMFConfigDialog: platform and backend values are now set by the plugins properties
* KMFSelectInterface: added new dialog that lets you chooss the interface at startup, not finished yet
* KMFSelectInterface: added screenshot loading, smaller fixes
* Switching to KConfig XT framework: replaces kmfconfiguration class
* Several cosmetical changes
* New Class KMFAppState: Holds some static variables giving information about the app's state
* Some minor Fixes
* Started documentaion for plugin framework
* Enable kdesu for running commands if not started as root
* Started implementing Template saving
* Added HP link URl to about dialog
* Minor code cleanup

Posted by Christian Hubinger 2005-03-21

Log in to post a comment.