Bug#669705: [NMU] autopsy: Helping to update to packaging format 3.0
2012/5/10 Jari Aalto jari.aa...@cante.net: I'm planning to NMU with changes listed in previous mail's patch to help migrate away from deprecated dpatch. Please let me know if an update is alredy being worked on, or if the previous patch needs adjustments, or if there is anything that should delay the NMU. Hi Jari, sorry for the late reply. I think I don't have time anymore to maintain the package. Please feel free to NMU. Thanks a lot, Lorenzo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573419: wmnetload: should this package be orphaned?
On 11/03/2010 12:48, Jan Hauke Rahm wrote: Package: wmnetload Version: 1.3-1.1 Severity: important User: debian...@lists.debian.org Usertags: proposed-orphan Dear Lorenzo, while reviewing some packages, your package came up as a package that should maybe be orphaned by its maintainer. You have been contacted about the package before and you said you were going to update it. Nothing changed since then. The package is literally maintained through NMUs, it's outdated wrt lintian issues and standards-version and I don't see any action from you. If you think that it should be removed from Debian instead of being orphaned, please reply to this bug and tell so. I am no longer a wmaker/wmnetload user and at this point I think it should be wise to orphan the package. Lorenzo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574739: O: wmnetload -- an app for monitorin network load
Package: wnpp Severity: normal I am no longer a user of this software and bug #358058 won't be fixed upstream (the software doesn't seem to be maintained anymore). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#358058: wmnetload: segfaults on startup
Rogério Brito ha scritto: Hi again, On Apr 09 2009, Rogério Brito wrote: On May 27 2008, Alexandre Lymberopoulos wrote: The program causes a segmentation fault when X starts and the device to be monitored is not up. When the monitored device is up wmnetload seems to work perfectly. I'm also seeing the segfaults, but I can't pinpoint when they happen precisely. I have many interfaces and sometimes they are working, sometimes not and wmnetload seems to work ok. Upon further investigation, it seems that wmnetload doesn't cycle between all interfaces when the right mouse button is clicked on the dock app. What I *do* see, though, is that it, suddenly dies out of the blue, when I'm using my system. My configuration is: I'm still seeing such problems, but now I've run it through valgrind and I see many messages of the type: conditional jump or move based on unitialized value, blah, blah. Also, I found an unitialized variable being used. The source for that was a typo. In file wmnetload.c::approxpixel, the following snippet of code is wrong: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diffr = (red - colorcells[i].red) 8; diffg = (green - colorcells[i].green) 8; diffr = (blue - colorcells[i].blue) 8; approx = diffr * diffr + diffg * diffg + diffb * diffb; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Obviously, the variable corresponding to the blue color is diffb, not diffr. This fixes one problem. There are also other initialization problems regarding wrong number of initializers for structures. Also, some signed vs. unsigned comparisons are made in the c files. Can we have any response to this thread? The bug has been filed for quite some time, without *any* action being taken. Lorenzo, are you listening? Please, reply. I fear that some drastic measures would be necessary if we *continue* to have no feedback from you. Hi guys, sorry for the long silence. I'm currently not able to reproduce the bug. I tried to start wmnetload with different interfaces and to bring up and down these interfaces manually but I did not experience any crash. Valgrind reports the same warnings noticed by Rogério. I'm running wmnetload through gdb and waiting the segfault. Are you aware of any deterministic trigger for the segfault? Lorenzo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#432837: Better patch
On 7/12/07, Matthew King [EMAIL PROTECTED] wrote: Here's a better patch which can include directories in locations other than /etc/shorewall Thank you. I'll update the package as soon as possible. -- lm -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421715: shorewall: conflicts with several packages
On 6/16/07, Michael Prokop [EMAIL PROTECTED] wrote: * Michael Prokop [EMAIL PROTECTED] [20070501 10:15]: [...] Any chance to get an answer? The problem will be fixed by the next upload. -- l -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#422572: Process spawned by left click remains zombie
Package: xfce4-genmon-plugin Version: 3.1-1 Severity: normal --- Please enter the report below this line. --- The process spawned when the icon plugin is left clicked remains zombie because the plugin process does not wait for the termination of the child. As a workaround the following patch can be used: --- main.c.orig 2007-05-06 21:58:20.0 -0500 +++ main.c 2007-05-06 20:54:37.0 -0500 @@ -97,7 +97,8 @@ char result[256]; genmon_SpawnCmd (poMonitor-onClickCmd, result, -sizeof (poMonitor-onClickCmd), 0); +//sizeof (poMonitor-onClickCmd), 0); +sizeof (poMonitor-onClickCmd), 1); } /**/ The patch is not the ultimate solution as the plugin is blocked until the child is terminated. --- System information. --- Architecture: i386 Kernel: Linux 2.6.20-asus-s1n Debian Release: lenny/sid 500 unstableftp.debian.org 500 stable www.debian-multimedia.org 500 stable security.debian.org 500 stable ftp.debian.org 1 experimentalftp.debian.org --- Package information. --- Depends (Version) | Installed ===-+-= libatk1.0-0 (= 1.13.2) | 1.18.0-2 libc6 (= 2.5) | 2.5-5 libcairo2(= 1.4.0) | 1.4.6-1 libfontconfig1 (= 2.4.0) | 2.4.2-1.2 libglib2.0-0(= 2.12.9) | 2.12.11-3 libgtk2.0-0 (= 2.10.3) | 2.10.12-1 libpango1.0-0 (= 1.16.2) | 1.16.2-2 libx11-6| 2:1.0.3-7 libxcursor1 ( 1.1.2) | 1:1.1.8-2 libxext6| 1:1.0.3-2 libxfce4util4(= 4.4.1) | 4.4.1-1 libxfcegui4-4(= 4.4.1) | 4.4.1-1 libxfixes3 (= 1:4.0.1) | 1:4.0.3-2 libxi6 | 1:1.0.1-4 libxinerama1| 1:1.0.2-1 libxrandr2 (= 2:1.2.0) | 2:1.2.1-1 libxrender1 | 1:0.9.2-1 xfce4-panel (= 4.4.1) | 4.4.1-1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421441: splashy: splashy-gdm hangs system randomly
Geoffrey L. Brimhall wrote: Package: splashy Version: 0.3.2 Severity: important There is a race condition between when splashy ends and gdm starts that happens on my system about 1 in 3 boots, when it happens the splashy screen is just hangs and console switching to X doesn't work. Think it may be related to my system being SMP (dual core ). This bug is really identical to #350179 - so either close this bug or re-open that one ! By updating the gdm and splashy scripts I got rid of the race condition, here's the fix ( note the fix really requires updating all display manager scripts to be aware if a boot gui is being used, if so shut it down ): REMOVE from splashy script in the start sequence: else log_daemon_msg Stopping $DESC $NAME /sbin/splashy_update exit log_end_msg $? # wait until splashy exits before changing tty's while `pidof splashy /dev/null`; do sleep 0.2 done # do some magic with the TTYs if test -z $CHVT_TTY; then CHVT_TTY=1 fi # detect X, if not, go to CHVT_TTY X11_RUNNING=1 pidof X /dev/null X11_RUNNING=1 if [ $X11_RUNNING -eq 1 ]; then splashy_chvt 7 else splashy_chvt $CHVT_TTY fi ADD to gdm script the above functionality, before the start_daemon command: # Disable splashy if running if `pidof splashy /dev/null`; then log_daemon_msg Stopping $DESC $NAME /sbin/splashy_update exit /sbin/splashy_chvt 7 log_end_msg $? fi I have the same problem on my laptop (splashy 0.3.2 + xdm 1:1.1.4-3): the machine hangs on the splash screen. The workaround suggested seems to solve the startup problem. -- lorenzo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415654: shorewall / linux ip_nat_sip module breaks SIP
Ted Merrill wrote:
Package: shorewall
Version: 3.2.9-1
Severity: normal
The latest debian unstable shorewall release, shorewall 3.2.9-1,
incorrectly
modifies some SIP packets during network address translation, thereby
causing
all subsequent voice packets to be lost.
Actually this may be a linux kernel issue instead since the problem is
related
to the following kernel module that was not loaded in previous release:
ip_nat_sip
Commenting out the loadmodule line in /usr/share/shorewall/modules that
loads
ip_nat_sip fixes the problem.
It's not clear to me what ip_nat_sip is needed for; perhaps something to do
with connection tracking (e.g. connected to ip_conntrack_sip module, also
recently added, which i don't seem to need either).
The problem specifically is that in a SIP 200 OK packet from the
registar,
the SDP connection information ('c') line is (incorrectly) modified.
It should be left alone; instead the ip address on that line is rewritten
to
be the ip address of the sender of the packet.
I'm temporarily disabling the sip module.
-- lorenzo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412134: shorewall: Logging (ulog) of MAC address is incomplete
Jeffrey B. Green wrote: Good. It's always a real pain if the bug cannot be reproduced. Here the info on ulogd: ii ulogd 1.23-6The Netfilter Userspace Logging Daemon This is the bogus version. The bug against ulogd has already been filed. -- lorenzo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412134: shorewall: Logging (ulog) of MAC address is incomplete
Jeffrey B. Green wrote: Package: shorewall Version: 3.2.6-2 Severity: wishlist The packets being written to the ulogd log file have only the following for the MAC address information: MAC=00 i.e. only the two digits 00. This problems shows up in the logs on Feb 9 (to narrow down the time frame of when things changed). tcpdump does indeed show the complete MAC addresses in the packets, but dumping the packets via the ulogd_OPRINT.so module shows only the 00 value. I could not find any relevant configuration options that might affect this behavior. I can reproduce the bug. It seems that the problem is in ulogd. See Debian bug#412499. Which version of ulogd are you using? -- lorenzo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413810: [INTL:gl] Galician debconf templates translation for shorewall
Jacobo Tarrio wrote: Package: shorewall Severity: wishlist Tags: l10n patch It is attached to this report. Thanks. It will be included in the next revision of the package. -- lm -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413549: shorewall: Shorewall always spam my console despite VERBOSITY=0
Paul Gear wrote: Aurélien Le Provost - Ribaltchenko wrote: Package: shorewall Version: 3.2.6-2 Severity: minor Hi, In /etc/shorewall/shorewall.conf I have VERBOSITY=0 because I don't want my console spamed by shorewall. But it has no effect... Don't know why. This is a case of Shorewall FAQ 16: http://shorewall.net/FAQ.htm#faq16 and should not be treated as a bug in Debian or Shorewall. Also the README.Debian provides useful information about how to prevent logging to console. -- lm
Bug#413548: shorewall: NAT (masquerade) rules lost after reboot
Aurélien Le Provost - Ribaltchenko wrote: Package: shorewall Version: 3.2.6-2 Severity: important Hi. Since I upgraded my server from sarge to etch, I noticed that NAT (masquerade) rules are lost after a reboot. I have this line in /etc/shorewall/masq : eth0eth2 The workaround is to append this lines to /etc/rc.local : /etc/init.d/shorewall stop /etc/init.d/shorewall start to have Internet on the LAN normally, without worrying to know if the server were rebooted or not. Hi, please temporarily comment the two lines you add to your /etc/rc.local, reboot your machine, and send me the content of the log file /var/log/shorewall-init.log. Thanks. -- lm
Bug#412134: shorewall: Logging (ulog) of MAC address is incomplete
Jeffrey B. Green wrote: Package: shorewall Version: 3.2.6-2 Severity: wishlist The packets being written to the ulogd log file have only the following for the MAC address information: MAC=00 i.e. only the two digits 00. This problems shows up in the logs on Feb 9 (to narrow down the time frame of when things changed). tcpdump does indeed show the complete MAC addresses in the packets, but dumping the packets via the ulogd_OPRINT.so module shows only the 00 value. I could not find any relevant configuration options that might affect this behavior. Can you please send me your configuration files so that I can reproduce the problem? Thanks. -- lm -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#408698: Bug Resolved
Flavio Visentin wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tom Eastep contacted me and gave me the solution. To meke this configuration work it's enough to specify the option routeback on the interface definition, like the following: /etc/shorewall/interfaces #ZONE INTERFACE BROADCAST OPTIONS net eth1- blacklist lan eth0- routeback,dhcp srv veth+ - routeback - From the definition of routeback, in the interface file, it wasn't clear to me that it worked with multiple interfaces too (although now it seems obvious also to me). Maybe we should specify this case in the option's description Anyway the bug should be closed. I completely forgot the routeback option! I'm going to close the bug. Thanks. -- lorenzo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407011: autopsy should recognize ils-sleuthkit
Dr. Markus Waldeck wrote: Package: autopsy Version: 2.08-1 Severity: important starting autopsy results in ERROR: Sleuth Kit ils executable missing % dpkg -L sleuthkit| grep ils | grep bin /usr/bin/ils-sleuthkit -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (990, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-686 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Versions of packages autopsy depends on: ii binutils 2.17-3 The GNU assembler, linker and bina ii perl 5.8.8-7Larry Wall's Practical Extraction ii sleuthkit 2.06-3 Tools for forensics analysis autopsy recommends no packages. On my system /usr/bin/ils is a link to /etc/alternatives/ils which is a link to /usr/bin/ils-sleuthkit. Note that my version of sleuthkit is 2.07-1. I think that your problems will be solved as soon as you upgrade sleuthkit. The point is that if /etc/alternatives/ils is pointing to somewhere else (e.g. tct) autopsy will not work. It is better to use directly ils-sleuthkit, icat-sleuthkit and mactime-sleuthkit instead of the symlinks to /etc/alternatives. Thanks for the report. -- l -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397153: shorewall: Doesn't start after upgrade from 3.0.x
* Paul Gear [EMAIL PROTECTED]: That is true, but in both of the machines i've upgraded to Shorewall 3.2.4, they have not started successfully. Shorewall does not start without the STARTUP_ENABLED variable being present, which i think is bad backwards-compatibility behaviour. I'll have a talk to Tom about this. I'm sorry for the mess. I closed the bug while it was still open. I uploaded a new version of the package which sets by default STARTUP_ENABLED=YES, such that upgrade on a machine without an up-to-date shorewall.conf shouldn't give problems any more. -- lorenzo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397153: shorewall: Doesn't start after upgrade from 3.0.x
* Greg Norris [EMAIL PROTECTED]: At the very least, README.Debian should be updated to reflect this change in behaviour. Currently the file says: 1. AUTOMATIC STARTUP In order to avoid the startup of the firewall on an unconfigured machine, automatic startup, on boot, is disabled by default. To enable it just edit the file /etc/default/shorewall and set the startup variable to 1. The initscript no longer seems to reference /etc/default/shorewall at all, so clearly this is no longer accurate. Why do you say that? The init script in the package does reference /etc/default/shorewall. -- lorenzo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348242: shorewall: leaves file behind after purged
* Lars Wirzenius [EMAIL PROTECTED]: Package: shorewall Version: 3.0.4-1 When testing shorewall with piuparts, I get the following error: 0m7.6s ERROR: Package purging left files on system: /etc/shorewall owned by: shorewall /etc/shorewall/tcstart This is due to postinst created the tcstart file, but it not being removed by postrm (which needs to happen when the package is removed, not just when it is purged, or else tcstart needs to be marked as a conffile). The tcstart is touched by postinst in order to avoid problems during upgrade. If your configuration has TC_ENABLED=Yes but you don't have tcstart shorewall refuses to start. Older versions worked without any problems when the tcstart file was missing. I'll add a test in order to check if that file is empty. Thank you very much. -- lorenzo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348726: Update overwrites shorewall.conf without detecting customizations
* Paul Gear [EMAIL PROTECTED]: Johannes Graumann wrote: Package: shorewall Version: 3.0.4-1 Severity: normal The recent update to a3.0.4-1 presents the problem of installing a new /etc/shorewall/shorewall.conf file without making the admin aware of customization being lost as is usually done (debconf issue - I guess). If there were no customisations to shorewall.conf, the debconf prompt would never appear. Whenever debconf asks about overwriting a file, it should be the system administrator's assumption that there are customisations. I can't see how this is a bug. Files installed by the package under /etc/ are trated as conffiles by dpkg automatically. On a package upgrade dpkg prompts you before overwriting conffile only if you have customized them; if no local customization has been made dpkg will silently replace them all. -- lorenzo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348423: ITP: python-pynids -- a python wrapper for libnids
Package: wnpp Severity: wishlist Owner: Lorenzo Martignoni [EMAIL PROTECTED] * Package name: python-pynids Version : 0.5 Upstream Author : Michael J. Pomraning [EMAIL PROTECTED] * URL : http://pilcrow.madison.wi.us/pynids/ * License : GPL Description : a python wrapper for libnids pynids is a python wrapper for libnids, a Network Intrusion Detection System library offering sniffing, IP defragmentation, TCP stream reassembly and TCP port scan detection. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.14 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336611: shorewall: Does not disable ipv6 at boot
* Sam Morris [EMAIL PROTECTED]:
Lorenzo Martignoni wrote:
but, as you can see, on my own system ipv6 seems to be disabled
correctly.
What happens on your system if you clear all firewall rules and policies
and then issue a shorewall start?
-- lorenzo
Ok, the recent kernel-image-2.6.8-i386 security update gave me an
opportunity to double check this. The output of 'ip6tables --list' after
booting up shows that ACCEPT is the policy for all three chains. I am
attaching the shorewall-init.log.
Running 'shorewall start' does not change this (Shorewall Already
Started). Running 'shorewall restart' does correctly set the chains'
policy to DROP.
Is it possible that the ipv6 kernel modules are not loaded when
shorewall is started, and so shorewall doesn't bother running ip6tables
to set the default policy?
I think you're right; the ipv6 module is not loaded automatically so
probably the code used to detect if ipv6 is enable:
disable_ipv6() {
local foo=$(ip -f inet6 addr ls 2 /dev/null)
fails to detect it and consequently ip6tables is not run.
On my system IPV6 is correctly disabled at boot. I don't think the
cause is a different version of Shorewall (my system runs Debian Sid)
because the code used to detect the presence of IPV6 is the same.
Please try to add ipv6 in your /etc/modules so that the module is
loaded at boot before shorewall startup and let me know what happen.
Thank you.
-- lorenzo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347578: shorewall: [INTL:sv] Swedish debconf templates translation
* Daniel Nylander [EMAIL PROTECTED]: Package: shorewall Version: 3.0.4-1 Severity: wishlist Tags: patch l10n Here is the swedish translation of the debconf template for shorewall. Regards, Daniel Thank you very much. I'll include it soon. -- lorenzo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342609: /etc/init.d/shorewall stop doesn't undo /etc/init.d/shorewall start
* Paul Gear [EMAIL PROTECTED]: Thijs Kinkhorst wrote: /etc/init.d/shorewall stop will keep applied some of the shorewall settings I experienced a problem that I think reduces to the same issue: I executed /etc/init.d/shorewall stop, thinking that it would disable the shorewall rules and hence enable all traffic. However, running /etc/init.d/shorewall stop left my system totally unreachable. I think that's undesirable behaviour. Lorenzo has changed the behaviour of the init script for Debian to make this the default behaviour for the benefit of those who are used to Debian init script behaviour. However, for those experienced with Shorewall, this is extremely undesirable behaviour. Stopping shorewall is semantically equivalent to saying I don't want any more traffic passing through my firewall. The appropriate way to clear out Shorewall's rules is 'shorewall clear' (which is now called by '/etc/init.d/shorewall stop'). If you want your system to be reachable when you execute 'shorewall stop', then you should put the appropriate entries in /etc/shorewall/routestopped. Lorenzo, i think at the very least we need a clear, prominent comment in README.Debian that highlights the difference between 'shorewall stop' and '/etc/init.d/shorewall stop'. I personally think the discrepancy is undesirable and a better approach would be educating users about what 'shorewall stop' and 'shorewall clear' are designed to do. The comment is already in NEWS.Debian. If you use apt-listchanges you'll be informed about news automatically when a new one is found. -- lorenzo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342608: Disable ipv6 could be harmful
* Jeroen van Wolffelaar [EMAIL PROTECTED]: Package: shorewall Version: 2.2.3-2 The default shorewall config says: | # Setting DISABLE_IPV6=Yes will cause Shorewall to disable IPV6 traffic | # to/from and through your firewall system. This requires that you have | # ip6tables installed. | DISABLE_IPV6=No However, it lacks a strong warning that it'll *drop* ipv6 traffic (or so it seems), causing timeouts (that take long), instead of immediate 'unrouteable' or some such errors (or just working connection for localhost). Also, there doesn't seem to be any direct way to log the reject/drops from it, so you won't easily see what exactly is going on anyway. I'm not entirely sure what was the reason for my application failing, but it's something similar to that, as disabling this setting again for my not-for-ipv6-configured host (but still having the capability because of Sarge's default kernel) resolved it. I'd appreciate it if you could add a warning there so that people won't easily make the same mistake I did :) I'm going to add a note in the README.Debian. Thank you for you report. -- lorenzo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#346271: New version 1.0.2 available
Package: scapy Severity: wishlist According to the webpage http://www.secdev.org/projects/scapy/ the new version 1.0.2 is available. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.14 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344965: please produce a clearer error message when autopsy run as non-root
* Michael Gilbert [EMAIL PROTECTED]: Package: autopsy Version: 2.06-1 Severity: wishlist when autopsy is run as non-root, the following error will be generated, Can't open log: autopsy.log at /usr/share/autopsy/lib//Print.pm line 316. it wolud be much better if the message was something like autopsy: permission denied: please run autopsy as root Ok. Thank you for your suggestion. I'm going to upload a new release. -- lorenzo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341942: shorewall vi again
* Clytie Siddall [EMAIL PROTECTED]: Sorry, my translation program has been munging text after finishing. The fixed file is attached below. from Clytie Thank you. -- lorenzo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340748: shorewall: [v3] ERROR: Only one firewall zone may be defined
* Jari Aalto [EMAIL PROTECTED]: Package: shorewall Version: 3.0.1-1 Severity: important After upgrade to v4 shorewall I changed the zone file to (ipsecfile is empty): #ZONE TYPEOPTIONS fw firewall net ipv4 loc ipv4 Which is assumed to be correect according to releasenotes.txt.gz and http://www.shorewall.net/Documentation.htm#Zones ZONEShort name of the zone (5 Characters or less in length). The names all and none are reserved and may not be used as zone names. TYPEipv4 - This is the standard Shorewall zone type and is the default if the column is left empty or if it is entered as -. Communication with some zone hosts may be encrypted. Encrypted hosts are designated using the 'ipsec' option in /etc/shorewall/hosts. ipsec - Communication with all zone hosts is encrypted Your kernel and iptables must include policy match support. firewall - Designates the firewall itself. You must have exactly one 'firewall' zone. No options are permitted with a 'firewall' zone. Try to unset the variable FW in your /etc/shorewall/shorewall.conf. Let me know whether it works or not. -- lorenzo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340003: Update bogons file to reflect IANA allocs in stable branch
* FX [EMAIL PROTECTED]: package: shorewall version: 2.2.3-2 On 2005-07-30, the bogons file in version 2.2.6 was updated to reflect recent IANA allocations. Please backport the updated bogons file, /usr/share/shorewall/bogons, to the stable branch. In order to backport the bogons file a new package should be made. Upload of a package into stable distribution is allowed only when the current version present a vulnerability. Please consider that bogons is no longer used in the current version of shorewall as its usefulness is very very low. -- lorenzo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308077: shorewall: Add Allow, Drop rules for AudioItunes
* Jari Aalto [EMAIL PROTECTED]: Package: shorewall Version: 2.2.3-1 Severity: wishlist Please add rules for Apple iTunes service (Linux daapd and mt-daapd servers): Port 3689 tcp + udp Hello, in my opinion is useless to add new actions, like this one, to Shorewall because such a rule is really trivial (just one line) and probably would be used only in a few rare situations. If you don't mind I'd prefer to add new actions only for the major and most used services in order to avoid a vicious circle in which a new action has to be created for every kind of service. If you really need such kind of action you can always create it and put into /etc/shorewall: http://www.shorewall.net/Actions.html#id2464206. -- lorenzo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309849: shorewall: Add Allow* Deny* rules for SMTP DCC server (Distributed Checksum Clearinghouse)
* Jari Aalto [EMAIL PROTECTED]: Package: shorewall Version: 2.2.3-1 Severity: wishlist The Distributed Checksum Clearinghouse or DCC is a cooperative, dis- tributed system intended to detect bulk mail or mail sent to many peo- ple. It allows individuals receiving a single mail message to determine that many other people have received essentially identical copies of the message and so reject or discard the message. http://www.rhyolite.com/anti-spam/dcc/dcc-tree/FAQ.html Do I need to run a DCC server? ... When normally installed by the included Makefiles, DCC clients are configured to use the public DCC servers without any additional configuration, except to open firewalls to port 6277 (UDP). Hello, in my opinion is useless to add new actions, like this one, to Shorewall because such a rule is really trivial (just one line) and probably would be used only in a few rare situations. If you don't mind I'd prefer to add new actions only for the major and most used services in order to avoid a vicious circle in which a new action has to be created for every kind of service. If you really need such kind of action you can always create it and put into /etc/shorewall: http://www.shorewall.net/Actions.html#id2464206. -- lorenzo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333590: /var/lib/shorewall/lock bug
* matthieu castet [EMAIL PROTECTED]: Package: shorewall Version: 2.4.5-1 Severity: important Hi, you should add some check on /var/lib/shorewall/lock in init.d script or add information. For an unknow reason (hard reset ?) /var/lib/shorewall/lock was still here, and I didn't understand why shorewall seem to hang. I reboot, it changes nothing, do a ctrl+c, the there was the same problem on the next reboot. yes I should have wait 60 s, but how could I know there was a timeout ? I can ask the upstream author to add a warning to inform users that the firewall is locked and that shorewall tries to wait up to 60 second to see if the lock is removed. Another solution could be to force the deletion of the lockfile in the initscript after the firewall shutdown is complete. I think I'll go for the latter and that I'll also add a warning message to inform the user that something is not working properly because after shorewall stop the lockfile is still present. -- lorenzo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307295: shorewall: Please guarantee a working firewall after upgrade
* Lorenzo Martignoni [EMAIL PROTECTED]: * John Summerfield [EMAIL PROTECTED]: Package: shorewall Version: 2.2.3-1 Severity: normal I maintain the software on several systems remotely, connecting over they Internet. I am concerned that one day an upgrade to shorwall will leave me with a broken firewall and the need to visit the site or worse, find local hired help. Hi John, I have the same worries. I usually use debconf to warn users about possible problems with configuration files but I'm aware that that couldn't be enough and problems may arise all the same. Unfortunately shorewall check is almost unsupported, that would be the best solution in my opinion. Ideas that come to mind: Use alternatives to choose the active version. This should be in manual mode. Store config files in version-dependant directories - /etc/shorewall22 etc. Use iptables-save to save a working firewall script and make this the default, to be changed at a time of the sysadmin's choosing. I cannot understand what really is your first idea, but I believe the second is much more insteresting: backup your current configuration before restart the firewall and eventually restore it. I'll think about that... This is quite a serious concern to me; I've been cracked and my firewall rules are part of my plan to limit (by IP address range) locations from which connexions can be made to sensitive services. Hello, shorewall now supports two new commands: safe-start and safe-restart that allow you to start or restart the firewall and to confirm that everything is working fine. If you do not accept the new configuration or you don't answer in a short time the old firewall configuration is restored automatically leaving your machine in a safe state. -- lorenzo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336611: shorewall: Does not disable ipv6 at boot
* Sam Morris [EMAIL PROTECTED]: Package: shorewall Version: 2.2.3-2 Severity: important Shorewall doesn't seem to disable IPv6 during bootup. I have DISABLE_IPV6=Yes set in /etc/shorewall/shorewall.conf, and yet, after a reboot: $ sudo ip6tables --list Password: Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination $ sudo /etc/init.d/shorewall restart Restarting Shorewall firewall: done. $ sudo ip6tables --list Chain INPUT (policy DROP) target prot opt source destination Chain FORWARD (policy DROP) target prot opt source destination Chain OUTPUT (policy DROP) target prot opt source destination Hello, thank you for your report. I tried to reproduce the bug: $ sudo shorewall stop $ sudo iptables -P INPUT ACCEPT $ sudo iptables -P OUTPUT ACCEPT $ sudo iptables -P FORWARD ACCEPT $ sudo iptables -F $ sudo ip6tables -P INPUT ACCEPT $ sudo ip6tables -P OUTPUT ACCEPT $ sudo ip6tables -P FORWARD ACCEPT $ sudo ip6tables -F $ sudo shorewall start ... ... $ sudo ip6tables -L Chain INPUT (policy DROP) target prot opt source destination Chain FORWARD (policy DROP) target prot opt source destination Chain OUTPUT (policy DROP) target prot opt source destination but, as you can see, on my own system ipv6 seems to be disabled correctly. What happens on your system if you clear all firewall rules and policies and then issue a shorewall start? -- lorenzo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336088: shorewall: Added actions (allow, reject) for Jabber protocol port 522[23]
* Jari Aalto [EMAIL PROTECTED]: Package: shorewall Version: 2.4.5-1 Severity: wishlist Jabber is IM protocol that uses TCP ports: 5222 non-encrypted (outgoing client) 5223 encrypted 5269 Jabber server intercommunication Please add separate allow and reject rules for these ports, like: action.AllowJabberPlain action.AllowJabberSecure action.RejectJabberPlain action.RejectJabberSecure action.AllowJabberd The jabber server protocol action.RejectJabberd The jabber server protocol Thank you for your report. I'll add these new targets in the next release of the package. -- lorenzo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335644: floods klogd / dmesg buffers with useless log messages
* Robert Millan [EMAIL PROTECTED]: Package: shorewall Version: 2.4.5-1 Severity: normal Shorewall floods klogd / dmesg buffers with useless log messages. This makes the console almost unusable (you can barely read what you type). Please see what upstream says about it: http://www.shorewall.net/FAQ.htm#faq16 I think klogd should allow importing this variable from /etc/defaults/klogd, but at the very least a debconf message in shorewall would help. Hello, I agree with the messages on the console render it completely unusable. I'll add a debconf messages to inform users about this issue. Thank you. -- lorenzo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336105: shorewall: old DNAT rules are not removed after 'restart'
* Jari Aalto [EMAIL PROTECTED]: Package: shorewall Version: 2.4.5-1 Severity: important It appears that once a DNAT rule has been done, it persists even accross 'restart' or 'force-reload'. This is a serious security hole, because the old rules should not be there any more if chnages has been done to the /etc/shorewall/rules file. HOW TO REPRODUCE Have A and B host in local network, access it from external host C. The connection happens to A, which forwards port to B's 22. C = ( A - [2022:dnat:22] - B ) a) initial settings in /etc/shorewall/rules ACCEPT net fw tcp 2022 DNAT net loc:192.168.1.2:22 tcp Why and not 2022? - Connect to A, which should forward to B. - Complete login to B with ssh. b) change the above settings to following: ACCEPT net fw tcp DNAT net loc:192.168.1.2:22 tcp - Restart shorewall: /etc/init.d/shorewall restart - Connect to A, but *using* previous forward, port 2022. = You're forwarded to B. Confirm that the previous rule still exists: iptables -L | grep 2022 Hello, in cooperation with the upstream author we have tried to reproduce the bug you reported but we weren't able to connect th the ssh server using the old DNAT rules. Could you send me a copy of your /etc/shorewall/* of the two configurations and the output of shorewall status with the old DNAT rule and with the new one? -- lorenzo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318946: User expectations and shorewall
* Martin Schulze [EMAIL PROTECTED]: Florian Weimer wrote: (Note that I have yet to test Lorenzo's new package.) Are you in a position to do so? Sure, but the question is if you want to rely on the results. You don't seem to trust my judgement on this matter, for reasons I don't know. I simply did not understand the problem. Hence, didn't understand the vulnerability. Hence, didn't understand what would need to be fixed. I tried to do my best to explain the problem, but unfortunately that's not enough. If you want I can try again to describe the bug. BTW, the vulnerability is recorder in CVE: CAN-2005-2317. If you can, please build an updated package, based on the version in sarge and woody if that's needed as well, and place them on a .debian.org host. I already have a fixed package. I only need to add the CVE ID. On which host of .debian.org should I upload it? -- lorenzo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#326899: shorewall: Providers file is missing
* Pieter Ennes [EMAIL PROTECTED]: Package: shorewall Version: 2.4.3-1 Severity: normal Shorewall packages 2.4.x seem to be missing the providers file in /usr/share/doc/shorewall/default-config. Hello, thank you for your report. I added the missing file and built a new package (2.4.3-2). -- lorenzo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318946: User expectations and shorewall
* Florian Weimer [EMAIL PROTECTED]: * Lorenzo Martignoni: The patch has been tested by me and by Paul Gear but further tests will be better, so your feedback will be very precious. Apart from the lack of CVE entry in the changelog, the package seems to be fine. Both problems are fixed. When I first emailed the security team and built the package I was convinced that the CVE entry was missing. It has been assigned on 20050719, one day after I opened of this bug but before my backport of the patch. I should have added it into the changelog.Debian. BTW, the CVE id is CAN-2005-2317. There is a surprising reduction of the installation size when I rebuild the package I could not track down, but the installed scripts are identical. What do you mean? I rebuilt the package from sources (not using my own local copy but downloading the version I've put online) but the size of the .debs is still the same (~150Kb) and the size of the data section is the same too (~760Kb). -- lorenzo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318946: User expectations and shorewall
* Florian Weimer [EMAIL PROTECTED]: * Martin Schulze: What was the behaviour pre-sarge? What is the behaviour post-sarge (or rather in sarge)? Do you mean before and after the upstream security update? The terms pre-sarge/post-sarge do not make much sense to me in this context, I'm afraid. Ok, so when did the behaviour change? Upstream's security update changed the behavior, from vulnerable to non-vulnerable, if you want. Which behaviour is documented and hence expected? Like most software, shorewall comes with no formalized descriptions of its semantics. The exact behavior of the MAC verification feature is not documented because the documentation writer seemd to assume that it went without saying. So what goes without saying? As far as I can see, something like this: MAC verification is a further restriction which is performed in addition to the usual filtering rules, and not intended to replace it. After all, it's called verification and not bypass. In my mind the semantic of MAC verification is: a further policy restriction that can be used to restrict access to a few clients based on their MAC addresses. So, to answer your question: Users expect that MAC verification never makes the filter policy less restrictive. This is not the case if you set MACLIST_DISPOSITION to ACCEPT or MACLIST_TTL to a non-zero value. Which behaviour is experienced by potentially buggy code? Buggy results? Sorry, I don't understand this question. (Note that I have yet to test Lorenzo's new package.) Are you in a position to do so? Sure, but the question is if you want to rely on the results. You don't seem to trust my judgement on this matter, for reasons I don't know. The patch has been tested by me and by Paul Gear but further tests will be better, so your feedback will be very precious. -- lorenzo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318946: more information on the bug
The bug affects Shorewall 2.2.x and 2.4.x but the only affected Debian
package is shorewall_2.2.3-1 which is currently in Sarge.
The problem with this bug is that clients which mac addresses are known
can bypass the firewall rules and do whatever they want: if
MACLIST_DISPOSITION is set to ACCEPT or MACLIST_TTL is not set to ZERO
then any client which mac address is listed in /etc/shorewall/maclist is
allowed to perform any kind of traffic on the network as the firewall
doesn't filter its requests. In my opinion this is a vulnerability.
MACLIST_DISPOSITION is set to ACCEPT to indicate that a client, which
mac address is not know, is allowed to use the network and that its
packets can be treated as the ones coming from any other hosts of the
same network (or firewall zone). According the documentation:
MACLIST_DISPOSITION determines the disposition of connection requests
that fail MAC verification. MACLIST_TTL is used to set the lifetime of
mac addresses cache to reduce the overhead of addresses lookup in
/etc/shorewall/maclist (using ipt_recent netfilter module).
I tested the bug on my home system: the desktop pc acts as firewall and
the laptop was connected to it via a wireless link. The wlan interface
of the firewall used the mac-filtering (i.e. maclist option is set for
that interface in /etc/shorewall/interfaces) and MACLIST_DISPOSITION was
set to REJECT and MACLIST_TTL to ZERO. The client traffic was perfectly
allowed or rejected according the rules of the firewall. When I set to
10 MACLIST_TTL the laptop became allowed to pass silently through the
firewall: traffic previously allowed was still allowed and traffic
previously denied became allowed too. The same happened when I set
MACLIST_DISPOSITION to ACCEPT and with other possible combinations of
these options.
I attached to this email a copy of the patch that fixes the security
problem. It is a backport of the upstream author patch for version
2.2.5. The BTS already contains a link to an updated version of the
package.
-- lorenzo
diff -urNad shorewall-2.2.3/firewall /tmp/dpep.v6MqTc/shorewall-2.2.3/firewall
--- shorewall-2.2.3/firewall2005-04-10 23:58:12.0 +0200
+++ /tmp/dpep.v6MqTc/shorewall-2.2.3/firewall 2005-07-18 21:04:43.0
+0200
@@ -464,11 +464,6 @@
echo $(chain_base $1)_mac
}
-macrecent_target() # $1 - interface
-{
-[ -n $MACLIST_TTL ] echo $(chain_base $1)_rec || echo RETURN
-}
-
#
# Functions for creating dynamic zone rules
#
@@ -494,6 +489,11 @@
echo ${c}_dyni ${c}_dynf ${c}_dyno
}
+macrecent_target() # $1 - interface
+{
+[ -n $MACLIST_TTL ] echo $(chain_base $1)_rec || echo RETURN
+}
+
#
# DNAT Chain from a zone
#
@@ -2035,13 +2035,14 @@
for interface in $maclist_interfaces; do
chain=$(mac_chain $interface)
createchain $chain no
-
+
if [ -n $MACLIST_TTL ]; then
chain1=$(macrecent_target $interface)
createchain $chain1 no
- run_iptables -A $chain -m recent --rcheck --seconds $MACLIST_TTL
--name $chain -j $chain1
- run_iptables -A $chain1 -m recent --update
--name $chain -j ACCEPT
- run_iptables -A $chain1 -m recent --set
--name $chain -j ACCEPT
+ run_iptables -A $chain -m recent --rcheck --seconds $MACLIST_TTL
--name $chain -j RETURN
+ run_iptables -A $chain
-j $chain1
+ run_iptables -A $chain -m recent --update
--name $chain -j RETURN
+ run_iptables -A $chain -m recent --set
--name $chain
fi
done
#
@@ -2061,8 +2062,7 @@
esac
fi
- chain=$(mac_chain $interface)
- chain1=$(macrecent_target $interface)
+ [ -n $MACLIST_TTL ] chain=$(macrecent_target $interface) ||
chain=$(mac_chain $interface)
if ! havechain $chain ; then
fatal_error No hosts on $interface have the maclist option
specified
@@ -2071,10 +2071,10 @@
macpart=$(mac_match $mac)
if [ -z $addresses ]; then
- run_iptables -A $chain $macpart $physdev_part -j $chain1
+ run_iptables -A $chain $macpart $physdev_part -j RETURN
else
for address in $(separate_list $addresses) ; do
- run_iptables2 -A $chain $macpart -s $address $physdev_part -j
$chain1
+ run_iptables2 -A $chain $macpart -s $address $physdev_part -j
RETURN
done
fi
done $TMP_DIR/maclist
@@ -2083,8 +2083,7 @@
# chains
#
for interface in $maclist_interfaces; do
- chain=$(mac_chain $interface)
- chain1=$(macrecent_target $interface)
+ [ -n $MACLIST_TTL ] chain=$(macrecent_target $interface) ||
chain=$(mac_chain $interface)
blob=$(ip link show $interface 2 /dev/null)
@@ -2092,12 +2091,13 @@
fatal_error Interface $interface must
Bug#318946: User expectations and shorewall
* Florian Weimer [EMAIL PROTECTED]: * Martin Schulze: What was the behaviour pre-sarge? What is the behaviour post-sarge (or rather in sarge)? Do you mean before and after the upstream security update? The terms pre-sarge/post-sarge do not make much sense to me in this context, I'm afraid. What do you think is the vulnerability? The vulnerability is that the firewall fails to enforce the security policy the user has configured. Yes, that is the problem. You expect that certain kind of traffic is blocked but in fact it isn't. [...] Here's a draft, in case you want to upload a fixed package. (Note that I have yet to test Lorenzo's new package.) -- Debian Security Advisory DSA ???-1 [EMAIL PROTECTED] http://www.debian.org/security/ September ???, 2005 http://www.debian.org/security/faq -- Package: shorewall Vulnerability : programming error Problem-Type : remote Debian-specific: no CVE ID : CAN-2005- Debian Bug : 318946 Supernaut noticed that shorewall could generate an iptables configuration which is significantly more permissive than the rule set given in the shorewall configuration. [...] I think it perfectly explains the issue. -- lorenzo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318978: Shorewall upgrade question asked prematurely, there is no way to answer the question when asked
* Manoj Srivastava [EMAIL PROTECTED]: Package: shorewall Version: 2.4.1-2 Severity: normal Hi, On upgrade, shorewall asks the scary looking question: Did you check your configuration and do you want to restart Shorewall right now? Followed by: == This is a major release of Shorewall that introduces some changes in the configuration files. You have to check carefully your configuration before restarting your firewall to avoid failures and network blackout. The changes are listed in /usr/share/doc/shorewall/releasenotes.txt.gz. == Except, of course, they are not yet: the file there is the old file, since the package has not been unpacked. If the user is not paying attention, they can read the file, check their configuration find that is is fine, upgrade, and then procxeed to have holes in the firewall or blackouts. There is no information yet as to what changes are going to take place, and thus this question *MUS* be asked in the postinst, and _NOT_ in the .config. I have left the severity at normal, feel free to upgrade severity to important. I'll fix it as soon as possible moving the question to the postinst script as you suggested. I must admit that I don't like the scary question at all but it's the only way I know to inform the user about problems that may arise during the upgrade to a new major release. Have you got any suggestion about how to better handle such notification? Thank you for your report and for your help. -- lorenzo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318946: shorewall: A client accepted by MAC address filtering to bypass any other rule
Package: shorewall Version: 2.4.1-2 Severity: critical Tags: security A client accepted by MAC address filtering can bypass any other rule. If MACLIST_TTL is set to a value greater than 0 or MACLIST_DISPOSITION is set to ACCEPT in /etc/shorewall/shorewall.conf (default is MACLIST_TTL=0 and MACLIST_DISPOSITION=REJECT), and a client is positively identified through its MAC address, it bypasses all other policies/rules in place, thus gaining access to all open services on the firewall. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.11 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages shorewall depends on: ii debconf 1.4.49 Debian configuration management sy ii iproute 20041019-3 Professional tools to control the ii iptables 1.2.11-10 Linux kernel 2.4+ iptables adminis -- debconf information: shorewall/upgrade_20_22: shorewall/upgrade_14_20: shorewall/upgrade_to_14: shorewall/warnrfc1918: * shorewall/dont_restart: shorewall/major_release: true -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#314470: shorewall: fireflier should be installable at the same time
* Remi Vanicat [EMAIL PROTECTED]: Package: shorewall Severity: wishlist Hello, the fireflier documentation say that it could be used in parallel to another firewall, fireflier using is own user-space rule, and the other firewall ruling the iptables (who can use the QUEUE target for packet it don't know how to handle for example), but the shorewall debian package conflict with fireflier, making this impossible. Hello, the bug will be fixed in the next debian release of the package. -- lorenzo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#312046: shorewall: [INTL:fr] French debconf templates translation
* Christian Perrier [EMAIL PROTECTED]: Package: shorewall Version: N/A Severity: wishlist Tags: patch l10n Please find attached the french debconf templates update, proofread by the debian-l10n-french mailing list contributors. Thank you very much. Please, for the next updates you make to this package templates, consider warning translators before uploading the package and leave them a delay for translation updates. The podebconf-report-po utility which is in the po-debconf package starting from its 0.8.15 version will do this job for you. See its man page for details. I'll do that as soon as possible. -- lorenzo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308380: shorewall: upgrade to version = 2.0.1 leaves obsolete rfc1918 file
* Debian User [EMAIL PROTECTED]: Package: shorewall Version: 2.0.15-1 Severity: important An upgrade from a version 2.0.1 to a more recent version does not touch the the old configuration under /etc/shorewall, in particular the obosolete rf1918 file is left, which will then be used by the newer shorewall version. the function of that file has been split between the rfc1918 file and the bogons file since version 2.0.1. If the user only uses the 'norf1918' option in the upgraded shorewall version, she/he might expect, that this option only applies to adresses from the 172.16.0.0/12, 192.168.0.0/16, 10.0.0.0/8, as described in the new documentation. Since the old rfc1918 file is still left in the shorewall configuration directory, shorewall also applies the 'norfc1918' option to adresses from the bogon range. If the ISP of the user switches to a new assigned IP range which has been listed in in the old outdated rfc1918 file, the firewall might suddenly drop connection attempts to the outside interface. A warning should be issued to the user to move the obsolete file out of the way. Thank you for your report. The bug will be fixed in the next Debian release. -- lorenzo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#305066: shorewall: add new rule for NFS server
* Jari Aalto [EMAIL PROTECTED]: Package: shorewall Version: 2.2.3-1 Severity: wishlist Please all following AllowNFS and DenyNFS rules: rpcinfo -p 102 tcp111 portmapper 102 udp111 portmapper 134 tcp 2049 nfs 151 udp850 mountd 151 tcp853 mountd Mountd ports are assigned dinamically at startup so such an action would be completely useless. Take a look at: http://www.linuxdocs.org/HOWTOs/NFS-HOWTO/security.html for more informations and firewalling solutions. -- lorenzo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307295: shorewall: Please guarantee a working firewall after upgrade
* John Summerfield [EMAIL PROTECTED]: Package: shorewall Version: 2.2.3-1 Severity: normal I maintain the software on several systems remotely, connecting over they Internet. I am concerned that one day an upgrade to shorwall will leave me with a broken firewall and the need to visit the site or worse, find local hired help. Hi John, I have the same worries. I usually use debconf to warn users about possible problems with configuration files but I'm aware that that couldn't be enough and problems may arise all the same. Unfortunately shorewall check is almost unsupported, that would be the best solution in my opinion. Ideas that come to mind: Use alternatives to choose the active version. This should be in manual mode. Store config files in version-dependant directories - /etc/shorewall22 etc. Use iptables-save to save a working firewall script and make this the default, to be changed at a time of the sysadmin's choosing. I cannot understand what really is your first idea, but I believe the second is much more insteresting: backup your current configuration before restart the firewall and eventually restore it. I'll think about that... This is quite a serious concern to me; I've been cracked and my firewall rules are part of my plan to limit (by IP address range) locations from which connexions can be made to sensitive services. -- lorenzo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#302723: Reserved subnetworks listed in the /etc/shorewall/rfc1918 seems to be wrong
* Patrice Weber [EMAIL PROTECTED]: Package: shorewall Version: 2.2.2-1 Severity: important Hello, The list of subnetworks generated by the python program and present in the rfc1918 file are not correct (for example : 83.0.0.0/8). This is why I went to http://www.shorewall.net/pub/shorewall/contrib/iana_reserved/ and used this python program to generate this new list, which seems more correct : 0.0.0.0/7 logdrop # Reserved 2.0.0.0/8 logdrop # Reserved 5.0.0.0/8 logdrop # Reserved 7.0.0.0/8 logdrop # Reserved 10.0.0.0/8 logdrop # Reserved 23.0.0.0/8 logdrop # Reserved 27.0.0.0/8 logdrop # Reserved 31.0.0.0/8 logdrop # Reserved 36.0.0.0/7 logdrop # Reserved 39.0.0.0/8 logdrop # Reserved 41.0.0.0/8 logdrop # Reserved 42.0.0.0/8 logdrop # Reserved 74.0.0.0/7 logdrop # Reserved 76.0.0.0/6 logdrop # Reserved 89.0.0.0/8 logdrop # Reserved 90.0.0.0/7 logdrop # Reserved 92.0.0.0/6 logdrop # Reserved 96.0.0.0/4 logdrop # Reserved 112.0.0.0/5 logdrop # Reserved 120.0.0.0/6 logdrop # Reserved 127.0.0.0/8 logdrop # Reserved 173.0.0.0/8 logdrop # Reserved 174.0.0.0/7 logdrop # Reserved 176.0.0.0/5 logdrop # Reserved 184.0.0.0/6 logdrop # Reserved 189.0.0.0/8 logdrop # Reserved 190.0.0.0/8 logdrop # Reserved 197.0.0.0/8 logdrop # Reserved 223.0.0.0/8 logdrop # Reserved 240.0.0.0/4 logdrop # Reserved Could you check this list against the packaged one ? I can update the bogons file but we will have the same problem in the future, especially when Sarge will become stable as the package will be update only for security bugs. For this reason I decided to convert the python script you used to update your bogons file into perl, include it into the debian package and add a notice into the README.Debian. Please take a look to that file and let me know if the proposed solution suits your needs, otherwise we can think about a better one. -- lorenzo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#301622: [l10n] Initial Czech translation of shorewall debconf messages
* Miroslav Kure [EMAIL PROTECTED]: Package: shorewall Severity: wishlist Tags: l10n, patch Hi, in attachement there is initial Czech translation (cs.po) of shorewall debconf messages, please include it. Hi, thank you for the translation. It will be included in the next release of the package. -- lorenzo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#298266: shorewall: [INTL:fr] French debconf templates translation
* Christian Perrier [EMAIL PROTECTED]: Package: shorewall Version: N/A Severity: wishlist Tags: patch l10n Please find attached the french debconf templates update, proofread by the debian-l10n-french mailing list contributors. Please, for the next updates you make to this package templates, consider warning translators before uploading the package and leave them a delay for translation updates. The podebconf-report-po utility which is in the po-debconf package starting from its 0.8.15 version will do this job for you. See its man page for details. If you already did this, please forget about these remarks, of courseThis message is generic..:-) Thank you for the template (it will be included in next shorewall debian release) and thank you for the suggestion, I'll look in to podebconf-report-po. -- lorenzo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#294842: shorewall: Typo in firewall script breaks rejNotSyn
* Juergen Kreileder [EMAIL PROTECTED]: Package: shorewall Version: 2.0.15-1 Severity: normal Tags: patch There's a typo in /usr/share/shorewall/firewall that breaks the rejNotSyn action. Here's a fix: [...] Thank you for your report and for your patch. I informed the upstream author. -- lorenzo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293065: shorewall: Checks for invalid packages despite dropunclean not set; breaks assymetric routing
* Brian May [EMAIL PROTECTED]: Package: shorewall Version: 2.0.7-1 Severity: important Hello, We route outgoing packets for several satellite connections. After a big set of upgrades (including kernel version) today, these asymmetric connections stopped working. I found the culprit: Chain FORWARD (policy DROP 62 packets, 3392 bytes) pkts bytes target prot opt in out source destination 45 2557 DROP !icmp -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID [...] This rule is the very first one listed for FORWARD, and the second one for INPUT and OUTPUT (the first one is lo specific). On one hand I suspect this use to work, and with recent kernel versions (2.6.9+) the meaning of INVALID has become more strict. One the other hand, I haven't set dropunclean for any of the interfaces, and checking the value this early would seem to render LOGUNCLEAN invalid, as any unclean packets have already been dropped before it gets this far. I have already changed the newnotsyn file/rule to cope with my asymmetric routing needs, but this isn't used until after the packets are already dropped. Hello, I got in touch with the upstream author. A solution is proposed in the new upstream release. Quoting from the changelog: Recent 2.6 kernels include code that evaluates TCP packets based on TCP Window analysis. This can cause packets that were previously classified as NEW or ESTABLISHED to be classified as INVALID. The new kernel code can be disabled by including this command in your /etc/shorewall/init file: echo 1 /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal Additional kernel logging about INVALID TCP packets may be obtained by adding this command to /etc/shorewall/init: echo 1 /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid Traditionally, Shorewall has dropped INVALID TCP packets early. The new DROPINVALID option allows INVALID packets to be passed through the normal rules chains by setting DROPINVALID=No. If not specified or if specified as empty (e.g., DROPINVALID=) then DROPINVALID=Yes is assumed. The new package will be ready soon. -- lorenzo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291548: autopsy: sleuthkit renamed dstat to datastat
* Kenny Duffus [EMAIL PROTECTED]: Package: autopsy Version: 2.03-2 Severity: normal Tags: patch In 1.73-3 the sleuthkit package renamed dstat to datastat to solve duplicate filenames. Thank you for your report and for your patch. The new version of the packages fixed the reported bug. -- lorenzo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291550: autopsy: defined locations of md5sum and sha1sum not always used
* Kenny Duffus [EMAIL PROTECTED]: Package: autopsy Version: 2.03-2 Severity: normal Tags: patch Autopsy defines the locations of programs to produce MD5 and SHA1 checksums in /usr/share/autopsy/conf.pl however these variables are not used everywhere. As a result autopsy tries to use /usr/bin/md5 and /usr/bin/sha1. Thank you for your report and for your patch. The new version of the packages fixed the reported bug. -- lorenzo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
