It has been my intention to continue the beta period for 4.0 through the summer and to release 4.0 in the September time frame. Several factors have caused me to rethink that schedule. - The rate of problem reports against Shorewall-perl has dropped rapidly and the code seems to be quite stable. - The 4.0 Documentation has come together more quickly than I had planned. - 3.4 and 4.0 are now on nearly identical code bases except for Shorewall-perl. I have patch files to make up for the differences so it is now possible to make maintenance updates to 3.4 and roll those updates into 4.0 with almost no additional effort. In light of these factors, I''m thinking of producing one more 4.0 Beta release then releasing 4.0.0 RC1. Assuming that the release candidate doesn''t encounter problems, I would anticipate final release some time in late July or early August. Because supporting 3.4 will not present any burden over supporting 4.0, I plan to break the "two supported releases" rule and to support 3.2, 3.4 and 4.0 until 4.2 comes along. Comments? -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
On Tuesday 26 June 2007 18:19, Tom Eastep wrote:> It has been my intention to continue the beta period for 4.0 through the > summer and to release 4.0 in the September time frame. Several factors have > caused me to rethink that schedule. > > - The rate of problem reports against Shorewall-perl has dropped rapidly > and the code seems to be quite stable. > - The 4.0 Documentation has come together more quickly than I had planned. > - 3.4 and 4.0 are now on nearly identical code bases except for > Shorewall-perl. I have patch files to make up for the differences so it > is now possible to make maintenance updates to 3.4 and roll those updates > into 4.0 with almost no additional effort. > > In light of these factors, I''m thinking of producing one more 4.0 Beta > release then releasing 4.0.0 RC1. Assuming that the release candidate > doesn''t encounter problems, I would anticipate final release some time in > late July or early August. > > Because supporting 3.4 will not present any burden over supporting 4.0, I > plan to break the "two supported releases" rule and to support 3.2, 3.4 and > 4.0 until 4.2 comes along. > > Comments? > > -TomTom My testing over the last few weeks suggests that your revised schedule is appropriate. There is a possible issue with the ''shorewall add'' command. I am still testing this, and will report back anything I find. Other than that Beta 6 is proving to be very stable. I have also done some testing against iptables 1.3.8. and haven''t encountered any problems so far. As iptables 1.3.8 now supports the randomising of source ports on snat, same, and masq rules, would it be a good idea to include support in Shorewall 4.0 or wait until 4.2? Steven. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
Steven Jan Springl wrote:> > My testing over the last few weeks suggests that your revised schedule is > appropriate. There is a possible issue with the ''shorewall add'' command. I am > still testing this, and will report back anything I find. Other than that > Beta 6 is proving to be very stable. > > I have also done some testing against iptables 1.3.8. and haven''t encountered > any problems so far.Thanks, Steven> > As iptables 1.3.8 now supports the randomising of source ports on snat, same, > and masq rules, would it be a good idea to include support in Shorewall 4.0 > or wait until 4.2? >--random is also supported on DNAT. It will be simple to add support for it so let''s wait and add it in 4.0.2 or there abouts. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
On Tuesday 26 June 2007 21:16, Tom Eastep wrote:> Steven Jan Springl wrote: > > My testing over the last few weeks suggests that your revised schedule is > > appropriate. There is a possible issue with the ''shorewall add'' command. > > I am still testing this, and will report back anything I find. Other than > > that Beta 6 is proving to be very stable. > > > > I have also done some testing against iptables 1.3.8. and haven''t > > encountered any problems so far. > > Thanks, Steven > > > As iptables 1.3.8 now supports the randomising of source ports on snat, > > same, and masq rules, would it be a good idea to include support in > > Shorewall 4.0 or wait until 4.2? > > --random is also supported on DNAT. It will be simple to add support for it > so let''s wait and add it in 4.0.2 or there abouts. > > -TomTom --random on DNAT is supported by iptables but not by kernel 2.6.21. I believe 2.6.22 will support it. Steven. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
On Tuesday 26 June 2007 19:19:37 Tom Eastep wrote:> It has been my intention to continue the beta period for 4.0 through the > summer and to release 4.0 in the September time frame. Several factors have > caused me to rethink that schedule. > > - The rate of problem reports against Shorewall-perl has dropped rapidly > and the code seems to be quite stable. > - The 4.0 Documentation has come together more quickly than I had planned. > - 3.4 and 4.0 are now on nearly identical code bases except for > Shorewall-perl. I have patch files to make up for the differences so it > is now possible to make maintenance updates to 3.4 and roll those updates > into 4.0 with almost no additional effort. > > In light of these factors, I''m thinking of producing one more 4.0 Beta > release then releasing 4.0.0 RC1. Assuming that the release candidate > doesn''t encounter problems, I would anticipate final release some time in > late July or early August. > > Because supporting 3.4 will not present any burden over supporting 4.0, I > plan to break the "two supported releases" rule and to support 3.2, 3.4 and > 4.0 until 4.2 comes along. > > Comments?Tom; the continued support for 3.4 is appreciated. Speaking for the bering-uclibc branch of LEAF the Perl-based 4.0 is somewhat too big to go with it - I know times are changing and so does the boot medias :) - both may be considered as good. I started with seawall and it also took some time to upgrade to shorewall - so maybe history repeats itself. Thx very much for giving us shorewall and outstanding support. And hopefully a perl-based shorewall is worth the effort for you to move to a new language. kp ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
On Tue, Jun 26, 2007 at 11:09:42PM +0200, KP Kirchdoerfer wrote:> Speaking for the bering-uclibc branch of LEAF the Perl-based 4.0 is somewhat > too big to go with it - I know times are changing and so does the boot > medias :) - both may be considered as good.Note that you only need about 2Mb worth of perl, not the entire perl distribution, so it should fit on almost anything besides a floppy. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
It has been my intention to continue the beta period for 4.0 through the summer and to release 4.0 in the September time frame. Several factors have caused me to rethink that schedule. - The rate of problem reports against Shorewall-perl has dropped rapidly and the code seems to be quite stable. - The 4.0 Documentation has come together more quickly than I had planned. - 3.4 and 4.0 are now on nearly identical code bases except for Shorewall-perl. I have patch files to make up for the differences so it is now possible to make maintenance updates to 3.4 and roll those updates into 4.0 with almost no additional effort. In light of these factors, I''m thinking of producing one more 4.0 Beta release then releasing 4.0.0 RC1. Assuming that the release candidate doesn''t encounter problems, I would anticipate final release some time in late July or early August. Because supporting 3.4 will not present any burden over supporting 4.0, I plan to break the "two supported releases" rule and to support 3.2, 3.4 and 4.0 until 4.2 comes along. Comments? -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ======================================================= Tom - I noticed Herr Kirchdoerfer''s response and have an entirely (maybe unfounded) reason for not migrating to 4.x. First off, I love the capabilities, the support, even the sporadic scoldings (which I can say in my case at lease, deserved). To my knowledge, a hack like myself has NOT been compromised since starting to run Shorewall. But, therein lies the rub. I happen to be using SuSE, and older (now unsupported) distro. But, what little mentoing I have received, is to never leave the tools for your "desturction" on the firewall box. So with SuSE''s YaST, I have to meticulously delete packages I don''t want, remove X, etc., etc., when I install. So when I (was able to) update, I relied on the SuSE YaST tool to update the kernel, and in keeping with leave tools/packages off, have to rely then on the binary distribution because I don''t even install a compiler on the Shorewall box. So this puts me at a disadvantage from some tools, such as Perl, which has a great library of modules. But, there''s the dilemma, and, maybe my ill conceived view, of my security -- I do NOT have the tools to make it easier to be compromised. So from that perspective, NOT having Perl seems to be more secure. A buddy of mine says that if "they''re gonna getcha, they''ll getcha" but I like to think otherwise with great tools, such as Shorewall. But, on the other hand, I don''t want to leave the gun sitting out for the granchildren to play with, to use a stupid analogy. Comments, thoughts ? When I rebuild the firewall, do with a Perl installation as well ? Bill A sufficiently talented fool ======================================================= ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
On Tue, Jun 26, 2007 at 02:39:43PM -0700, Bill.Light@kp.org wrote:> But, therein lies the rub. I happen to be using SuSE, and older (now > unsupported) distro. But, what little mentoing I have received, is to > never leave the tools for your "desturction" on the firewall box. So with > SuSE''s YaST, I have to meticulously delete packages I don''t want, remove > X, etc., etc., when I install. So when I (was able to) update, I relied > on the SuSE YaST tool to update the kernel, and in keeping with leave > tools/packages off, have to rely then on the binary distribution because I > don''t even install a compiler on the Shorewall box.This is more or less worthless on an internet-connected host. Every attacker just downloads whatever they need (in the form of a rootkit bundle), without even looking to see what is installed locally. The only person you inconvenience is yourself. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
Bill.Light@kp.org wrote:> I noticed Herr Kirchdoerfer''s response and have an entirely (maybe > unfounded) reason for not migrating to 4.x.What you write below looks like a justification for not using Shorewall-perl. Please do not confuse Shorewall 4.x and Shorewall-perl. While Shorewall-perl is an option in Shorewall 4.x, you don''t need to install it and you don''t need to use it.> First off, I love the > capabilities, the support, even the sporadic scoldings (which I can say > in my case at lease, deserved). To my knowledge, a hack like myself has > NOT been compromised since starting to run Shorewall. > > But, therein lies the rub. I happen to be using SuSE, and older (now > unsupported) distro. But, what little mentoing I have received, is to > never leave the tools for your "desturction" on the firewall box. So > with SuSE''s YaST, I have to meticulously delete packages I don''t want, > remove X, etc., etc., when I install. So when I (was able to) update, I > relied on the SuSE YaST tool to update the kernel, and in keeping with > leave tools/packages off, have to rely then on the binary distribution > because I don''t even install a compiler on the Shorewall box. > > So this puts me at a disadvantage from some tools, such as Perl, which > has a great library of modules. But, there''s the dilemma, and, maybe my > ill conceived view, of my security -- I do NOT have the tools to make it > easier to be compromised. So from that perspective, NOT having Perl > seems to be more secure. A buddy of mine says that if "they''re gonna > getcha, they''ll getcha" but I like to think otherwise with great tools, > such as Shorewall. But, on the other hand, I don''t want to leave the > gun sitting out for the granchildren to play with, to use a stupid analogy. > > Comments, thoughts ? When I rebuild the firewall, do with a Perl > installation as well ?If you are that paranoid about your firewall, install Shorewall-perl on a system behind the firewall and run Shorewall-lite on the firewall system. I personally think that a well-constructed firewall box (no externalized services) is the hardest system in your network to compromise. So why would an attacker go after the hardest target when there are much softer ones to be had. My $.02US -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/