From jpdalbec at ysu.edu Thu Dec 1 22:48:17 2005 From: jpdalbec at ysu.edu (John Dalbec) Date: Thu, 01 Dec 2005 17:48:17 -0500 Subject: PHP IMAP segfault In-Reply-To: <20051201170033.BBDB4744B1@hormel.redhat.com> References: <20051201170033.BBDB4744B1@hormel.redhat.com> Message-ID: <438F7DB1.30506@ysu.edu> On Wed, 30 Nov 2005 at 12:52:46 -0700, Michal Jaegermann wrote: > On Wed, Nov 30, 2005 at 12:09:09PM -0500, John Dalbec wrote: > >>> (gdb) backtrace >>> #0 0x409ba612 in zif_imap_fetch_overview () from /usr/lib/php4/imap.so >>> #1 0x67696c61 in ?? () >>> Cannot access memory at address 0x62656420 > > > 0x62656420 actually spells " deb" (little endian) and 0x67696c61 > is "alig". Sounds suspiciously like > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170411 > which you actually posted with that exception that depending on > what distro you are using it may be either imap or libc-client > libraries (or maybe php has a copy of this code?). So you may want > to look as well at > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170521 > > Clearly this may be a wrong guess. > > Michal The code that I was concerned about is in rfc822.c, not mail.c. But I guess the stack corruption could have occurred in one of the mail_ functions (probably mail_fetch_structure). PHP-IMAP statically links libc-client.a so technically after any fix affecting this library PHP should be rebuilt. The segfault doesn't occur until fairly late in the subroutine when it tries to access the corrupted stack. I tried to single-step through it to see whether I could find the point of stack corruption but I didn't have the patience for it and I think the IMAP connections were timing out and causing unrelated segfaults (also with stack corruption): Program received signal SIGSEGV, Segmentation fault. 0x4044b5f8 in object.2 () from /etc/httpd/modules/libphp4.so (gdb) bt #0 0x4044b5f8 in object.2 () from /etc/httpd/modules/libphp4.so #1 0x0839767c in ?? () #2 0x40452168 in object.2 () from /etc/httpd/modules/libphp4.so #3 0x40459f12 in object.2 () from /etc/httpd/modules/libphp4.so #4 0x40438582 in object.2 () from /etc/httpd/modules/libphp4.so #5 0x4045623e in object.2 () from /etc/httpd/modules/libphp4.so #6 0x404565ab in object.2 () from /etc/httpd/modules/libphp4.so #7 0x4044e06c in object.2 () from /etc/httpd/modules/libphp4.so #8 0x4044b894 in object.2 () from /etc/httpd/modules/libphp4.so #9 0x08051bf9 in run_cleanups () #10 0x080506ab in ap_clear_pool () #11 0x08050711 in ap_destroy_pool () #12 0x0805067c in ap_clear_pool () #13 0x0805f7bd in child_main () #14 0x0805fe3a in make_child () #15 0x0805ff7d in startup_children () #16 0x080605d0 in standalone_main () #17 0x08060ed3 in main () #18 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6 You can find a somewhat-sanitized version of the offending e-mail message at http://unix1.cc.ysu.edu/~jpdalbec/adam.txt including ..., debalig at aol.com, .... Maybe I'll try a binary search setting different breakpoints. John From jpdalbec at ysu.edu Fri Dec 2 16:48:14 2005 From: jpdalbec at ysu.edu (John Dalbec) Date: Fri, 02 Dec 2005 11:48:14 -0500 Subject: PHP IMAP segfault In-Reply-To: <20051201170033.BBDB4744B1@hormel.redhat.com> References: <20051201170033.BBDB4744B1@hormel.redhat.com> Message-ID: <43907ACE.10301@ysu.edu> On Wed, 30 Nov 2005 12:52:46 -0700 Michal Jaegermann wrote: > 0x62656420 actually spells " deb" (little endian) and 0x67696c61 > is "alig". Sounds suspiciously like > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170411 > which you actually posted with that exception that depending on > what distro you are using it may be either imap or libc-client > libraries (or maybe php has a copy of this code?). So you may want > to look as well at > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170521 > > Clearly this may be a wrong guess. > > Michal I built IMAP with the mail.c patch and installed it, then I built PHP which should have incorporated the new libc-client. I installed IMAP and PHP on a test server but I didn't upgrade the production IMAP server since I don't think this patch affects the imapd server. Does it affect imapd? In any case, the segfault I saw continues to occur. The stack becomes corrupted after rfc822_write_address(address, env->to); I think I can fix the problem by patching rfc822_parse_adrlist (which is called by mail_fetch_structure) to temporarily truncate each header to length MAILTMPLEN-1 before parsing. I'll build and test packages before posting the patch. Thanks, John From michal at harddata.com Fri Dec 2 17:13:25 2005 From: michal at harddata.com (Michal Jaegermann) Date: Fri, 2 Dec 2005 10:13:25 -0700 Subject: PHP IMAP segfault In-Reply-To: <43907ACE.10301@ysu.edu> References: <20051201170033.BBDB4744B1@hormel.redhat.com> <43907ACE.10301@ysu.edu> Message-ID: <20051202171325.GB19851@mail.harddata.com> On Fri, Dec 02, 2005 at 11:48:14AM -0500, John Dalbec wrote: > > I built IMAP with the mail.c patch and installed it, then I built PHP which > should have incorporated the new libc-client. I installed IMAP and PHP on > a test server but I didn't upgrade the production IMAP server since I don't > think this patch affects the imapd server. Does it affect imapd? The original report and security advisory CAN-2005-2933 were for imapd. So, unless your IMAP server program is linking dynamically a fixed libc-client, and it was restarted, then it sounds that it is affected. Or maybe I misuderstood what you have in mind. > In any case, the segfault I saw continues to occur. The stack becomes > corrupted after rfc822_write_address(address, env->to); It is possible that you found another bug. > I think I can fix the problem by patching rfc822_parse_adrlist (which is > called by mail_fetch_structure) to temporarily truncate each header to > length MAILTMPLEN-1 before parsing. If those headers are stored without checks in some fixed size memory region, and headers are bigger than that, then bad things will happen. Backtraces you posted suggest that stack was indeed corrupted. In such case this is a security issue. Michal From jkeating at j2solutions.net Fri Dec 2 17:21:42 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 02 Dec 2005 09:21:42 -0800 Subject: PHP IMAP segfault In-Reply-To: <20051202171325.GB19851@mail.harddata.com> References: <20051201170033.BBDB4744B1@hormel.redhat.com> <43907ACE.10301@ysu.edu> <20051202171325.GB19851@mail.harddata.com> Message-ID: <1133544102.4054.46.camel@yoda.loki.me> On Fri, 2005-12-02 at 10:13 -0700, Michal Jaegermann wrote: > If those headers are stored without checks in some fixed size memory > region, and headers are bigger than that, then bad things will > happen. Backtraces you posted suggest that stack was indeed corrupted. > In such case this is a security issue. If we can prove the issue and reproduce it, we need to alert vendor-sec for a CVE, and then keep quite about it until the public date is reached. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From marcdeslauriers at videotron.ca Sat Dec 3 01:31:16 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Fri, 02 Dec 2005 20:31:16 -0500 Subject: [Updated] [FLSA-2005:166943] Updated php packages fix security issues Message-ID: <4390F564.2090603@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated php packages fix security issues Advisory ID: FLSA:166943 Issue date: 2005-12-02 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2005-2498 CVE-2005-3390 CVE-2005-3389 CVE-2005-3388 CVE-2005-3353 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: Updated PHP packages that fix multiple security issues are now available. PHP is an HTML-embedded scripting language commonly used with the Apache HTTP Web server. [Updated 2nd December 2005] Red Hat Linux 9 packages have been updated to add missing security patches. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 Fedora Core 1 - i386 Fedora Core 2 - i386 3. Problem description: A bug was discovered in the PEAR XML-RPC Server package included in PHP. If a PHP script is used which implements an XML-RPC Server using the PEAR XML-RPC package, then it is possible for a remote attacker to construct an XML-RPC request which can cause PHP to execute arbitrary PHP commands as the 'apache' user. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-2498 to this issue. A flaw was found in the way PHP registers global variables during a file upload request. A remote attacker could submit a carefully crafted multipart/form-data POST request that would overwrite the $GLOBALS array, altering expected script behavior, and possibly leading to the execution of arbitrary PHP commands. Please note that this vulnerability only affects installations which have register_globals enabled in the PHP configuration file, which is not a default or recommended option. The Common Vulnerabilities and Exposures project assigned the name CVE-2005-3390 to this issue. A flaw was found in the PHP parse_str() function. If a PHP script passes only one argument to the parse_str() function, and the script can be forced to abort execution during operation (for example due to the memory_limit setting), the register_globals may be enabled even if it is disabled in the PHP configuration file. This vulnerability only affects installations that have PHP scripts using the parse_str function in this way. (CVE-2005-3389) A Cross-Site Scripting flaw was found in the phpinfo() function. If a victim can be tricked into following a malicious URL to a site with a page displaying the phpinfo() output, it may be possible to inject javascript or HTML content into the displayed page or steal data such as cookies. This vulnerability only affects installations which allow users to view the output of the phpinfo() function. As the phpinfo() function outputs a large amount of information about the current state of PHP, it should only be used during debugging or if protected by authentication. (CVE-2005-3388) A denial of service flaw was found in the way PHP processes EXIF image data. It is possible for an attacker to cause PHP to crash by supplying carefully crafted EXIF image data. (CVE-2005-3353) Users of PHP should upgrade to these updated packages, which contain backported patches that resolve 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: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166943 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/php-4.1.2-7.3.18.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/php-4.1.2-7.3.18.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/php-devel-4.1.2-7.3.18.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/php-imap-4.1.2-7.3.18.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/php-ldap-4.1.2-7.3.18.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/php-manual-4.1.2-7.3.18.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/php-mysql-4.1.2-7.3.18.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/php-odbc-4.1.2-7.3.18.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/php-pgsql-4.1.2-7.3.18.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/php-snmp-4.1.2-7.3.18.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/php-4.2.2-17.17.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/php-4.2.2-17.17.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/php-devel-4.2.2-17.17.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/php-imap-4.2.2-17.17.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/php-ldap-4.2.2-17.17.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/php-manual-4.2.2-17.17.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/php-mysql-4.2.2-17.17.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/php-odbc-4.2.2-17.17.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/php-pgsql-4.2.2-17.17.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/php-snmp-4.2.2-17.17.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/php-4.3.11-1.fc1.3.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/php-4.3.11-1.fc1.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/php-devel-4.3.11-1.fc1.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/php-domxml-4.3.11-1.fc1.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/php-imap-4.3.11-1.fc1.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/php-ldap-4.3.11-1.fc1.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/php-mbstring-4.3.11-1.fc1.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/php-mysql-4.3.11-1.fc1.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/php-odbc-4.3.11-1.fc1.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/php-pgsql-4.3.11-1.fc1.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/php-snmp-4.3.11-1.fc1.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/php-xmlrpc-4.3.11-1.fc1.3.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/php-4.3.11-1.fc2.4.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/php-4.3.11-1.fc2.4.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/php-devel-4.3.11-1.fc2.4.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/php-domxml-4.3.11-1.fc2.4.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/php-imap-4.3.11-1.fc2.4.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/php-ldap-4.3.11-1.fc2.4.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/php-mbstring-4.3.11-1.fc2.4.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/php-mysql-4.3.11-1.fc2.4.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/php-odbc-4.3.11-1.fc2.4.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/php-pear-4.3.11-1.fc2.4.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/php-pgsql-4.3.11-1.fc2.4.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/php-snmp-4.3.11-1.fc2.4.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/php-xmlrpc-4.3.11-1.fc2.4.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 8bdf500386f11c6484c04361095061cce6c5c5f8 redhat/7.3/updates/i386/php-4.1.2-7.3.18.legacy.i386.rpm 592c870e99523279267a0daea98c7dc08b09e5ca redhat/7.3/updates/i386/php-devel-4.1.2-7.3.18.legacy.i386.rpm 9f84a76296d88673ba8354f416a6ee75b86afb3f redhat/7.3/updates/i386/php-imap-4.1.2-7.3.18.legacy.i386.rpm 8c4b7136f2cac5f8eea394db819e0f67a973e4ff redhat/7.3/updates/i386/php-ldap-4.1.2-7.3.18.legacy.i386.rpm d579f333822efd11fb2fc1364d2b9218bd3547a9 redhat/7.3/updates/i386/php-manual-4.1.2-7.3.18.legacy.i386.rpm 50ec5b4419f70839b5c0b328a605189137477d12 redhat/7.3/updates/i386/php-mysql-4.1.2-7.3.18.legacy.i386.rpm a73300b91e8ac8aee1792f5ec0975fb312b7f780 redhat/7.3/updates/i386/php-odbc-4.1.2-7.3.18.legacy.i386.rpm af7de72af9756d6085d255544de389eb8f355c39 redhat/7.3/updates/i386/php-pgsql-4.1.2-7.3.18.legacy.i386.rpm d96277ec0aa9d37af3372eedb0868249ca96ff51 redhat/7.3/updates/i386/php-snmp-4.1.2-7.3.18.legacy.i386.rpm 8a03b8a7832aba6baf825ec64778f4a321707405 redhat/7.3/updates/SRPMS/php-4.1.2-7.3.18.legacy.src.rpm a3770f044b61275fe671c2e41452fdc3556cd68b redhat/9/updates/i386/php-4.2.2-17.17.legacy.i386.rpm 282e79a54800f0f078702983a54391ddf97637eb redhat/9/updates/i386/php-devel-4.2.2-17.17.legacy.i386.rpm 08cf701a137ed486294e7768d3f1464d40ee72b0 redhat/9/updates/i386/php-imap-4.2.2-17.17.legacy.i386.rpm 1b882b5ad1933a567eeb03e9ea40f59a124bfd4f redhat/9/updates/i386/php-ldap-4.2.2-17.17.legacy.i386.rpm 11ce31a48256813fd0b61975b4189f9053ea0b37 redhat/9/updates/i386/php-manual-4.2.2-17.17.legacy.i386.rpm a23a1e0fc5f254f0b3284c20f35736e9c0cb70f4 redhat/9/updates/i386/php-mysql-4.2.2-17.17.legacy.i386.rpm 11204a5ad7b12dc80a021ebf23acaf5c791c518d redhat/9/updates/i386/php-odbc-4.2.2-17.17.legacy.i386.rpm 791b822042fed0cd3936e0148a51a215db3d7f78 redhat/9/updates/i386/php-pgsql-4.2.2-17.17.legacy.i386.rpm b93fc807a74caefeb1f0d848b4a6f2c268ec1508 redhat/9/updates/i386/php-snmp-4.2.2-17.17.legacy.i386.rpm 5df94b0dda6f043a8312a03be66689c2abd373ab redhat/9/updates/SRPMS/php-4.2.2-17.17.legacy.src.rpm cd04cc6c329e18a9c0c989cdb9a5fcdc9b6712c8 fedora/1/updates/i386/php-4.3.11-1.fc1.3.legacy.i386.rpm bdb82f6017f088488443cec5f97650aa172714bd fedora/1/updates/i386/php-devel-4.3.11-1.fc1.3.legacy.i386.rpm 5921f184247991ddac4b398a617abea8768cd9d5 fedora/1/updates/i386/php-domxml-4.3.11-1.fc1.3.legacy.i386.rpm b38b1aabdcee19a8764b9156ffbd4a7fd15c5345 fedora/1/updates/i386/php-imap-4.3.11-1.fc1.3.legacy.i386.rpm ecb2bfd639fe1e44a389e2527babbd912279d6ad fedora/1/updates/i386/php-ldap-4.3.11-1.fc1.3.legacy.i386.rpm 3bd193c7d75216cbe34cee7c637be042b2197693 fedora/1/updates/i386/php-mbstring-4.3.11-1.fc1.3.legacy.i386.rpm 0883a4ef7c03d8faebc90ed0f4a138e1f9b64c9f fedora/1/updates/i386/php-mysql-4.3.11-1.fc1.3.legacy.i386.rpm 62017bd8700dcaceb2280443abb3e6fd17e9458e fedora/1/updates/i386/php-odbc-4.3.11-1.fc1.3.legacy.i386.rpm c9a90440e780eb1420100ed8b0e28d92ddea0295 fedora/1/updates/i386/php-pgsql-4.3.11-1.fc1.3.legacy.i386.rpm ef627102ded443de2e78c33a29f76c6066f7bf5a fedora/1/updates/i386/php-snmp-4.3.11-1.fc1.3.legacy.i386.rpm 38da5e66ead97e573a7105ad4a62a14c75763268 fedora/1/updates/i386/php-xmlrpc-4.3.11-1.fc1.3.legacy.i386.rpm d2b93da45a735956e980e8a5401c4b171644794a fedora/1/updates/SRPMS/php-4.3.11-1.fc1.3.legacy.src.rpm edce472b6a404a45bb0187ed2058929b51850423 fedora/2/updates/i386/php-4.3.11-1.fc2.4.legacy.i386.rpm 5f55d05ec4dbbbd6717a14f495bfe9948bec3837 fedora/2/updates/i386/php-devel-4.3.11-1.fc2.4.legacy.i386.rpm d308529686de245b33057c4ce1a7e0435ba748e6 fedora/2/updates/i386/php-domxml-4.3.11-1.fc2.4.legacy.i386.rpm a85ba72dbcf8357c63bd7ddd71a8e7b1e270a0d0 fedora/2/updates/i386/php-imap-4.3.11-1.fc2.4.legacy.i386.rpm 8856c97f65e6dfdf5241faa5294a9a8883de049b fedora/2/updates/i386/php-ldap-4.3.11-1.fc2.4.legacy.i386.rpm f7d1159e5756ba33282920d0923bcd338306a2c8 fedora/2/updates/i386/php-mbstring-4.3.11-1.fc2.4.legacy.i386.rpm 24d23bd41dc5c3233019a86a988057dfa8fd3576 fedora/2/updates/i386/php-mysql-4.3.11-1.fc2.4.legacy.i386.rpm 618b32b0c28b71755c8f487b035649e44213b2cf fedora/2/updates/i386/php-odbc-4.3.11-1.fc2.4.legacy.i386.rpm cf728abb52acc26f2f6d33dbb5135fdbd2ec4df0 fedora/2/updates/i386/php-pear-4.3.11-1.fc2.4.legacy.i386.rpm fe3a23d81b92930426f7dd3a5b687ef979d8a3b9 fedora/2/updates/i386/php-pgsql-4.3.11-1.fc2.4.legacy.i386.rpm 771c5041ed29045e4de59bcacbc0c640247c80e7 fedora/2/updates/i386/php-snmp-4.3.11-1.fc2.4.legacy.i386.rpm 2962cc479b53c181dd67fdd4008ee904d81e71ac fedora/2/updates/i386/php-xmlrpc-4.3.11-1.fc2.4.legacy.i386.rpm 2c6d2007423a9334a22451521a742ca942677c57 fedora/2/updates/SRPMS/php-4.3.11-1.fc2.4.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=CVE-2005-2498 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3390 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3389 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3388 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3353 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: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Wed Dec 7 04:16:12 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 06 Dec 2005 23:16:12 -0500 Subject: Fedora Legacy Test Update Notification: mozilla Message-ID: <4396620C.5010602@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2005-168375 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168375 2005-12-06 --------------------------------------------------------------------- Name : mozilla Versions : rh7.3: mozilla-1.7.12-0.73.2.legacy Versions : rh9: mozilla-1.7.12-0.90.1.legacy Versions : fc1: mozilla-1.7.12-1.1.1.legacy Versions : fc2: mozilla-1.7.12-1.2.1.legacy Summary : A Web browser. Description : Mozilla is an open-source Web browser, designed for standards compliance, performance, and portability. --------------------------------------------------------------------- Update Information: Updated mozilla packages that fix several security bugs are now available. Mozilla is an open source Web browser, advanced email and newsgroup client, IRC chat client, and HTML editor. A bug was found in the way Mozilla processes XBM image files. If a user views a specially crafted XBM file, it becomes possible to execute arbitrary code as the user running Mozilla. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-2701 to this issue. A bug was found in the way Mozilla processes certain Unicode sequences. It may be possible to execute arbitrary code as the user running Mozilla, if the user views a specially crafted Unicode sequence. (CVE-2005-2702) A bug was found in the way Mozilla makes XMLHttp requests. It is possible that a malicious web page could leverage this flaw to exploit other proxy or server flaws from the victim's machine. It is also possible that this flaw could be leveraged to send XMLHttp requests to hosts other than the originator; the default behavior of the browser is to disallow this. (CVE-2005-2703) A bug was found in the way Mozilla implemented its XBL interface. It may be possible for a malicious web page to create an XBL binding in a way that would allow arbitrary JavaScript execution with chrome permissions. Please note that in Mozilla 1.7.10 this issue is not directly exploitable and would need to leverage other unknown exploits. (CVE-2005-2704) An integer overflow bug was found in Mozilla's JavaScript engine. Under favorable conditions, it may be possible for a malicious web page to execute arbitrary code as the user running Mozilla. (CVE-2005-2705) A bug was found in the way Mozilla displays about: pages. It is possible for a malicious web page to open an about: page, such as about:mozilla, in such a way that it becomes possible to execute JavaScript with chrome privileges. (CVE-2005-2706) A bug was found in the way Mozilla opens new windows. It is possible for a malicious web site to construct a new window without any user interface components, such as the address bar and the status bar. This window could then be used to mislead the user for malicious purposes. (CVE-2005-2707) Users of Mozilla are advised to upgrade to this updated package that contains Mozilla version 1.7.12 and is not vulnerable to these issues. --------------------------------------------------------------------- Changelogs rh7.3: * Wed Nov 30 2005 David Eisenstein 37:1.7.12-0.73.2.legacy - Change build options to create nondebug versions and stripped libs. * Wed Oct 05 2005 Pekka Savola 37:1.7.12-0.73.1.legacy - Update to 1.7.12 to fix security problems (#168375) rh9: * Thu Sep 22 2005 Pekka Savola 37:1.7.12-0.90.1.legacy - Update to 1.7.12 to fix a couple of security issues (#168375) fc1: * Mon Oct 03 2005 David Eisenstein 37:1.7.12-1.1.1.legacy - Rebuilt from RHEL 3 as Fedora Legacy update for Fedora Core 1 - Changed useragent vendor tag to Fedora by copying Marc's mozilla- redhat-default-prefs.js from 1.7.10 - Removed Network category from mozilla.desktop - Added missing gnome-vfs2-devel and desktop-file-utils to BuildRequires fc2: * Thu Oct 06 2005 Pekka Savola 37:1.7.12-1.2.1.legacy - Update to 1.7.12 to fix a number of security issues (#168375) --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh7.3: 0ae10dbacdb2472a628a50bf8c5e8f2f54c05e8b redhat/7.3/updates-testing/i386/mozilla-1.7.12-0.73.2.legacy.i386.rpm bff4f2c1d9275bd23d77485aaba9cba2711cd059 redhat/7.3/updates-testing/i386/mozilla-chat-1.7.12-0.73.2.legacy.i386.rpm f03b386ccc78f9e7701e9a13bc7b8d20a1ffa6a1 redhat/7.3/updates-testing/i386/mozilla-devel-1.7.12-0.73.2.legacy.i386.rpm 07c3079647613a446cc228c52dd30bf680577a7a redhat/7.3/updates-testing/i386/mozilla-dom-inspector-1.7.12-0.73.2.legacy.i386.rpm 6b784f7a3d316f2cba036edff3de9b0655a931a0 redhat/7.3/updates-testing/i386/mozilla-js-debugger-1.7.12-0.73.2.legacy.i386.rpm 3117c8a563e96c6680a67d54838cb80edd2d1bdb redhat/7.3/updates-testing/i386/mozilla-mail-1.7.12-0.73.2.legacy.i386.rpm 7c8a98aa917aa25a8da0111ddf0dd14af97dae29 redhat/7.3/updates-testing/i386/mozilla-nspr-1.7.12-0.73.2.legacy.i386.rpm af0566c481a1c71ca829acbe1a6236a0c8357500 redhat/7.3/updates-testing/i386/mozilla-nspr-devel-1.7.12-0.73.2.legacy.i386.rpm 13f7e9de34bde44148fc937b8af67a646d05a088 redhat/7.3/updates-testing/i386/mozilla-nss-1.7.12-0.73.2.legacy.i386.rpm 38a2c8ae78b113999ca96cb6e6cded4546e8d12f redhat/7.3/updates-testing/i386/mozilla-nss-devel-1.7.12-0.73.2.legacy.i386.rpm d4ed2b56c7c9d3fce0798f8c8896532513e39cd0 redhat/7.3/updates-testing/SRPMS/mozilla-1.7.12-0.73.2.legacy.src.rpm 5e150015de68be25c45dad3a1bd9b3a2d377845c redhat/7.3/updates-testing/i386/galeon-1.2.14-0.73.5.legacy.i386.rpm 386ee463b84c4749942c1cb0c9f9f56111729c1c redhat/7.3/updates-testing/SRPMS/galeon-1.2.14-0.73.5.legacy.src.rpm rh9: 5282b6d81fa7dbd45f506921da3800fa233ace20 redhat/9/updates-testing/i386/mozilla-1.7.12-0.90.1.legacy.i386.rpm c4ae587e77b7905666079958c199f01726542afb redhat/9/updates-testing/i386/mozilla-chat-1.7.12-0.90.1.legacy.i386.rpm 65dd772102dd18492e3d1dcf57c25c8e2dc266b4 redhat/9/updates-testing/i386/mozilla-devel-1.7.12-0.90.1.legacy.i386.rpm d9037fbae761a3be89464b49a3e4d0144fe5f902 redhat/9/updates-testing/i386/mozilla-dom-inspector-1.7.12-0.90.1.legacy.i386.rpm 7286328e5e852d54054842499991b757a611764a redhat/9/updates-testing/i386/mozilla-js-debugger-1.7.12-0.90.1.legacy.i386.rpm ce0434655656869055dd1c241d8e4ec87b116332 redhat/9/updates-testing/i386/mozilla-mail-1.7.12-0.90.1.legacy.i386.rpm f8b6ac8a06f09586dae8c0b6b5ee1ac477441a9b redhat/9/updates-testing/i386/mozilla-nspr-1.7.12-0.90.1.legacy.i386.rpm 4e3e35121ee0b7af06741ed55b8940dbfff75729 redhat/9/updates-testing/i386/mozilla-nspr-devel-1.7.12-0.90.1.legacy.i386.rpm 084505eb96bf88a56674de30742f65488456b605 redhat/9/updates-testing/i386/mozilla-nss-1.7.12-0.90.1.legacy.i386.rpm cdf65aa899b79b48e0887ef39ca91302e6d15681 redhat/9/updates-testing/i386/mozilla-nss-devel-1.7.12-0.90.1.legacy.i386.rpm 5a2acb7f2793efb7f10255b92612e77a1d9e65bb redhat/9/updates-testing/SRPMS/mozilla-1.7.12-0.90.1.legacy.src.rpm 74020053368e66bfd9efce5ba562c63f69a577d6 redhat/9/updates-testing/i386/galeon-1.2.14-0.90.5.legacy.i386.rpm 2b4d838851a2281850c46ba31431e648a00499a3 redhat/9/updates-testing/SRPMS/galeon-1.2.14-0.90.5.legacy.src.rpm fc1: 18c32412474b8a52d801d2fc4ed81495b68ea951 fedora/1/updates-testing/i386/mozilla-1.7.12-1.1.1.legacy.i386.rpm 07750f8d1e9c3837fb6914501da8dfea7d4020d4 fedora/1/updates-testing/i386/mozilla-chat-1.7.12-1.1.1.legacy.i386.rpm ab9fc23d55b6d15343033e0c8ed9421dc3863722 fedora/1/updates-testing/i386/mozilla-devel-1.7.12-1.1.1.legacy.i386.rpm 6847a3a144b5f35d03fadefcc908c94b865905d3 fedora/1/updates-testing/i386/mozilla-dom-inspector-1.7.12-1.1.1.legacy.i386.rpm 7f1d643d23e0d0f03230b6f5737d00cf2a1668b9 fedora/1/updates-testing/i386/mozilla-js-debugger-1.7.12-1.1.1.legacy.i386.rpm 881f6ca2c2db756f3f5def713824f4d7081e3493 fedora/1/updates-testing/i386/mozilla-mail-1.7.12-1.1.1.legacy.i386.rpm ccf82ba2d865f59f45160ac3f01b5f1bb9b30dde fedora/1/updates-testing/i386/mozilla-nspr-1.7.12-1.1.1.legacy.i386.rpm 5e7d244a529051309619e1c4ff11ecc556e4eae6 fedora/1/updates-testing/i386/mozilla-nspr-devel-1.7.12-1.1.1.legacy.i386.rpm aa8c2bce17d85f5233060849bb49472ddaf5565f fedora/1/updates-testing/i386/mozilla-nss-1.7.12-1.1.1.legacy.i386.rpm ff7b95a361c1d7687e9cffef62e069731652fdb2 fedora/1/updates-testing/i386/mozilla-nss-devel-1.7.12-1.1.1.legacy.i386.rpm 78828bdf69c50385edce0ce157ec0eb6fc08146c fedora/1/updates-testing/SRPMS/mozilla-1.7.12-1.1.1.legacy.src.rpm 06a88b65df00bd254ec70948c5e37e43d6484af4 fedora/1/updates-testing/i386/epiphany-1.0.8-1.fc1.5.legacy.i386.rpm 7562c2a419340f1d5e3fe57073af7a4f1f126306 fedora/1/updates-testing/SRPMS/epiphany-1.0.8-1.fc1.5.legacy.src.rpm fc2: 2b7201d0640279090ba36b881cee56444f12a9b6 fedora/2/updates-testing/i386/mozilla-1.7.12-1.2.1.legacy.i386.rpm 7158928cb2a91dd5acfbbe6d4cd90bdb93060178 fedora/2/updates-testing/i386/mozilla-chat-1.7.12-1.2.1.legacy.i386.rpm c21b66c22ded12a42375d75724673b7a1816543b fedora/2/updates-testing/i386/mozilla-devel-1.7.12-1.2.1.legacy.i386.rpm eddc9d39ddfb6562ad22c793ff9ba945ab4f4f78 fedora/2/updates-testing/i386/mozilla-dom-inspector-1.7.12-1.2.1.legacy.i386.rpm 2f95ea57e64e31484cdb3ae7c74eddbad8aa43b0 fedora/2/updates-testing/i386/mozilla-js-debugger-1.7.12-1.2.1.legacy.i386.rpm 2853941cb5115c58b0f02f61abe883d00186707b fedora/2/updates-testing/i386/mozilla-mail-1.7.12-1.2.1.legacy.i386.rpm 349a2fe95bf5e792a5dc4b981f1af31b7a02b520 fedora/2/updates-testing/i386/mozilla-nspr-1.7.12-1.2.1.legacy.i386.rpm f48748f29967b40255e8a64620612cc39d497340 fedora/2/updates-testing/i386/mozilla-nspr-devel-1.7.12-1.2.1.legacy.i386.rpm c9c6b6437bb73536aab3848e16d12090c376877d fedora/2/updates-testing/i386/mozilla-nss-1.7.12-1.2.1.legacy.i386.rpm 5e20ad8d5d237a7aec66ca6ed6a5b4de806db106 fedora/2/updates-testing/i386/mozilla-nss-devel-1.7.12-1.2.1.legacy.i386.rpm 428bd0ee614bf6e25d473a82d666e5e9c7212f5a fedora/2/updates-testing/SRPMS/mozilla-1.7.12-1.2.1.legacy.src.rpm 04fd8328845ef860a6a61d3a8f001f8ce1aafcac fedora/2/updates-testing/i386/epiphany-1.2.10-0.2.6.legacy.i386.rpm 005dfc66f6dc4288457983397850db041f845e19 fedora/2/updates-testing/SRPMS/epiphany-1.2.10-0.2.6.legacy.src.rpm 24d7a3574244da838fabb07f1ac91071e8015202 fedora/2/updates-testing/i386/devhelp-0.9.1-0.2.9.legacy.i386.rpm 36480970cf8a3639a956192959ba6f766e6b819e fedora/2/updates-testing/i386/devhelp-devel-0.9.1-0.2.9.legacy.i386.rpm c5c049361828b011e956bce2b07e21724b108ddb fedora/2/updates-testing/SRPMS/devhelp-0.9.1-0.2.9.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: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Wed Dec 7 04:16:37 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 06 Dec 2005 23:16:37 -0500 Subject: Fedora Legacy Test Update Notification: ethereal Message-ID: <43966225.1010906@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2005-152922 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152922 2005-12-06 --------------------------------------------------------------------- Name : ethereal Versions : rh7.3: ethereal-0.10.13-0.73.1.legacy Versions : rh9: ethereal-0.10.13-0.90.1.legacy Versions : fc1: ethereal-0.10.13-1.FC1.3.legacy Versions : fc2: ethereal-0.10.13-1.FC2.2.legacy Summary : Network traffic analyzer. Description : Ethereal is a network traffic analyzer for Unix-ish operating systems. --------------------------------------------------------------------- Update Information: Updated Ethereal packages that fix various security vulnerabilities are now available. Ethereal is a program for monitoring network traffic. A number of security flaws have been discovered in Ethereal. On a system where Ethereal is running, a remote attacker could send malicious packets to trigger these flaws and cause Ethereal to crash or potentially execute arbitrary code. The Common Vulnerabilities and Exposures project has assigned the following names to these issues: CAN-2004-1139, CAN-2004-1140, CVE-2004-1141, CVE-2004-1142, CVE-2005-0006, CVE-2005-0007, CVE-2005-0008, CVE-2005-0009, CVE-2005-0010, CVE-2005-0084, CVE-2005-0699, CVE-2005-0704, CVE-2005-0705, CVE-2005-0739, CVE-2005-1456, CVE-2005-1457, CVE-2005-1458, CVE-2005-1459, CVE-2005-1460, CVE-2005-1461, CVE-2005-1462, CVE-2005-1463, CVE-2005-1464, CVE-2005-1465, CVE-2005-1466, CVE-2005-1467, CVE-2005-1468, CVE-2005-1469, CVE-2005-1470, CVE-2005-2360, CVE-2005-2361, CVE-2005-2362, CVE-2005-2363, CVE-2005-2364, CVE-2005-2365, CVE-2005-2366, CVE-2005-2367, CVE-2005-3241, CVE-2005-3242, CVE-2005-3243, CVE-2005-3244, CVE-2005-3245, CVE-2005-3246, CVE-2005-3247, CVE-2005-3248, CVE-2005-3249, and CVE-2005-3184. Users of Ethereal should upgrade to these updated packages which contain version 0.10.13 and are not vulnerable to these issues. --------------------------------------------------------------------- Changelogs rh73: * Tue Nov 22 2005 David Eisenstein 0.10.13-0.73.1.legacy - Updated to 0.10.13 to fix multiple security issues (Bug #152922) - Add lines to specfile to package /usr/sbin/{randpkt,capinfos} and {_mandir}/man1/capinfos.* * Mon Mar 14 2005 Marc Deslauriers 0.10.10-0.73.1.legacy - Updated to 0.10.10 to fix multiple security issues (FL#2453) * Wed Feb 23 2005 Marc Deslauriers 0.10.9-0.73.2.legacy - Added the evil plugins hack to get plugins built * Mon Feb 07 2005 Marc Deslauriers 0.10.9-0.73.1.legacy - Updated to 0.10.9 to fix multiple security issues (FL#2407) - Modified configure parameters - Added gcc patch rh9: * Mon Nov 28 2005 David Eisenstein 0.10.13-0.90.1.legacy - Updated to 0.10.13 to fix multiple security issues (Bug #152922) - Added ethereal-0.10.6-old.patch from RHEL3 0.10.13 .src.rpm. - Package /usr/sbin/randpkt - Add ldconfig commands to post-install and post-uninstall, like RHEL3. * Mon Mar 14 2005 Marc Deslauriers 0.10.10-0.90.1.legacy - Updated to 0.10.10 to fix multiple security issues (FL#2453) * Wed Feb 23 2005 Marc Deslauriers 0.10.9-0.90.2.legacy - Added the evil plugins hack to get plugins built * Tue Feb 08 2005 Marc Deslauriers 0.10.9-0.90.1.legacy - Updated to 0.10.9 to fix multiple security issues (FL#2407) - Modified configure parameters fc1: * Sun Nov 27 2005 David Eisenstein 0.10.13-1.FC1.3.legacy - Oops. The hunk I removed from the ethereal-0.10.6-old.patch had *NOT* been applied upstream. Reinstate it. Sorry 'bout that. * Tue Nov 08 2005 David Eisenstein 0.10.13-1.FC1.2.legacy - Add missing /usr/sbin/randpkt to files section so it will build. * Mon Nov 07 2005 David Eisenstein 0.10.13-1.FC1.1.legacy - Updated to 0.10.13 to fix multiple security issues (Bug #152922) - Removed the no-longer-needed ethereal-0.10.8-htmlview.patch - Added ethereal-0.10.6-old.patch from RHEL3 0.10.13 .src.rpm after remov- ing a hunk from it that already had been applied upstream to packet-smb.c * Mon Mar 14 2005 Marc Deslauriers 0.10.10-1.FC1.1.legacy - Updated to 0.10.10 to fix multiple security issues (FL#2453) * Wed Feb 23 2005 Marc Deslauriers 0.10.9-1.FC1.2.legacy - Added the evil plugins hack to get plugins built * Tue Feb 08 2005 Marc Deslauriers 0.10.9-1.FC1.1.legacy - Updated to 0.10.9 to fix multiple security issues (FL#2407) - Added htmlview patch - Changed BuildRequires to gtk2 fc2: * Mon Nov 28 2005 David Eisenstein 0.10.13-1.FC2.2.legacy - Add autoconf, automake16, libtool BuildRequires. * Mon Nov 28 2005 David Eisenstein 0.10.13-1.FC2.1.legacy - Updated to 0.10.13 to fix multiple security issues (Bug #152922) - Removed the no-longer-needed ethereal-0.10.8-htmlview.patch - Package /usr/sbin/randpkt --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh7.3: b6ec3227ce109dee158226168c100e726bfc20e3 redhat/7.3/updates-testing/i386/ethereal-0.10.13-0.73.1.legacy.i386.rpm 76bf3ca139e814ced155cab659e2845713baeee8 redhat/7.3/updates-testing/i386/ethereal-gnome-0.10.13-0.73.1.legacy.i386.rpm 27d46417d6c70d7696ce51bb0eda1eca4c09306c redhat/7.3/updates-testing/SRPMS/ethereal-0.10.13-0.73.1.legacy.src.rpm rh9: f40d4d125f74b5b2320b5f9c07a4dfe3a38b6070 redhat/9/updates-testing/i386/ethereal-0.10.13-0.90.1.legacy.i386.rpm d2a08d88c8c22d375f36ebcaf480b580244e7b8f redhat/9/updates-testing/i386/ethereal-gnome-0.10.13-0.90.1.legacy.i386.rpm 51e96ba6f6d6448370fd1d7e88bce2be2561f5b8 redhat/9/updates-testing/SRPMS/ethereal-0.10.13-0.90.1.legacy.src.rpm fc1: 1f7a8447e658a08866f8050458c130793684ea72 fedora/1/updates-testing/i386/ethereal-0.10.13-1.FC1.3.legacy.i386.rpm 15198b45cdf68437b14cf37476b4eacb93313547 fedora/1/updates-testing/i386/ethereal-gnome-0.10.13-1.FC1.3.legacy.i386.rpm 7df377ffb3f5267fc65e11adb54882d92135b405 fedora/1/updates-testing/SRPMS/ethereal-0.10.13-1.FC1.3.legacy.src.rpm fc2: f50e59779e38adf3de331c9f1b71f49ddb5dec11 fedora/2/updates-testing/i386/ethereal-0.10.13-1.FC2.2.legacy.i386.rpm 92c6b494330da5f7c6757bec6004d9110786c914 fedora/2/updates-testing/i386/ethereal-gnome-0.10.13-1.FC2.2.legacy.i386.rpm aa43704fe2deb8aa46b3e61e3884470d9911e1fa fedora/2/updates-testing/SRPMS/ethereal-0.10.13-1.FC2.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: OpenPGP digital signature URL: From ashishs at us.ibm.com Wed Dec 7 05:37:30 2005 From: ashishs at us.ibm.com (Ashish N Shah) Date: Tue, 6 Dec 2005 22:37:30 -0700 Subject: Ashish N Shah is out of the office. Message-ID: I will be out of the office starting 12/05/2005 and will not return until 01/02/2006. I am out of the office, in my absence please contact Shanshank Trivedi (shank at us.ibm.com) for any SID/X3 issues. Contact Kuldip Nanda (knanda at us.ibm.com) for Preload issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gene.heskett at verizon.net Thu Dec 8 18:06:37 2005 From: gene.heskett at verizon.net (Gene Heskett) Date: Thu, 08 Dec 2005 13:06:37 -0500 Subject: exporting displays question Message-ID: <200512081306.37882.gene.heskett@verizon.net> Hi all; I'm trying to export the x display on a more or less debian/morphix (the bdi install of emc-4.30 TBE) box in my workshop, current temps in the teens, which I believe uses the XFree86 stuff, to my main box here in a nice warm room, and failing miserably. Here I've done an 'xhost +' which supposely lets everyone in according to the message it returned when I ran it. There I've set the DISPLAY=thisbox:0 and exported it. An ssh -X eventually works but I am still lookng at the local konsole I used to log into the remote box when its done. An attempt to run an xterm while ssh -X'd into that box fails in about 2 minutes, saying it can't open the display 192.168.xx.x:0, which is this box. This box is a rather hacked FC2 and is reasonably uptodate, but its not running XFree86, its running x.org-6.8.1-901 and running it very well since a couple of days after it was announced, what, a year ago? So whats the next thing to do to make this work? Any and all clues cheerfully accepted at this point. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.36% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. From neils at ariel.met.tamu.edu Thu Dec 8 21:52:27 2005 From: neils at ariel.met.tamu.edu (Neil R. Smith) Date: Thu, 08 Dec 2005 15:52:27 -0600 Subject: cannot set user id Message-ID: <1134078747.4429.194.camel@penny.met.tamu.edu> FC2, 2.6.10-1.771 NIS client with nsswitch.conf passwd entry 'compat nis' /etc/passwd user entries of form '+username' Problem: Recently a user of our FC2 system found he wasn't able to ssh login anymore. No other users (total <20) are experiencing this problem. The ssh login fails with 'Connection to xxxxxxx closed by remote host.' When root user su's to this account, say with 'su - username', error is 'su: cannot set user id: Resource temporarily unavailable' /var/log/messages records consecutive 'session opened' and 'session closed' for the user, with same time stamp. /var/log/secure records that sshd accepted the password for that user. 'ypwhich' reports correct NIS master. To my knowledge there have been no system config changes across the working/notworking time interval. Again, this user used to be able to login. All others except this user can still login. Any suggestions? -Neil -- Neil R. Smith, Comp. Sys. Mngr. neils at tamu.edu Dept. Atmospheric Sci., Texas A&M Univ. 979/845-6272 FAX:979/862-4466 From jpdalbec at ysu.edu Fri Dec 9 22:17:19 2005 From: jpdalbec at ysu.edu (John Dalbec) Date: Fri, 09 Dec 2005 17:17:19 -0500 Subject: Perl Format String Vulnerability Message-ID: <439A026F.7080005@ysu.edu> Does this affect us? (1) HIGH: Perl Format String Vulnerability Affected: Perl versions 5.9.2 and 5.8.6 confirmed; potentially all Perl versions Webmin version 1.23 and prior Description: Perl is widely used as a scripting language for a variety of applications including web-based software. Perl contains a vulnerability that can be triggered by passing a format specifier of the form "%INT_MAXn". The vulnerability causes an integer variable in a Perl function to wrap around (change its parity) that can be exploited to execute arbitrary code. For instance, "%2147483647n" format specifier will trigger the flaw in Perl running on 32-bit Operating Systems. Note that the flaw can be exploited only via Perl-based applications that contain a format string vulnerability. The discoverers have reportedly found several applications that are vulnerable. One of the affected applications is Webmin, a web interface to perform administrative tasks like server and user configuration. Webmin's web server miniserv.pl, which runs on port 10000/tcp by default, contains a format string vulnerability. By passing a username containing a format specifier, an attacker can exploit the flaw to execute arbitrary code with possibly root privileges. Immunity, Inc. has made an exploit available to some of its customers. Status: Some Linux vendors have released patches. The discoverers have also released an unofficial patch for version 5.9.2 that is available at: http://www.dyadsecurity.com/advisory/perl/perl-5.9.2-exp_parameter_intwrap_vulnerability. A workaround for the Webmin flaw is to block the traffic to port 10000/tcp at the network perimeter. Council Site Actions: Most of the council sites are responding to this item on some level and plan to install patches as they are made available. Several sites have notified their web developers. One site requested updates from the 3rd party providers that bundle Perl with applications in use at their site. Another site said that they have several Mandriva Linux systems running Webmin and plan to recommend that the affected system administrators apply the MDKSA-2005:223 update. These systems are used by a few dozen users. The remaining council sites commented they do not use Perl on and of their web servers. References: DyadSecurity Advisory http://www.dyadsecurity.com/perl-0002.html http://www.dyadsecurity.com/webmin-0001.html Posting by giarc http://archives.neohapsis.com/archives/fulldisclosure/2005-12/0001.html Posting by Dave Aitel http://archives.neohapsis.com/archives/fulldisclosure/2005-12/0015.html Webmin miniserv.pl Documentation http://www.dyadsecurity.com/webmin-0001.html Webmin Homepage http://www.webmin.com SecurityFocus BID http://www.securityfocus.com/bid/15629 From deisenst at gtw.net Fri Dec 9 22:42:00 2005 From: deisenst at gtw.net (David Eisenstein) Date: Fri, 9 Dec 2005 16:42:00 -0600 (CST) Subject: exporting displays question In-Reply-To: <200512081306.37882.gene.heskett@verizon.net> Message-ID: On Thu, 8 Dec 2005, Gene Heskett wrote: > Hi all; > > I'm trying to export the x display on a more or less debian/morphix (the bdi > install of emc-4.30 TBE) box in my workshop, current temps in the teens, > which I believe uses the XFree86 stuff, to my main box here in a nice warm > room, and failing miserably. > > Here I've done an 'xhost +' which supposely lets everyone in according to the > message it returned when I ran it. It should, but there may be more to do. > There I've set the DISPLAY=thisbox:0 and exported it. > > An ssh -X eventually works but I am still lookng at the local konsole I used > to log into the remote box when its done. > > An attempt to run an xterm while ssh -X'd into that box fails in about 2 > minutes, saying it can't open the display 192.168.xx.x:0, which is this box. So it's in the ssh terminal session running on thatbox that you've exported DISPLAY=thisbox:0, right? > This box is a rather hacked FC2 and is reasonably uptodate, but its not > running XFree86, its running x.org-6.8.1-901 and running it very well > since a couple of days after it was announced, what, a year ago? > > So whats the next thing to do to make this work? Any and all clues > cheerfully accepted at this point. There are two methods of going about this. One way is to allow the ssh program to forward X connections. Typically it does so by the sshd daemon on the remote box that opens the terminal connection there already setting you up with a DISPLAY exported variable (typically, with DISPLAY=localhost:10.0), so you don't have to set one up yourself. (Your ssh -X should create the TCP/IP and socket plumbing to do this automagically, so you shouldn't define a DISPLAY environment variable there to use this method.) The X connection is then forwarded through the ssh session to your thisbox X server when you start a client program on that box, like say, xclock or xterm. This way of doing it, however, incurs the overhead of having all the data over the wire be encrypted by the client (thatbox) machine to be decrypted by your X server (thisbox) machine and vice-versa, since all the X traffic runs through the ssh connection. This is a great method to use if you're using an untrusted network. -------------(thatbox localhost)--------------------(thatbox) ------encrypted data------ ------------------------(thisbox)------------------- xclock -> [DISPLAY :10.0 (TCP port 6010)] -> sshd -> [SSH port 22] -> [ethernet TCP/IP] -> [SSH client port] -> ssh -> [unix domain socket] -> X server ___________________________________ The second method, using the DISPLAY=thisbox:0, is a bit more complicated but is more efficient since there's no encryption over the wire. (Disclaimer: Bear in mind the below advice is what I'd do in FC1; things may or may not be the same in FC2.) First thing is to make sure that your X server is not running with the "-nolisten tcp" option. If X is running with that option, then it will accept client connections only over UNIX domain sockets, not over TCP/IP. (You can tell by doing a $ ps ax and looking at the command arguments for X on thisbox). If you're booting up in X on your comfy computer, running Gnome and the Gnome Display Manager (gdm), my understanding is that you can change a setting in its configuration file that will start the X server without the "-nolisten tcp" option (I haven't tried this myself): Config file- /etc/X11/gdm/gdm.conf Change line: #DisallowTCP=true to: DisallowTCP=false (I don't boot up in X; I start the X server with my own startx command, thereby controlling the X startup options myself.) Second thing is to make sure you don't have TCP port 6000 (the port for X display :0) blocked by an iptables firewall running on your FC2 thisbox. If necessary, you can edit /etc/sysconfig/iptables to add a line like this: -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp -s 192.168.yy.y --dport 6000 -j ACCEPT where '192.168.yy.y' is the IP address of your ice-cold workshop computer (thatbox). Then restart the firewall. (Bear in mind that when you manually edit the iptables config file, you risk losing that manual configuration if you run Red Hat's (or Fedora's) {redhat,system}-config-securitylevel program unless you back up your manual changes somewhere and put them back after running that program.) Hope this helped. -David From gene.heskett at verizon.net Fri Dec 9 23:17:35 2005 From: gene.heskett at verizon.net (Gene Heskett) Date: Fri, 09 Dec 2005 18:17:35 -0500 Subject: exporting displays question In-Reply-To: References: Message-ID: <200512091817.35886.gene.heskett@verizon.net> On Friday 09 December 2005 17:42, David Eisenstein wrote: >On Thu, 8 Dec 2005, Gene Heskett wrote: >> Hi all; >> >> I'm trying to export the x display on a more or less debian/morphix >> (the bdi install of emc-4.30 TBE) box in my workshop, current temps >> in the teens, which I believe uses the XFree86 stuff, to my main >> box here in a nice warm room, and failing miserably. >> >> Here I've done an 'xhost +' which supposely lets everyone in >> according to the message it returned when I ran it. > >It should, but there may be more to do. > >> There I've set the DISPLAY=thisbox:0 and exported it. >> >> An ssh -X eventually works but I am still lookng at the local >> konsole I used to log into the remote box when its done. >> >> An attempt to run an xterm while ssh -X'd into that box fails in >> about 2 minutes, saying it can't open the display 192.168.xx.x:0, >> which is this box. > >So it's in the ssh terminal session running on thatbox that you've >exported DISPLAY=thisbox:0, right? Yes, at least till the hd upchucked all over itself yesterday. >> This box is a rather hacked FC2 and is reasonably uptodate, but its >> not running XFree86, its running x.org-6.8.1-901 and running it >> very well since a couple of days after it was announced, what, a >> year ago? >> >> So whats the next thing to do to make this work? Any and all clues >> cheerfully accepted at this point. > >There are two methods of going about this. One way is to allow the > ssh program to forward X connections. Typically it does so by the > sshd daemon on the remote box that opens the terminal connection > there already setting you up with a DISPLAY exported variable > (typically, with DISPLAY=localhost:10.0), so you don't have to set > one up yourself. (Your ssh -X should create the TCP/IP and socket > plumbing to do this automagically, so you shouldn't define a DISPLAY > environment variable there to use this method.) The X connection is > then forwarded through the ssh session to your thisbox X server when > you start a client program on that box, like say, xclock or xterm. > >This way of doing it, however, incurs the overhead of having all the >data over the wire be encrypted by the client (thatbox) machine to be >decrypted by your X server (thisbox) machine and vice-versa, since > all the X traffic runs through the ssh connection. This is a great > method to use if you're using an untrusted network. This is all trusted, no internal firewalls of any kind on the coyote.den domain. > > -------------(thatbox localhost)--------------------(thatbox) > ------encrypted data------ > ------------------------(thisbox)------------------- xclock -> > [DISPLAY :10.0 (TCP port 6010)] -> sshd -> [SSH port 22] -> > [ethernet TCP/IP] -> [SSH client port] -> ssh -> [unix domain > socket] -> X server > > >___________________________________ > >The second method, using the DISPLAY=thisbox:0, is a bit more > complicated but is more efficient since there's no encryption over > the wire. > >(Disclaimer: Bear in mind the below advice is what I'd do in FC1; > things may or may not be the same in FC2.) > >First thing is to make sure that your X server is not running with > the "-nolisten tcp" option. If X is running with that option, then > it will accept client connections only over UNIX domain sockets, not > over TCP/IP. (You can tell by doing a $ ps ax and looking at the > command arguments for X on thisbox). > >If you're booting up in X on your comfy computer, running Gnome and > the Gnome Display Manager (gdm), my understanding is that you can > change a setting in its configuration file that will start the X > server without the "-nolisten tcp" option (I haven't tried this > myself): I don't believe such an option is set here. Would that show in the xorg.0.log? > Config file- /etc/X11/gdm/gdm.conf > > Change line: > #DisallowTCP=true > to: > DisallowTCP=false I'll try this, and I just set the RemoteLoginAllowed=true also. Or is that not needed. >(I don't boot up in X; I start the X server with my own startx > command, thereby controlling the X startup options myself.) Ditto. >Second thing is to make sure you don't have TCP port 6000 (the port > for X display :0) blocked by an iptables firewall running on your > FC2 thisbox. If necessary, you can edit /etc/sysconfig/iptables to > add a line like this: Nope, no iptables running on either box, just an 8 port 100baseT switch between them, and about 100 feet of cat5. >-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp -s > 192.168.yy.y --dport 6000 -j ACCEPT > >where '192.168.yy.y' is the IP address of your ice-cold workshop > computer (thatbox). Then restart the firewall. (Bear in mind that > when you manually edit the iptables config file, you risk losing > that manual configuration if you run Red Hat's (or Fedora's) > {redhat,system}-config-securitylevel program unless you back up your > manual changes somewhere and put them back after running that > program.) > >Hope this helped. -David I'll find out after I've resuscitated that box, the hd's got funkity in the cold and trashed themselves yesterday. So I've got to start with a fresh install after I lug it all into the comfort zone here. I'll do that after I locate some thermo controlled fans so it will keep warm if I leave it on, but not overheat in the summertime. -- Cheers, Gene People having trouble with vz bouncing email to me should use this address: which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. From peak at argo.troja.mff.cuni.cz Sun Dec 11 10:36:04 2005 From: peak at argo.troja.mff.cuni.cz (Pavel Kankovsky) Date: Sun, 11 Dec 2005 11:36:04 +0100 (CET) Subject: Perl Format String Vulnerability In-Reply-To: <439A026F.7080005@ysu.edu> Message-ID: <20051211103604.5523.qmail@paddy.troja.mff.cuni.cz> On Fri, 9 Dec 2005, John Dalbec wrote: > Does this affect us? > > (1) HIGH: Perl Format String Vulnerability > Affected: > Perl versions 5.9.2 and 5.8.6 confirmed; potentially all Perl versions > Webmin version 1.23 and prior Perl 5.6.1 in RH 7.3 appears not to be affected (%N$ is not supported). Newer versions are probably affected. --Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ] "Resistance is futile. Open your source code and prepare for assimilation." From gene.heskett at verizon.net Mon Dec 12 02:20:30 2005 From: gene.heskett at verizon.net (Gene Heskett) Date: Sun, 11 Dec 2005 21:20:30 -0500 Subject: ssh question Message-ID: <200512112120.30833.gene.heskett@verizon.net> How can I make the ssh thats installed on my FC2 system, be compatible with the ssh thats installed on a specialty release (BDI-4.30) thats debian/morphix based running a 2.6.12-rtai kernel? The version numbers are totally different, as if the two copies of OpenSSH branched in 1994 or something. One accepts the ssh -Y syntax, the other rejects it, one accepts the ssh -X syntax while the other rejects it, hence the X services cannot be exported one to the other in either direction. Its a secure local network with a tight firewall between all these machines here, and the router to the internet. My logs are clean of any attempts to access from the outside and have been that way for over a year now. What would be the recommended fix for this? -- Cheers, Gene People having trouble with vz bouncing email to me should use this address: which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. From hjp+fedora-legacy at wsr.ac.at Mon Dec 12 09:23:19 2005 From: hjp+fedora-legacy at wsr.ac.at (Peter J. Holzer) Date: Mon, 12 Dec 2005 10:23:19 +0100 Subject: ssh question In-Reply-To: <200512112120.30833.gene.heskett@verizon.net> References: <200512112120.30833.gene.heskett@verizon.net> Message-ID: <20051212092319.GA12073@wsr.ac.at> On 2005-12-11 21:20:30 -0500, Gene Heskett wrote: > How can I make the ssh thats installed on my FC2 system, be compatible > with the ssh thats installed on a specialty release (BDI-4.30) thats > debian/morphix based running a 2.6.12-rtai kernel? FC 2 includes OpenSSH_3.6.1p2, SSH protocols 1.5/2.0, OpenSSL 0x0090701f Debian Sarge includes OpenSSH_3.8.1p1 Debian-8.sarge.4, OpenSSL 0.9.7e 25 Oct 2004 Debian also includes at least one other SSH implementation. I played with it briefly, but encountered some problems (don't remember what they were) and due to lack of time returned to OpenSSH. > The version numbers are totally different, If the version numbers are really totally different, the other SSH probably isn't OpenSSH. As you can see above, OpenSSH on Sarge is a bit newer, but not much. > as if the two copies of OpenSSH branched in 1994 or something. I'm not sure if SSH existed in 1994 (I certainly learned about it a few years later). OpenSSH as the first major branch is certainly not that old. There are other branches, and at least two complete reimplementations. > One accepts the ssh -Y syntax, the other rejects it, one accepts the > ssh -X syntax while the other rejects it, hence the X services cannot > be exported one to the other in either direction. I think is is more likely that you have disallowed X forwarding on the SSH server(s). I certainly can connect with both ssh -X and ssh -Y from a debian box to a FC2 box (even though FC2 openssh is too old to recognize -Y) and connect with ssh -X from FC2 to debian. > What would be the recommended fix for this? Check the documentation and configuration of the ssh servers. Use the option -vv to get (lots of) debug output. hp -- _ | Peter J. Holzer | If I wanted to be "academically correct", |_|_) | Sysadmin WSR | I'd be programming in Java. | | | hjp at wsr.ac.at | I don't, and I'm not. __/ | http://www.hjp.at/ | -- Jesse Erlbaum on dbi-users -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 388 bytes Desc: not available URL: From jpdalbec at ysu.edu Thu Dec 15 21:43:24 2005 From: jpdalbec at ysu.edu (John Dalbec) Date: Thu, 15 Dec 2005 16:43:24 -0500 Subject: [Mach-devel] mach 0.4.8 fc1 on fc4 problem In-Reply-To: <20051210043348.92AB588BF3@sc8-sf-spam1.sourceforge.net> References: <20051210043348.92AB588BF3@sc8-sf-spam1.sourceforge.net> Message-ID: <43A1E37C.2080604@ysu.edu> I'm trying to set up a Fedora Core 1 build root in mach on Fedora Core 3. The setup fails because ld-linux.so.2 -> ld-2.3.2.so segfaults in dl_main(). See below for details. Any thoughts on how I can further diagnose the problem? Thanks, John Dalbec > Date: Thu, 08 Dec 2005 16:59:50 -0500 > From: John Dalbec > To: mach-devel at lists.sourceforge.net > Subject: Re: [Mach-devel] mach 0.4.8 fc1 on fc4 problem > > Who Knows wrote: > >>John Dalbec wrote: >> >> >> >>>This looks like the problem I had with fc2-on-fc3 with 0.4.7 where I >>>needed to: create a mach-libselinux package containing >>>/usr/lib/libselinux-mach.so >>>create a local repository containing it >>>add the local repository to /etc/mach/locations and /etc/mach/dist.d/... >>>add mach-libselinux to the "minimal" package list in /etc/mach/dist.d/... >>>John >> >> >>The new version 0.4.8 now correctly copies the libselinux files which >>should eliminate the need for the special package. >>and i did verify they were copied for the fc1 root. >> >>thanks >> >>Jim > > > OK, I'm getting the same problem in FC1-on-FC3. It looks like > glibc_post_upgrade fails when iconvconfig segfaults. Actually it looks like any > chrooted command segfaults at that point. Strace shows that the segfault occurs > almost immediately after trying to open /etc/ld.so.preload. I can't get a > backtrace from gdb. I wonder if the chroot command itself is segfaulting? I > don't see a fork() in the strace output. > John I've strace()'d "true" in a working FC1 buildroot (on RHL 9) and the next strace'd command opens /etc/ld.so.cache. Maybe it's corrupted? No, removing it doesn't help. FC3 # /var/lib/mach/roots/fedora-1-i386-legacy/lib/libc.so.6 /var/lib/mach/roots/fedora-1-i386-legacy/lib/libc.so.6: relocation error: /var/lib/mach/roots/fedora-1-i386-legacy/lib/libc.so.6: symbol _dl_starting_up, version GLIBC_PRIVATE not defined in file ld-linux.so.2 with link time reference FC3 # strace /var/lib/mach/roots/fedora-1-i386-legacy/lib/ld-linux.so.2 /var/lib/mach/roots/fedora-1-i386-legacy/lib/libc.so.6 execve("/var/lib/mach/roots/fedora-1-i386-legacy/lib/ld-linux.so.2", ["/var/lib/mach/roots/fedora-1-i386-legacy/lib/ld-linux.so.2", "/var/lib/mach/roots/fedora-1-i386-legacy/lib/libc.so.6"], [/* 24 vars */]) = 0 uname({sys="Linux", node="dalbec134-fc3.meshel.ysu.edu.localdomain", ...}) = 0 brk(0) = 0x946b000 open("/var/lib/mach/roots/fedora-1-i386-legacy/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\\\1"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1570564, ...}) = 0 old_mmap(NULL, 1296772, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x957000 old_mmap(0xa8e000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x136000) = 0xa8e000 old_mmap(0xa91000, 10628, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xa91000 close(3) = 0 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f95000 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ FC3 # gdb /var/lib/mach/roots/fedora-1-i386-legacy/lib/ld-linux.so.2 GNU gdb Red Hat Linux (6.1post-1.20040607.43.0.1rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...(no debugging symbols found)...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) run /var/lib/mach/roots/fedora-1-i386-legacy/lib/libc.so.6 Starting program: /var/lib/mach/roots/fedora-1-i386-legacy/lib/ld-linux.so.2 /var/lib/mach/roots/fedora-1-i386-legacy/lib/libc.so.6 Reading symbols from shared object read from target memory...(no debugging symbols found)...done. Loaded system supplied DSO at 0xd61000 Program received signal SIGSEGV, Segmentation fault. 0x00372600 in dl_main () (gdb) bt #0 0x00372600 in dl_main () #1 0x0038070a in _dl_sysdep_start () #2 0x00371f80 in _dl_start () #3 0x00371c57 in _start () 0x0037253d : test %edi,%edi 0x0037253f : je 0x3738be 0x00372545 : mov 0xffffff48(%ebp),%eax 0x0037254b : test %eax,%eax 0x0037254d : jne 0x373878 0x00372553 : mov 0xffffff4c(%ebx),%eax 0x00372559 : test %eax,%eax 0x0037255b : je 0x3728bb 0x00372561 : mov 0x18(%eax),%edi 0x00372564 : lea 0xffffd96a(%ebx),%edx 0x0037256a : mov $0x1,%ecx 0x0037256f : movl $0x0,(%esp) 0x00372576 : mov %edx,%eax 0x00372578 : mov %edi,0xffffff48(%ebx) 0x0037257e : call 0x37a8f0 <_dl_new_object> 0x00372583 : mov %eax,0xffffff00(%ebp) 0x00372589 : sub $0x4,%esp 0x0037258c : test %eax,%eax 0x0037258e : je 0x3728bb 0x00372594 : mov 0xffffff4c(%ebx),%edi 0x0037259a : mov 0xffffff00(%ebp),%esi 0x003725a0 : mov 0x1c(%edi),%eax 0x003725a3 : mov %edi,%edx 0x003725a5 : add %eax,%edx 0x003725a7 : movzwl 0x2c(%edi),%eax 0x003725ab : mov %edx,0x144(%esi) 0x003725b1 : mov %ax,0x14c(%esi) 0x003725b8 : xor %esi,%esi 0x003725ba : cmp %eax,%esi 0x003725bc : jae 0x3725e3 0x003725be : mov %eax,0xfffffefc(%ebp) 0x003725c4 : mov %edx,%edi 0x003725c6 : mov %esi,%eax 0x003725c8 : shl $0x5,%eax 0x003725cb : lea (%eax,%edi,1),%ecx 0x003725ce : cmpl $0x2,(%edx) 0x003725d1 : je 0x37385a 0x003725d7 : inc %esi 0x003725d8 : add $0x20,%edx 0x003725db : cmp 0xfffffefc(%ebp),%esi ---Type to continue, or q to quit--- 0x003725e1 : jb 0x3725c6 0x003725e3 : mov 0xffffff00(%ebp),%eax 0x003725e9 : lea 0x58(%ebx),%edx 0x003725ef : mov %edx,0xfffffef8(%ebp) 0x003725f5 : mov 0x8(%eax),%esi 0x003725f8 : test %esi,%esi 0x003725fa : je 0x37288c 0x00372600 : mov (%esi),%edx eax 0xb7f7a000 -1208508416 ecx 0xd61054 14028884 edx 0x386560 3695968 ebx 0x386508 3695880 esp 0xbfa77cd0 0xbfa77cd0 ebp 0xbfa77e9c 0xbfa77e9c esi 0x578 1400 edi 0xb7f7a000 -1208508416 eip 0x372600 0x372600 eflags 0x10206 66054 cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x0 0 elf/rtld.c: ... struct link_map *l = _dl_new_object ((char *) "", "", lt_library, NULL); if (__builtin_expect (l != NULL, 1)) { static ElfW(Dyn) dyn_temp[DL_RO_DYN_TEMP_CNT]; l->l_phdr = ((const void *) GL(dl_sysinfo_dso) + GL(dl_sysinfo_dso)->e_phoff); l->l_phnum = GL(dl_sysinfo_dso)->e_phnum; for (uint_fast16_t i = 0; i < l->l_phnum; ++i) { const ElfW(Phdr) *const ph = &l->l_phdr[i]; if (ph->p_type == PT_DYNAMIC) { l->l_ld = (void *) ph->p_vaddr; l->l_ldnum = ph->p_memsz / sizeof (ElfW(Dyn)); break; } if (ph->p_type == PT_LOAD) assert ((void *) ph->p_vaddr == GL(dl_sysinfo_dso)); } elf_get_dynamic_info (l, dyn_temp); ... elf/dynamic-link.h: ... static inline void __attribute__ ((unused, always_inline)) elf_get_dynamic_info (struct link_map *l, ElfW(Dyn) *temp) { ElfW(Dyn) *dyn = l->l_ld; ElfW(Dyn) **info; #ifndef RTLD_BOOTSTRAP if (dyn == NULL) return; #endif info = l->l_info; while (dyn->d_tag != DT_NULL) { if (dyn->d_tag < DT_NUM) info[dyn->d_tag] = dyn; ... I'm guessing the above is the location of the segfault? I tried installing the i386 C library but it still segfaults. John > > > > --__--__-- > > _______________________________________________ > Mach-devel mailing list > Mach-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mach-devel > > > End of Mach-devel Digest > From deisenst at gtw.net Fri Dec 16 02:30:26 2005 From: deisenst at gtw.net (David Eisenstein) Date: Thu, 15 Dec 2005 20:30:26 -0600 (CST) Subject: 8 more days 'til we inherit FC3; are we ready??; FWD: Fedora Core 3 Status Update Message-ID: Hi, In just a little over a week, we are scheduled to inherit Fedora Core 3. I suppose at the same time, we will be dropping Fedora Core 1 (though I wish we weren't -- we seem to have a lot more postings of parties interested in FC1 than we have interested in FC2, and we get more votes and QA testing on FC1 than FC2 in bugzilla). Are we ready? What do we need to prepare for maintaining FC3? -David ---------- Forwarded message ---------- From: Bill Nottingham Reply-To: fedora-list at redhat.com To: fedora-announce-list at redhat.com Date: Mon, 28 Nov 2005 21:58:59 -0500 Subject: Fedora Core 3 Status Update As is customary, the Fedora Steering Committe plans to transfer Fedora Core 3 to the Fedora Legacy project at the release of Fedora Core 5 test 2. This is currently scheduled for December 23, 2005, as noted on: http://fedora.redhat.com/participate/schedule/ For more information on the Fedora Legacy Project, or if you wish to join the team please see http://fedoralegacy.org/. From jkeating at j2solutions.net Fri Dec 16 02:41:33 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 15 Dec 2005 18:41:33 -0800 Subject: 8 more days 'til we inherit FC3; are we ready??; FWD: Fedora Core 3 Status Update In-Reply-To: References: Message-ID: <1134700893.3005.131.camel@yoda.loki.me> On Thu, 2005-12-15 at 20:30 -0600, David Eisenstein wrote: > Hi, > > In just a little over a week, we are scheduled to inherit Fedora Core 3. > I suppose at the same time, we will be dropping Fedora Core 1 (though I > wish we weren't -- we seem to have a lot more postings of parties > interested in FC1 than we have interested in FC2, and we get more votes > and QA testing on FC1 than FC2 in bugzilla). > > Are we ready? What do we need to prepare for maintaining FC3? A few last minute syncups and maybe touching a config file or two and we'll be ready. At this time I am not prepared to drop FC1. We have a significant user base that is still supporting us in our FC1 tasks and I will not abandon them. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From jimpop at yahoo.com Fri Dec 16 03:49:12 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Thu, 15 Dec 2005 19:49:12 -0800 (PST) Subject: 8 more days 'til we inherit FC3; are we ready??; FWD: Fedora Core 3 Status Update In-Reply-To: <1134700893.3005.131.camel@yoda.loki.me> Message-ID: <20051216034912.88457.qmail@web30401.mail.mud.yahoo.com> I agree with Jesse and David. It makes no sense to drop FC1 if there is still user interest (a'la RH73). A lot of people jumped to FC1 when Redhat changed their business practice (which turned out to be a very good move for them despite mine and other objections), so I think it is in FL's interest to support them. -Jim P. ----- Original Message ---- From: Jesse Keating To: Discussion of the Fedora Legacy Project Cc: notting at redhat.com Sent: Thursday, December 15, 2005 9:41:33 PM Subject: Re: 8 more days 'til we inherit FC3; are we ready??; FWD: Fedora Core 3 Status Update On Thu, 2005-12-15 at 20:30 -0600, David Eisenstein wrote: > Hi, > > In just a little over a week, we are scheduled to inherit Fedora Core 3. > I suppose at the same time, we will be dropping Fedora Core 1 (though I > wish we weren't -- we seem to have a lot more postings of parties > interested in FC1 than we have interested in FC2, and we get more votes > and QA testing on FC1 than FC2 in bugzilla). > > Are we ready? What do we need to prepare for maintaining FC3? A few last minute syncups and maybe touching a config file or two and we'll be ready. At this time I am not prepared to drop FC1. We have a significant user base that is still supporting us in our FC1 tasks and I will not abandon them. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -- fedora-legacy-list mailing list fedora-legacy-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list From deisenst at gtw.net Fri Dec 16 04:29:20 2005 From: deisenst at gtw.net (David Eisenstein) Date: Thu, 15 Dec 2005 22:29:20 -0600 (CST) Subject: [Mach-devel] mach 0.4.8 fc1 on fc4 problem In-Reply-To: <43A1E37C.2080604@ysu.edu> Message-ID: On Thu, 15 Dec 2005, John Dalbec wrote: > I'm trying to set up a Fedora Core 1 build root in mach on Fedora Core > 3. The setup fails because ld-linux.so.2 -> ld-2.3.2.so segfaults in > dl_main(). See below for details. Any thoughts on how I can further > diagnose the problem? > Thanks, > John Dalbec > <> Hi John, Have you done this, from the mach README? "If you're on Fedora Core 2, and want to build for older targets, MAKE SURE you turn off vdso's by doing sysctl -w kernel.vdso=0 before using mach. You can add an entry to /etc/sysctl.conf to make this more permanent." I assume that will also be needed if you're running mach from FC3 or FC4 and trying to build for older targets. Also, do you have SELinux stuff turned on or off in your FC3 host? Dag Wieers indicates that there can be a number of compatibility problems that occur among versions of Red Hat and Fedora Core, and talks of a number of things one can try when using older software on newer kernels in his page, "Red Hat and Fedora Core Compatibility Tweaks." It says there, "How do I know it breaks because of [new and improved technologies integrated into their kernel]? "In most of the cases you won't. The resulting behaviour could be a segmentation fault on start-up, random crashes or even unexpected behaviours and spurious messages. ..." You may want to give some of Dag's tweaks a try if the vdso tweak doesn't help you: . -David From mic at npgx.com.au Fri Dec 16 06:15:27 2005 From: mic at npgx.com.au (Michael Mansour) Date: Fri, 16 Dec 2005 16:15:27 +1000 Subject: 8 more days 'til we inherit FC3; are we ready??; FWD: Fedora Core 3 Status Update In-Reply-To: <20051216034912.88457.qmail@web30401.mail.mud.yahoo.com> References: <1134700893.3005.131.camel@yoda.loki.me> <20051216034912.88457.qmail@web30401.mail.mud.yahoo.com> Message-ID: <20051216061339.M5291@npgx.com.au> Hi, > I agree with Jesse and David. It makes no sense to drop FC1 if > there is still user interest (a'la RH73). A lot of people jumped to > FC1 when Redhat changed their business practice (which turned out to > be a very good move for them despite mine and other objections), so > I think it is in FL's interest to support them. > > -Jim P. > > ----- Original Message ---- > From: Jesse Keating > To: Discussion of the Fedora Legacy Project > Cc: notting at redhat.com > Sent: Thursday, December 15, 2005 9:41:33 PM > Subject: Re: 8 more days 'til we inherit FC3; are we ready??; FWD: > Fedora Core 3 Status Update > > On Thu, 2005-12-15 at 20:30 -0600, David Eisenstein wrote: > > Hi, > > > > In just a little over a week, we are scheduled to inherit Fedora Core 3. > > I suppose at the same time, we will be dropping Fedora Core 1 (though I > > wish we weren't -- we seem to have a lot more postings of parties > > interested in FC1 than we have interested in FC2, and we get more votes > > and QA testing on FC1 than FC2 in bugzilla). > > > > Are we ready? What do we need to prepare for maintaining FC3? > > A few last minute syncups and maybe touching a config file or two and > we'll be ready. > > At this time I am not prepared to drop FC1. We have a significant user > base that is still supporting us in our FC1 tasks and I will not abandon > them. > > -- > Jesse Keating RHCE (geek.j2solutions.net) > Fedora Legacy Team (www.fedoralegacy.org) > GPG Public Key > (geek.j2solutions.net/jkeating.j2solutions.pub) > > Was I helpful? Let others know: > http://svcs.affero.net/rm.php?r=jkeating Just to add my 2 cents, I still use FC1, FC2 and FC3 on various servers and would still like to see FL support for them. Michael. From pekkas at netcore.fi Fri Dec 16 06:48:17 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 16 Dec 2005 08:48:17 +0200 (EET) Subject: 8 more days 'til we inherit FC3; are we ready??; FWD: Fedora Core 3 Status Update In-Reply-To: <20051216061339.M5291@npgx.com.au> References: <1134700893.3005.131.camel@yoda.loki.me> <20051216034912.88457.qmail@web30401.mail.mud.yahoo.com> <20051216061339.M5291@npgx.com.au> Message-ID: On Fri, 16 Dec 2005, Michael Mansour wrote: > Just to add my 2 cents, I still use FC1, FC2 and FC3 on various servers and > would still like to see FL support for them. Whether or not there is "user base" for FC1 is irrelevant. The key point is, are FC1 users willing to participate in pushing out packages (package proposal, verify QA, publish QA, etc.) ? The question is: If dropping FC1 wouldn't reduce the number of QA folks and the work they do [for other distros], we should drop 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 jedgecombe at carolina.rr.com Fri Dec 16 13:42:49 2005 From: jedgecombe at carolina.rr.com (Jason Edgecombe) Date: Fri, 16 Dec 2005 08:42:49 -0500 Subject: What do users need to do to prepare? Message-ID: <43A2C459.8070305@carolina.rr.com> Hi there, as an admin of a few FC3 boxes, what do I need to do to prepare for the transition? change yum.conf? add gpg keys? Can I set it up now or do I need to wait? I'd like to set it up now. Did the transition have to be the week of christmas, when many people are on vacation? Sincerely, Jason From pekkas at netcore.fi Fri Dec 16 13:49:59 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 16 Dec 2005 15:49:59 +0200 (EET) Subject: What do users need to do to prepare? In-Reply-To: <43A2C459.8070305@carolina.rr.com> References: <43A2C459.8070305@carolina.rr.com> Message-ID: On Fri, 16 Dec 2005, Jason Edgecombe wrote: > Did the transition have to be the week of christmas, when many people are on > vacation? Don't worry, unfortunately I doubt there will be any updates coming out in months so you don't need to sweat it ;-(. [1] [1] http://www.netcore.fi/pekkas/buglist.html I hope someone is working on the "needsrelease" and "needsbuild" piles above.. -- 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 16 16:42:32 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 16 Dec 2005 10:42:32 -0600 Subject: What do users need to do to prepare? In-Reply-To: <43A2C459.8070305@carolina.rr.com> References: <43A2C459.8070305@carolina.rr.com> Message-ID: <1134751352.fd42e9b63258c@mail.ph.utexas.edu> Quoting Jason Edgecombe : > Did the transition have to be the week of christmas, when many people > are on vacation? > > Sincerely, > Jason The transition date is set by the Fedora Core group, not by the Fedora Legacy group. And they tend to miss their deadlines often... -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! From mike.mccarty at sbcglobal.net Fri Dec 16 17:20:46 2005 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Fri, 16 Dec 2005 11:20:46 -0600 Subject: 8 more days 'til we inherit FC3; are we ready??; FWD: Fedora Core 3 Status Update In-Reply-To: References: <1134700893.3005.131.camel@yoda.loki.me> <20051216034912.88457.qmail@web30401.mail.mud.yahoo.com> <20051216061339.M5291@npgx.com.au> Message-ID: <43A2F76E.2020007@sbcglobal.net> Pekka Savola wrote: > On Fri, 16 Dec 2005, Michael Mansour wrote: > >> Just to add my 2 cents, I still use FC1, FC2 and FC3 on various >> servers and >> would still like to see FL support for them. > > > Whether or not there is "user base" for FC1 is irrelevant. Of course it's relevant. If nobody used or wanted FC1, it wouldn't be relevant. I suppose you mean that there being people who use it is insufficient to motivate you to continue to support it. Whether it motivates others to continue to support it, > The key point is, are FC1 users willing to participate in pushing out > packages (package proposal, verify QA, publish QA, etc.) ? > > The question is: > > If dropping FC1 wouldn't reduce the number of QA folks and the work > they do [for other distros], we should drop it. > Certainly. -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From jkeating at j2solutions.net Fri Dec 16 17:42:26 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 16 Dec 2005 09:42:26 -0800 Subject: What do users need to do to prepare? In-Reply-To: <43A2C459.8070305@carolina.rr.com> References: <43A2C459.8070305@carolina.rr.com> Message-ID: <1134754946.3005.160.camel@yoda.loki.me> On Fri, 2005-12-16 at 08:42 -0500, Jason Edgecombe wrote: > Hi there, > > as an admin of a few FC3 boxes, what do I need to do to prepare for the > transition? change yum.conf? add gpg keys? > > Can I set it up now or do I need to wait? > > I'd like to set it up now. Actually what would be best is if the Legacy group prepares a fedora-legacy-release package that drops a yum.repo file in /etc/yum.repos.d/ and most likely enables it. There was a lot of discussion about this earlier, I don't recall if I ever saw a package. The directory structure is present on the mirrors so now would be a good time to test that package. If we get the package created and tested, we can link to this package in the mail that goes out from the Fedora Project regarding the transition, making it easy for folks to come aboard. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From jpdalbec at ysu.edu Fri Dec 16 18:15:32 2005 From: jpdalbec at ysu.edu (John Dalbec) Date: Fri, 16 Dec 2005 13:15:32 -0500 Subject: [Mach-devel] mach 0.4.8 fc1 on fc4 problem Message-ID: <43A30444.4030304@ysu.edu> The kernel.vdso setting fixed the problem for me. I think I have SELinux turned on, but mach includes a preload library that disables SELinux features so I don't think that's a problem. Thanks, John -------- Original Message -------- Date: Thu, 15 Dec 2005 22:29:20 -0600 (CST) From: David Eisenstein Subject: Re: [Mach-devel] mach 0.4.8 fc1 on fc4 problem To: Discussion of the Fedora Legacy Project Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 15 Dec 2005, John Dalbec wrote: > I'm trying to set up a Fedora Core 1 build root in mach on Fedora Core > 3. The setup fails because ld-linux.so.2 -> ld-2.3.2.so segfaults in > dl_main(). See below for details. Any thoughts on how I can further > diagnose the problem? > Thanks, > John Dalbec > <> Hi John, Have you done this, from the mach README? "If you're on Fedora Core 2, and want to build for older targets, MAKE SURE you turn off vdso's by doing sysctl -w kernel.vdso=0 before using mach. You can add an entry to /etc/sysctl.conf to make this more permanent." I assume that will also be needed if you're running mach from FC3 or FC4 and trying to build for older targets. Also, do you have SELinux stuff turned on or off in your FC3 host? Dag Wieers indicates that there can be a number of compatibility problems that occur among versions of Red Hat and Fedora Core, and talks of a number of things one can try when using older software on newer kernels in his page, "Red Hat and Fedora Core Compatibility Tweaks." It says there, "How do I know it breaks because of [new and improved technologies integrated into their kernel]? "In most of the cases you won't. The resulting behaviour could be a segmentation fault on start-up, random crashes or even unexpected behaviours and spurious messages. ..." You may want to give some of Dag's tweaks a try if the vdso tweak doesn't help you: . -David From pekkas at netcore.fi Fri Dec 16 19:19:32 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 16 Dec 2005 21:19:32 +0200 (EET) Subject: active contributors and supporting distro foo In-Reply-To: <43A2F76E.2020007@sbcglobal.net> References: <1134700893.3005.131.camel@yoda.loki.me> <20051216034912.88457.qmail@web30401.mail.mud.yahoo.com> <20051216061339.M5291@npgx.com.au> <43A2F76E.2020007@sbcglobal.net> Message-ID: On Fri, 16 Dec 2005, Mike McCarty wrote: >> Whether or not there is "user base" for FC1 is irrelevant. > > Of course it's relevant. If nobody used or wanted FC1, it > wouldn't be relevant. I suppose you mean that there being > people who use it is insufficient to motivate you to continue > to support it. This isn't directed at you, but as a more generic rant -- as I see a lot of people asking to support "foo" but not putting in any hours to help in the process. The project is WAY too understaffed already. ... The only thing relevant (IMHO) is whether there are ACTIVE people ACTUALLY putting in work to 'Make It Happen' (tm). There is no such thing as free lunch. If you want updates for "foo", you should participate in creating those updates. Other folks may or may not do them for you. I'll rephrase to be clearer, because the project is way too understaffed already: - 90% of relevance: whether the distro has (enough) active contributors - 10% of relevance: whether there are sufficient number of users to make the effort worth the trouble of the active contributors - Only those who are or would be active contributors have a say in making a decision whether to support "foo" or not. -- 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 mike.mccarty at sbcglobal.net Fri Dec 16 19:35:53 2005 From: mike.mccarty at sbcglobal.net (Mike McCarty) Date: Fri, 16 Dec 2005 13:35:53 -0600 Subject: active contributors and supporting distro foo In-Reply-To: References: <1134700893.3005.131.camel@yoda.loki.me> <20051216034912.88457.qmail@web30401.mail.mud.yahoo.com> <20051216061339.M5291@npgx.com.au> <43A2F76E.2020007@sbcglobal.net> Message-ID: <43A31719.6050009@sbcglobal.net> Pekka Savola wrote: > On Fri, 16 Dec 2005, Mike McCarty wrote: > >>> Whether or not there is "user base" for FC1 is irrelevant. >> >> >> Of course it's relevant. If nobody used or wanted FC1, it >> wouldn't be relevant. I suppose you mean that there being >> people who use it is insufficient to motivate you to continue >> to support it. > > > This isn't directed at you, but as a more generic rant -- as I see a lot No offence taken, I'm sure. > of people asking to support "foo" but not putting in any hours to help > in the process. The project is WAY too understaffed already. I'm sure it is. My point was that if nobody used FC1, then it *certainly* would not be supported. So it is relevant. But having users may not be sufficient. > The only thing relevant (IMHO) is whether there are ACTIVE people > ACTUALLY putting in work to 'Make It Happen' (tm). > > There is no such thing as free lunch. If you want updates for "foo", > you should participate in creating those updates. Other folks may or > may not do them for you. I almost agree. I agree TANSTAAFL, but there may be people who use something but do not have the technical expertise either to maintain or to test the changes made to it. Even if they do, I don't put some sort of onus of "should" participate. Those who *do* participate do so for their own reasons, whatever they may be. If the results of those efforts are made freely available, then I don't fault anyone who picks them up and uses them. > I'll rephrase to be clearer, because the project is way too understaffed > already: > > - 90% of relevance: whether the distro has (enough) active > contributors > - 10% of relevance: whether there are sufficient number of users to > make the effort worth the trouble of the active contributors > - Only those who are or would be active contributors have a say in > making a decision whether to support "foo" or not. So, if there are lots of volunteers to support a completely abandoned version of software, you think it "should" be supported? The only one of your statements I agree with is the last. Those who volunteer their services do so for whatever motives they have, and have the absolute last word in whether they continue to do so, individually. You have stated your *own* criteria for continuing to participate. That does not mean that other contributors will or even should agree. It all depends on what their motives are. For all I know, there is a contributor who uses FC1 on a machine, and wishes to keep it so simply because it was the very first release of the "core" project. He might continue to make releases to the Legacy Support for that reason, even 10 years from now. Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! From kelson at speed.net Fri Dec 16 20:04:41 2005 From: kelson at speed.net (Kelson) Date: Fri, 16 Dec 2005 12:04:41 -0800 Subject: active contributors and supporting distro foo In-Reply-To: <43A31719.6050009@sbcglobal.net> References: <1134700893.3005.131.camel@yoda.loki.me> <20051216034912.88457.qmail@web30401.mail.mud.yahoo.com> <20051216061339.M5291@npgx.com.au> <43A2F76E.2020007@sbcglobal.net> <43A31719.6050009@sbcglobal.net> Message-ID: <43A31DD9.2080601@speed.net> Mike McCarty wrote: > Pekka Savola wrote: >> - 90% of relevance: whether the distro has (enough) active >> contributors >> - 10% of relevance: whether there are sufficient number of users to >> make the effort worth the trouble of the active contributors >> - Only those who are or would be active contributors have a say in >> making a decision whether to support "foo" or not. > > So, if there are lots of volunteers to support a completely abandoned > version of software, you think it "should" be supported? It seems to me that rather than debating about which condition is more relevant, we would be better served by stating: There are two necessary (but not sufficient) conditions for a distro to remain supported: 1. It must have enough active contributors. 2. It must have enough users that the effort is worth it. It's a simple AND operation. If either condition is false, the other is irrelevant -- percentages don't come into it. If both are true, then FL can decide whether to support it beyond the standard policy. -- Kelson Vibber SpeedGate Communications From sheltren at cs.ucsb.edu Fri Dec 16 22:31:49 2005 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Fri, 16 Dec 2005 18:31:49 -0400 Subject: What do users need to do to prepare? In-Reply-To: <1134754946.3005.160.camel@yoda.loki.me> References: <43A2C459.8070305@carolina.rr.com> <1134754946.3005.160.camel@yoda.loki.me> Message-ID: On Dec 16, 2005, at 1:42 PM, Jesse Keating wrote: > > Actually what would be best is if the Legacy group prepares a > fedora-legacy-release package that drops a yum.repo file > in /etc/yum.repos.d/ and most likely enables it. There was a lot of > discussion about this earlier, I don't recall if I ever saw a package. > The directory structure is present on the mirrors so now would be a > good > time to test that package. If we get the package created and > tested, we > can link to this package in the mail that goes out from the Fedora > Project regarding the transition, making it easy for folks to come > aboard. > Hi Jesse, yes, I did create a package, and I believe the latest revision of it is here: http://www.cs.ucsb.edu/~jeff/legacy/legacy-yumconf-3-2.fc3.src.rpm -Jeff From Axel.Thimm at ATrpms.net Sat Dec 17 00:00:24 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 17 Dec 2005 01:00:24 +0100 Subject: What do users need to do to prepare? In-Reply-To: <1134754946.3005.160.camel@yoda.loki.me> References: <43A2C459.8070305@carolina.rr.com> <1134754946.3005.160.camel@yoda.loki.me> Message-ID: <20051217000024.GA7978@neu.nirvana> On Fri, Dec 16, 2005 at 09:42:26AM -0800, Jesse Keating wrote: > On Fri, 2005-12-16 at 08:42 -0500, Jason Edgecombe wrote: > > Hi there, > > > > as an admin of a few FC3 boxes, what do I need to do to prepare for the > > transition? change yum.conf? add gpg keys? > > > > Can I set it up now or do I need to wait? > > > > I'd like to set it up now. > > Actually what would be best is if the Legacy group prepares a > fedora-legacy-release package that drops a yum.repo file > in /etc/yum.repos.d/ and most likely enables it. It should be enabled. If a user needs to download a package or even just a yum.repo file he already explicitly asked for legacy support. Having a two step procedure will only make users forget the second step. It is different if the package is merged into future fedora core packages (which it should!). FC5 for instance could start off with a disabled fedoralegacy entry, which users will have to enable. Someone (Jesse :) should lobby this to become part of fedora-release-5. > There was a lot of discussion about this earlier, I don't recall if > I ever saw a package. The directory structure is present on the > mirrors so now would be a good time to test that package. If we get > the package created and tested, we can link to this package in the > mail that goes out from the Fedora Project regarding the transition, > making it easy for folks to come aboard. > -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at j2solutions.net Sat Dec 17 00:07:40 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 16 Dec 2005 16:07:40 -0800 Subject: What do users need to do to prepare? In-Reply-To: <20051217000024.GA7978@neu.nirvana> References: <43A2C459.8070305@carolina.rr.com> <1134754946.3005.160.camel@yoda.loki.me> <20051217000024.GA7978@neu.nirvana> Message-ID: <1134778061.24472.25.camel@yoda.loki.me> On Sat, 2005-12-17 at 01:00 +0100, Axel Thimm wrote: > > It should be enabled. If a user needs to download a package or even > just a yum.repo file he already explicitly asked for legacy > support. Having a two step procedure will only make users forget the > second step. Yep, this was the conclusion we came to for the FC3 and FC4 stuff. FC5 was still a discussion as to if we wanted it disabled by default. > It is different if the package is merged into future fedora core > packages (which it should!). FC5 for instance could start off with a > disabled fedoralegacy entry, which users will have to enable. Someone > (Jesse :) should lobby this to become part of fedora-release-5. Already working on this. Legacy is now officially a subproject of Fedora, with me as the Chairman of the Fedora Legacy Project Management Committee. What does this mean? Nothing yet, I'm still trying to sort how we'll fit into this, and others to have on the committee. But this does mean that I can now continue with discussions such as having FL repo info shipped w/ FC5 and future releases. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From gene.heskett at verizon.net Sat Dec 17 00:23:28 2005 From: gene.heskett at verizon.net (Gene Heskett) Date: Fri, 16 Dec 2005 19:23:28 -0500 Subject: export/import of X q? Message-ID: <200512161923.28217.gene.heskett@verizon.net> Greetings all; If its not too much trouble, could an rpm of the latest ssh be made available in one of the fedora repo's? The one there is at least a revision out of dateand doesn't accept the -Y option on the cli. I have a case where the one on this FC2 box doesn't understand the -Y option, and the one on the target box doesn't understand the -X option when issued from here. Also its xorg-6.8.1-901 on this box (built from tarballs, works great!), and XFree86-4.3-something on that debian sarge based box that I'm trying to make an X app tun on by exporting its display to this box. There might be some incompatabilities there that I'm not familiar with. Is there any chance of making this work? -- Cheers, Gene People having trouble with vz bouncing email to me should use this address: which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. From deisenst at gtw.net Sat Dec 17 03:38:55 2005 From: deisenst at gtw.net (David Eisenstein) Date: Fri, 16 Dec 2005 21:38:55 -0600 (CST) Subject: export/import of X q? In-Reply-To: <200512161923.28217.gene.heskett@verizon.net> Message-ID: Just curious, Gene. What does the X11Forwarding line in your '/etc/ssh/sshd_config' file look like on your FC2 box? On your other box? -David On Fri, 16 Dec 2005, Gene Heskett wrote: > Greetings all; > > If its not too much trouble, could an rpm of the latest ssh be made <> From gene.heskett at verizon.net Sat Dec 17 11:03:44 2005 From: gene.heskett at verizon.net (Gene Heskett) Date: Sat, 17 Dec 2005 06:03:44 -0500 Subject: export/import of X q? In-Reply-To: References: Message-ID: <200512170603.45049.gene.heskett@verizon.net> On Friday 16 December 2005 22:38, David Eisenstein wrote: >/etc/ssh/sshd_config X11Forwarding yes On this FC2 box. But, on the other box it *was* no, I just changed it. Whats next? Thank you. -- Cheers, Gene People having trouble with vz bouncing email to me should use this address: which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. From marcdeslauriers at videotron.ca Sun Dec 18 05:12:59 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sun, 18 Dec 2005 00:12:59 -0500 Subject: [FLSA-2005:152787] Updated redhat-config-nfs package fixes security issue Message-ID: <43A4EFDB.8090507@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated redhat-config-nfs package fixes security issue Advisory ID: FLSA:152787 Issue date: 2005-12-17 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2004-0750 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: An updated redhat-config-nfs package that fixes a security issue is now available. redhat-config-nfs is a graphical user interface for creating, modifying, and deleting nfs shares. 2. Relevant releases/architectures: Red Hat Linux 9 - i386 Fedora Core 1 - i386 Fedora Core 2 - i386 3. Problem description: John Buswell discovered a flaw in redhat-config-nfs that could lead to incorrect permissions on exported shares when exporting to multiple hosts. This could cause an option such as "all_squash" to not be applied to all of the listed hosts. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2004-0750 to this issue. Additionally, a bug was found that prevented redhat-config-nfs from being run if hosts didn't have options set in /etc/exports. All users of redhat-config-nfs should upgrade to this updated package, which includes a patch to correct 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: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152787 6. RPMs required: Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/redhat-config-nfs-1.0.13-6.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/redhat-config-nfs-1.0.13-6.legacy.noarch.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/redhat-config-nfs-1.1.3-3.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/redhat-config-nfs-1.1.3-3.legacy.noarch.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/system-config-nfs-1.2.3-5.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/system-config-nfs-1.2.3-5.legacy.noarch.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 6d0c5c269b0702a5f7ef352e1c01390dfcedf66e redhat/9/updates/i386/redhat-config-nfs-1.0.13-6.legacy.noarch.rpm 7dfd3e3cd3e937144b0a79b38967749caea1f779 redhat/9/updates/SRPMS/redhat-config-nfs-1.0.13-6.legacy.src.rpm 376cd7a13d85877976d606a2a8dc57e5a9de1766 fedora/1/updates/i386/redhat-config-nfs-1.1.3-3.legacy.noarch.rpm b1828331941b0d64625dc5981990b63fb8f5ee26 fedora/1/updates/SRPMS/redhat-config-nfs-1.1.3-3.legacy.src.rpm e9694cfe870c4370ab080ef81fe2ee5d09f23a34 fedora/2/updates/i386/system-config-nfs-1.2.3-5.legacy.noarch.rpm 6e4cee9467fa66760b8e757000e771f167225377 fedora/2/updates/SRPMS/system-config-nfs-1.2.3-5.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=CVE-2004-0750 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: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Sun Dec 18 05:13:50 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sun, 18 Dec 2005 00:13:50 -0500 Subject: [FLSA-2005:152832] Updated lynx package fixes security issues Message-ID: <43A4F00E.8030208@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated lynx package fixes security issues Advisory ID: FLSA:152832 Issue date: 2005-12-17 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2005-2929 CVE-2005-3120 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: An updated lynx package that corrects security issues is now available. Lynx is a text-based Web browser. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 Fedora Core 1 - i386 Fedora Core 2 - i386 3. Problem description: An arbitrary command execute bug was found in the lynx "lynxcgi:" URI handler. An attacker could create a web page redirecting to a malicious URL which could execute arbitrary code as the user running lynx. The Common Vulnerabilities and Exposures project assigned the name CVE-2005-2929 to this issue. Ulf Harnhammar discovered a stack overflow bug in Lynx when handling connections to NNTP (news) servers. An attacker could create a web page redirecting to a malicious news server which could execute arbitrary code as the user running lynx. The Common Vulnerabilities and Exposures project assigned the name CVE-2005-3120 to this issue. Users should update to this erratum package, which contains backported patches to correct 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: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152832 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/ i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/ Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/ i386: http://download.fedoralegacy.org/redhat/9/updates/i386/ Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/ i386: http://download.fedoralegacy.org/fedora/1/updates/i386/ Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/ i386: http://download.fedoralegacy.org/fedora/2/updates/i386/ 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- f90ed394ffb119c628f30cbe24af00980e21ddec redhat/7.3/updates/i386/lynx-2.8.4-18.3.legacy.i386.rpm ae6eccd737ca25bd411bffb3db5a4ae46b512a0f redhat/7.3/updates/SRPMS/lynx-2.8.4-18.3.legacy.src.rpm e3f8bdd24f77bd9122afe9550b1711ec39580c30 redhat/9/updates/i386/lynx-2.8.5-11.2.legacy.i386.rpm e6f6f18d22595b977964b03e4f820ef4c259faf4 redhat/9/updates/SRPMS/lynx-2.8.5-11.2.legacy.src.rpm f9a79fc5425d1d853614c53c1ab158c9328c3078 fedora/1/updates/i386/lynx-2.8.5-13.2.legacy.i386.rpm 6711308acdcff88c914cda153f0862253efa0b67 fedora/1/updates/SRPMS/lynx-2.8.5-13.2.legacy.src.rpm ff7d68c03bbe5cbeac076e5153dc964b8900a8d5 fedora/2/updates/i386/lynx-2.8.5-15.2.legacy.i386.rpm e46bb7466177677c5a6032fcef7a71bc55145984 fedora/2/updates/SRPMS/lynx-2.8.5-15.2.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=CVE-2005-2929 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3120 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: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Sun Dec 18 05:14:39 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sun, 18 Dec 2005 00:14:39 -0500 Subject: [FLSA-2005:152870] Updated a2ps package fixes security issue Message-ID: <43A4F03F.9040402@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated a2ps package fixes security issue Advisory ID: FLSA:152870 Issue date: 2005-12-17 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2004-1170 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: An updated a2ps package that fixes a security bug is now available. The a2ps filter converts text and other types of files to PostScript format. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 Fedora Core 1 - i386 3. Problem description: A problem was discovered in the way a2ps handles filenames that include shell metacharacters. An attacker could use this flaw to execute arbitrary commands by providing a filename that includes metacharacters as an argument. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2004-1170 to this issue. All users of a2ps should upgrade to this updated package, which includes a patch to correct 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: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152870 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/a2ps-4.13b-19.2.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/a2ps-4.13b-19.2.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/a2ps-4.13b-28.2.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/a2ps-4.13b-28.2.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/a2ps-4.13b-30.2.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/a2ps-4.13b-30.2.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- b0ebb139fd78a887831f8528458d969c42841283 redhat/7.3/updates/i386/a2ps-4.13b-19.2.legacy.i386.rpm fb55530b7f25e02080fcd8c5126f9f5f042a5d43 redhat/7.3/updates/SRPMS/a2ps-4.13b-19.2.legacy.src.rpm 828dc69302ec1530ada589842da023e3eb796ab5 redhat/9/updates/i386/a2ps-4.13b-28.2.legacy.i386.rpm 8b3ef7ab2dca9d436fb34b2d11935921842c2779 redhat/9/updates/SRPMS/a2ps-4.13b-28.2.legacy.src.rpm 87a14c8ceafcc6e633430ed3715a9d63c3c9e837 fedora/1/updates/i386/a2ps-4.13b-30.2.legacy.i386.rpm 9426b2180ef3750090b05616daa776f88bbfb3fa fedora/1/updates/SRPMS/a2ps-4.13b-30.2.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=CVE-2004-1170 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: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Sun Dec 18 05:15:20 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sun, 18 Dec 2005 00:15:20 -0500 Subject: [FLSA-2005:152892] Updated enscript package fixes security issues Message-ID: <43A4F068.9070205@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated enscript package fixes security issues Advisory ID: FLSA:152892 Issue date: 2005-12-17 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2004-1184 CVE-2004-1185 CVE-2004-1186 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: An updated enscript package that fixes several security issues is now available. GNU enscript converts ASCII files to PostScript. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 Fedora Core 1 - i386 3. Problem description: Enscript has the ability to interpret special escape sequences. A flaw was found in the handling of the epsf command used to insert inline EPS files into a document. An attacker could create a carefully crafted ASCII file which made use of the epsf pipe command in such a way that it could execute arbitrary commands if the file was opened with enscript by a victim. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2004-1184 to this issue. Additional flaws in Enscript were also discovered which can only be triggered by executing enscript with carefully crafted command line arguments. These flaws therefore only have a security impact if enscript is executed by other programs and passed untrusted data from remote users. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the names CVE-2004-1185 and CVE-2004-1186 to these issues. All users of enscript should upgrade to these updated packages, which resolve 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: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152892 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/enscript-1.6.1-19.73.2.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/enscript-1.6.1-19.73.2.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/enscript-1.6.1-24.2.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/enscript-1.6.1-24.2.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/enscript-1.6.1-25.1.1.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/enscript-1.6.1-25.1.1.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- ac29cc61b638a8a4a6e70642a48d4d4e7985a94c redhat/7.3/updates/i386/enscript-1.6.1-19.73.2.legacy.i386.rpm 2cc05a10d33fb0bd13cad08ae622cebbbf94ada6 redhat/7.3/updates/SRPMS/enscript-1.6.1-19.73.2.legacy.src.rpm 275eecbd654c9cc15b17e65a2c60cff8c5ec6f58 redhat/9/updates/i386/enscript-1.6.1-24.2.legacy.i386.rpm ed838a6c0f4235c789a872e880ddc5aff2d0e457 redhat/9/updates/SRPMS/enscript-1.6.1-24.2.legacy.src.rpm f1de9a957caa34766434ea5e77ad31d49ee769dd fedora/1/updates/i386/enscript-1.6.1-25.1.1.legacy.i386.rpm f73d7da391cadf7d033dfe21979fb2ae10477fc6 fedora/1/updates/SRPMS/enscript-1.6.1-25.1.1.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=CVE-2004-1184 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1185 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1186 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: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Sun Dec 18 05:16:03 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sun, 18 Dec 2005 00:16:03 -0500 Subject: [FLSA-2005:155510] Updated gtk2 packages fixes security issues Message-ID: <43A4F093.8080508@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated gtk2 packages fixes security issues Advisory ID: FLSA:155510 Issue date: 2005-12-17 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2004-0753 CVE-2004-0782 CVE-2004-0783 CVE-2004-0788 CVE-2005-0891 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: Updated gtk2 packages that fix several security flaws are now available. The gtk2 package contains the GIMP ToolKit (GTK+), a library for creating graphical user interfaces for the X Window System. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 Fedora Core 1 - i386 3. Problem description: During testing of a previously fixed flaw in Qt (CVE-2004-0691), a flaw was discovered in the BMP image processor of gtk2. An attacker could create a carefully crafted BMP file which would cause an application to enter an infinite loop and not respond to user input when the file was opened by a victim. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2004-0753 to this issue. During a security audit Chris Evans discovered a stack and a heap overflow in the XPM image decoder. An attacker could create a carefully crafted XPM file which could cause an application linked with gtk2 to crash or possibly execute arbitrary code when the file was opened by a victim. (CVE-2004-0782, CVE-2004-0783) Chris Evans also discovered an integer overflow in the ICO image decoder. An attacker could create a carefully crafted ICO file which could cause an application linked with gtk2 to crash when the file was opened by a victim. (CVE-2004-0788) A bug was found in the way gtk2 processes BMP images. It is possible that a specially crafted BMP image could cause a denial of service attack on applications linked against gtk2. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-0891 to this issue. Users of gtk2 are advised to upgrade to these packages which contain backported patches and are not vulnerable to 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: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155510 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/gtk2-2.0.2-4.2.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/gtk2-2.0.2-4.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/gtk2-devel-2.0.2-4.2.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/gtk2-2.2.1-4.2.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/gtk2-2.2.1-4.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/gtk2-devel-2.2.1-4.2.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/gtk2-2.2.4-10.3.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/gtk2-2.2.4-10.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/gtk2-devel-2.2.4-10.3.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- f923e47859f2b8e973a19978baa299a9eb9510b9 redhat/7.3/updates/i386/gtk2-2.0.2-4.2.legacy.i386.rpm 0b42963350b57d6c8f4d77fc9e611d6e976d80b1 redhat/7.3/updates/i386/gtk2-devel-2.0.2-4.2.legacy.i386.rpm e975fad01109fe3e9efb1b1ab2d47db32b0b83ee redhat/7.3/updates/SRPMS/gtk2-2.0.2-4.2.legacy.src.rpm 5d06ac2e6c81087e13c175b457116c0fd6950057 redhat/9/updates/i386/gtk2-2.2.1-4.2.legacy.i386.rpm 99ef7dc3fdd67673358acc791ef306b914653271 redhat/9/updates/i386/gtk2-devel-2.2.1-4.2.legacy.i386.rpm 8ada7b7f6ee51a281d6e0079aba0f2c150fdbf06 redhat/9/updates/SRPMS/gtk2-2.2.1-4.2.legacy.src.rpm be0ba4a1776f9849cd5734ccb655b9dabb97011b fedora/1/updates/i386/gtk2-2.2.4-10.3.legacy.i386.rpm 501aa3181b863c6904004ec8ef5c9e38cef77652 fedora/1/updates/i386/gtk2-devel-2.2.4-10.3.legacy.i386.rpm 76c60fd3ca93a1291f6bb60403b3c080323fa855 fedora/1/updates/SRPMS/gtk2-2.2.4-10.3.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=CVE-2004-0753 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0782 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0783 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0788 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0891 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: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Sun Dec 18 05:16:46 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sun, 18 Dec 2005 00:16:46 -0500 Subject: [FLSA-2005:166939] Updated openssl packages fix security issues Message-ID: <43A4F0BE.5010104@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated openssl packages fix security issues Advisory ID: FLSA:166939 Issue date: 2005-12-17 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2004-0079 CVE-2005-0109 CVE-2005-2969 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: Updated OpenSSL packages that fix security issues are now available. OpenSSL is a toolkit that implements Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well as a full-strength general purpose cryptography library. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 Fedora Core 1 - i386 Fedora Core 2 - i386 3. Problem description: OpenSSL contained a software work-around for a bug in SSL handling in Microsoft Internet Explorer version 3.0.2. This work-around is enabled in most servers that use OpenSSL to provide support for SSL and TLS. Yutaka Oiwa discovered that this work-around could allow an attacker, acting as a "man in the middle" to force an SSL connection to use SSL 2.0 rather than a stronger protocol such as SSL 3.0 or TLS 1.0. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-2969 to this issue. A bug was fixed in the way OpenSSL creates DSA signatures. A cache timing attack was fixed in a previous advisory which caused OpenSSL to do private key calculations with a fixed time window. The DSA fix for this was not complete and the calculations are not always performed within a fixed-window. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-0109 to this issue. Testing performed by the OpenSSL group using the Codenomicon TLS Test Tool uncovered a null-pointer assignment in the do_change_cipher_spec() function. A remote attacker could perform a carefully crafted SSL/TLS handshake against a server that uses the OpenSSL library in such a way as to cause OpenSSL to crash. Depending on the server this could lead to a denial of service. (CVE-2004-0079) Users are advised to update to these erratum packages which contain patches to correct these issues. Note: After installing this update, users are advised to either restart all services that use OpenSSL or restart their system. 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: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166939 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/openssl095a-0.9.5a-24.7.6.legacy.src.rpm http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/openssl096-0.9.6-25.11.legacy.src.rpm http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/openssl-0.9.6b-39.10.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/openssl095a-0.9.5a-24.7.6.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/openssl096-0.9.6-25.11.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/openssl-0.9.6b-39.10.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/openssl-0.9.6b-39.10.legacy.i686.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/openssl-devel-0.9.6b-39.10.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/openssl-perl-0.9.6b-39.10.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/openssl096-0.9.6-25.12.legacy.src.rpm http://download.fedoralegacy.org/redhat/9/updates/SRPMS/openssl096b-0.9.6b-15.3.legacy.src.rpm http://download.fedoralegacy.org/redhat/9/updates/SRPMS/openssl-0.9.7a-20.6.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/openssl096-0.9.6-25.12.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/openssl096b-0.9.6b-15.3.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/openssl-0.9.7a-20.6.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/openssl-0.9.7a-20.6.legacy.i686.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/openssl-devel-0.9.7a-20.6.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/openssl-perl-0.9.7a-20.6.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/openssl096-0.9.6-26.3.legacy.src.rpm http://download.fedoralegacy.org/fedora/1/updates/SRPMS/openssl096b-0.9.6b-18.3.legacy.src.rpm http://download.fedoralegacy.org/fedora/1/updates/SRPMS/openssl-0.9.7a-33.13.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/openssl096-0.9.6-26.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/openssl096b-0.9.6b-18.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/openssl-0.9.7a-33.13.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/openssl-0.9.7a-33.13.legacy.i686.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/openssl-devel-0.9.7a-33.13.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/openssl-perl-0.9.7a-33.13.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/openssl096b-0.9.6b-20.3.legacy.src.rpm http://download.fedoralegacy.org/fedora/2/updates/SRPMS/openssl-0.9.7a-35.2.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/openssl096b-0.9.6b-20.3.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/openssl-0.9.7a-35.2.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/openssl-0.9.7a-35.2.legacy.i686.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/openssl-devel-0.9.7a-35.2.legacy.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/openssl-perl-0.9.7a-35.2.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 772eb428fce0f9244879936da6de8540c4a0da19 redhat/7.3/updates/i386/openssl095a-0.9.5a-24.7.6.legacy.i386.rpm 2abb561452161340c02522e5b304685bded02acc redhat/7.3/updates/i386/openssl096-0.9.6-25.11.legacy.i386.rpm 1c00535c2fd6314aba666132c49b62850387fa2e redhat/7.3/updates/i386/openssl-0.9.6b-39.10.legacy.i386.rpm eb04713acd216bf3e2b46ed11f5627af2937d726 redhat/7.3/updates/i386/openssl-0.9.6b-39.10.legacy.i686.rpm 5339f0df2ca59678b043c356000c80d6a06350e9 redhat/7.3/updates/i386/openssl-devel-0.9.6b-39.10.legacy.i386.rpm 602fb4b040aa26656f60771e56495f894da7a7d1 redhat/7.3/updates/i386/openssl-perl-0.9.6b-39.10.legacy.i386.rpm 94c051599af2faaaf771df548c801d8f046b2d94 redhat/7.3/updates/SRPMS/openssl095a-0.9.5a-24.7.6.legacy.src.rpm 876c535d8b28b2ffa22be646aa7021c57a62046c redhat/7.3/updates/SRPMS/openssl096-0.9.6-25.11.legacy.src.rpm 046b9d93eee9dcd9b69f89f185ad3065c78fd4ec redhat/7.3/updates/SRPMS/openssl-0.9.6b-39.10.legacy.src.rpm a404db788cdcdf1b267dde272dd6db3cf1891ba2 redhat/9/updates/i386/openssl096-0.9.6-25.12.legacy.i386.rpm 11cf0a7546f054b5fcff676a88deb27e45cdb0cd redhat/9/updates/i386/openssl096b-0.9.6b-15.3.legacy.i386.rpm 62eb39923eb2a98a1749a58a28fce5c425587387 redhat/9/updates/i386/openssl-0.9.7a-20.6.legacy.i386.rpm e97a1fb8963711a2c97e298173d30fe64abd7a3f redhat/9/updates/i386/openssl-0.9.7a-20.6.legacy.i686.rpm dca80e912b43137b71e966cdc956b50324fd59fc redhat/9/updates/i386/openssl-devel-0.9.7a-20.6.legacy.i386.rpm 1f34a94f36d3b7fa56b633fc134eac3d99a08f45 redhat/9/updates/i386/openssl-perl-0.9.7a-20.6.legacy.i386.rpm daa7c0eb8f988a152db550398ec6c3e9ad08418e redhat/9/updates/SRPMS/openssl096-0.9.6-25.12.legacy.src.rpm beff357b1eabf4dbd89bd2776d83ad8157e4668b redhat/9/updates/SRPMS/openssl096b-0.9.6b-15.3.legacy.src.rpm d010302930f88638255581d7f4d8d245fc5f1f4f redhat/9/updates/SRPMS/openssl-0.9.7a-20.6.legacy.src.rpm 6e2a5333e1a41cf7c87b0bd704f37ebeefb19011 fedora/1/updates/i386/openssl096-0.9.6-26.3.legacy.i386.rpm aca4f861c4dde379cec5351f56c7aec4b2e47310 fedora/1/updates/i386/openssl096b-0.9.6b-18.3.legacy.i386.rpm 620c574712782b4e349ed1392d1d674507a146cc fedora/1/updates/i386/openssl-0.9.7a-33.13.legacy.i386.rpm 5518b5e24176b056dae1e653a4abb9f2dd227d99 fedora/1/updates/i386/openssl-0.9.7a-33.13.legacy.i686.rpm 5ce78af8e1d18ec2deb174ac6fdce6e84c68e46a fedora/1/updates/i386/openssl-devel-0.9.7a-33.13.legacy.i386.rpm 1bee0f14e627fde0951377e1bf2f90b190152967 fedora/1/updates/i386/openssl-perl-0.9.7a-33.13.legacy.i386.rpm 0d7079c953bb754c45c5a0231c5b292b814ce3f6 fedora/1/updates/SRPMS/openssl096-0.9.6-26.3.legacy.src.rpm 8350ee0de5d81a3a0a842745997f89f8aae9e37f fedora/1/updates/SRPMS/openssl096b-0.9.6b-18.3.legacy.src.rpm b116a8978d0ea6720193ac67c927d1c07eb122c4 fedora/1/updates/SRPMS/openssl-0.9.7a-33.13.legacy.src.rpm 0b4dd57385c42886afbd62bc17c3b10fb3b28d38 fedora/2/updates/i386/openssl096b-0.9.6b-20.3.legacy.i386.rpm d8773965612fda44388b73296ba8fb9caea9db1f fedora/2/updates/i386/openssl-0.9.7a-35.2.legacy.i386.rpm 45c1a884034056c1f3f31f6a61af617a44a31e47 fedora/2/updates/i386/openssl-0.9.7a-35.2.legacy.i686.rpm 24f03de813df1d534d3d847fde68ffd603a2e234 fedora/2/updates/i386/openssl-devel-0.9.7a-35.2.legacy.i386.rpm a990c20059b07984cc06a1029219b713650b0cfd fedora/2/updates/i386/openssl-perl-0.9.7a-35.2.legacy.i386.rpm b39cd980bda3350d69ee5a4da934fb54c956c965 fedora/2/updates/SRPMS/openssl096b-0.9.6b-20.3.legacy.src.rpm 63d5d41cd2be5a010c2ad2c6276f0ddba2948e38 fedora/2/updates/SRPMS/openssl-0.9.7a-35.2.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=CVE-2004-0079 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0109 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2969 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: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Sun Dec 18 05:17:49 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sun, 18 Dec 2005 00:17:49 -0500 Subject: [FLSA-2005:168326] Updated util-linux and mount packages fix security issue Message-ID: <43A4F0FD.50804@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated util-linux and mount packages fix security issue Advisory ID: FLSA:168326 Issue date: 2005-12-18 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2005-2876 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: Updated util-linux and mount packages that fix a security issue are now available. The util-linux package contains a large variety of low-level system utilities that are necessary for a Linux system to function. The mount package contains the mount, umount, swapon and swapoff programs. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 Fedora Core 1 - i386 Fedora Core 2 - i386 3. Problem description: A bug was found in the way the umount command is executed by normal users. It may be possible for a user to gain elevated privileges if the user is able to execute the "umount -r" command on a mounted file system. The file system will be re-mounted only with the "readonly" flag set, clearing flags such as "nosuid" and "noexec". The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-2876 to this issue. All users of util-linux and mount should upgrade to these updated packages, which contain a backported patch to correct 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: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168326 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/util-linux-2.11n-12.7.3.2.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/mount-2.11n-12.7.3.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/util-linux-2.11n-12.7.3.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/losetup-2.11n-12.7.3.2.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/util-linux-2.11y-9.2.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/mount-2.11y-9.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/util-linux-2.11y-9.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/losetup-2.11y-9.2.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/util-linux-2.11y-29.2.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/mount-2.11y-29.2.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/util-linux-2.11y-29.2.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/losetup-2.11y-29.2.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/util-linux-2.12-19.1.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/util-linux-2.12-19.1.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 437139c00fbc4109ea3cd66b88a778a023d07298 redhat/7.3/updates/i386/mount-2.11n-12.7.3.2.legacy.i386.rpm e39b80b435a545f87878cb2d4f6e89d89ec2c88f redhat/7.3/updates/i386/util-linux-2.11n-12.7.3.2.legacy.i386.rpm 0c671214cb28d21b71917d04e4cdce3240515b45 redhat/7.3/updates/i386/losetup-2.11n-12.7.3.2.legacy.i386.rpm a35553671d54999b0929f42a1283252b1cab1d18 redhat/7.3/updates/SRPMS/util-linux-2.11n-12.7.3.2.legacy.src.rpm cbe71d4ed7c39c0ed186a548c194c44e3328595b redhat/9/updates/i386/mount-2.11y-9.2.legacy.i386.rpm 926ae6d1c9f6d5309ab24c712cbe2a3ec97bba1c redhat/9/updates/i386/util-linux-2.11y-9.2.legacy.i386.rpm 969d19231dc24415f7d761539b59ba772c716a36 redhat/9/updates/i386/losetup-2.11y-9.2.legacy.i386.rpm 9ac87483879c1df0ed9c100081e19b7614af8f79 redhat/9/updates/SRPMS/util-linux-2.11y-9.2.legacy.src.rpm 881c066cf8ec3aa25450a7e8db2f43e55faaef40 fedora/1/updates/i386/mount-2.11y-29.2.legacy.i386.rpm f1b2f60ee7b5fb3149ab3b36133c930c6eecb788 fedora/1/updates/i386/util-linux-2.11y-29.2.legacy.i386.rpm 501380711d59e946f1dab5a40b0906525393d766 fedora/1/updates/i386/losetup-2.11y-29.2.legacy.i386.rpm 65519afd06a882abad31b847ad7053936dfd0ef4 fedora/1/updates/SRPMS/util-linux-2.11y-29.2.legacy.src.rpm 72c70f92397f84a3f021c6cef964fa0fb9b8cc57 fedora/2/updates/i386/util-linux-2.12-19.1.legacy.i386.rpm 2c93eefe88d57118fc2ddfee7fd5949e3d58c38f fedora/2/updates/SRPMS/util-linux-2.12-19.1.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=CVE-2005-2876 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: OpenPGP digital signature URL: From mic at npgx.com.au Mon Dec 19 01:25:04 2005 From: mic at npgx.com.au (Michael Mansour) Date: Mon, 19 Dec 2005 11:25:04 +1000 Subject: Failed primary.xml.gz in FC1 Message-ID: <20051219012334.M98403@npgx.com.au> Hi, When I try and perform a check-update to get the latest FL updates for an FC1 machine, I get the following: # yum check-update Setting up repositories Reading repository metadata in from local files primary.xml.gz 100% |=========================| 254 kB 00:05 http://download.fedoralegacy.org/fedora/1/updates/i386/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum Trying other mirror. Error: failure: repodata/primary.xml.gz from fedoralegacyupdates: [Errno 256] No more mirrors to try. Checking the file it is there and does exist, but seems to be broken? Michael. From deisenst at gtw.net Mon Dec 19 03:27:45 2005 From: deisenst at gtw.net (David Eisenstein) Date: Sun, 18 Dec 2005 21:27:45 -0600 (CST) Subject: Failed primary.xml.gz in FC1 In-Reply-To: <20051219012334.M98403@npgx.com.au> Message-ID: On Mon, 19 Dec 2005, Michael Mansour wrote: > Hi, > > When I try and perform a check-update to get the latest FL updates for an FC1 > machine, I get the following: > > # yum check-update > Setting up repositories > Reading repository metadata in from local files > primary.xml.gz 100% |=========================| 254 kB 00:05 > http://download.fedoralegacy.org/fedora/1/updates/i386/repodata/primary.xml.gz: > [Errno -1] Metadata file does not match checksum > Trying other mirror. > Error: failure: repodata/primary.xml.gz from fedoralegacyupdates: [Errno 256] > No more mirrors to try. > > Checking the file it is there and does exist, but seems to be broken? > > Michael. Hey Michael, Curious. What version of yum are you using? Looking at these lines in a freshly-downloaded repomd.xml from download.fedoralegacy.org versus an sha1sum of a freshly-downloaded primary.xml.gz, it appears that the checksum should match: ac9fbb74145e3e77e1c2354c1ee0e9de25385a48 1134883655 versus $ sha1sum primary.xml.gz ac9fbb74145e3e77e1c2354c1ee0e9de25385a48 primary.xml.gz Perhaps the headers are corrupted on your system and need to be re-down- loaded. Have you tried: # yum clean headers # yum check-update ? Warm regards, David Eisenstein From mic at npgx.com.au Mon Dec 19 03:46:11 2005 From: mic at npgx.com.au (Michael Mansour) Date: Mon, 19 Dec 2005 13:46:11 +1000 Subject: Failed primary.xml.gz in FC1 In-Reply-To: References: <20051219012334.M98403@npgx.com.au> Message-ID: <20051219033318.M69053@npgx.com.au> Hi David, > > Hi, > > > > When I try and perform a check-update to get the latest FL updates for an FC1 > > machine, I get the following: > > > > # yum check-update > > Setting up repositories > > Reading repository metadata in from local files > > primary.xml.gz 100% |=========================| 254 kB 00:05 > > http://download.fedoralegacy.org/fedora/1/updates/i386/repodata/primary.xml.gz: > > [Errno -1] Metadata file does not match checksum > > Trying other mirror. > > Error: failure: repodata/primary.xml.gz from fedoralegacyupdates: [Errno 256] > > No more mirrors to try. > > > > Checking the file it is there and does exist, but seems to be broken? > > > > Michael. > > Hey Michael, > > Curious. What version of yum are you using? I use the latest from ATrpms: yum-2.4.1-64.rhfc1.at I've been using yum from ATrpms for ages, and on multiple servers (FC1 - 3, RHEL3 - 4) so they are a uniform yum version (with the same features) through my environment and never a problem. Just today this has shown up. > Looking at these lines in a freshly-downloaded repomd.xml from > download.fedoralegacy.org versus an sha1sum of a freshly-downloaded > primary.xml.gz, it appears that the checksum should match: > > > > ac9fbb74145e3e77e1c2354c1ee0e9de25385a48 > 1134883655 > > versus > > $ sha1sum primary.xml.gz > ac9fbb74145e3e77e1c2354c1ee0e9de25385a48 primary.xml.gz Checking my one: # sha1sum primary.xml.gz ac9fbb74145e3e77e1c2354c1ee0e9de25385a48 primary.xml.gz The same as that too. > Perhaps the headers are corrupted on your system and need to be re- > down- loaded. Have you tried: > > # yum clean headers > # yum check-update Hmmm.. I've run both these and it seems to have fixed the problem: # yum check-update Setting up repositories Reading repository metadata in from local files primary.xml.gz 100% |=========================| 254 kB 00:05 fedoralega: ################################################## 730/730 Added 730 new packages, deleted 0 old in 7.09 seconds a2ps.i386 4.13b-30.2.legacy fedoralegacyupdates enscript.i386 1.6.1-25.1.1.legacy fedoralegacyupdates gtk2.i386 2.2.4-10.3.legacy fedoralegacyupdates losetup.i386 2.11y-29.2.legacy fedoralegacyupdates lynx.i386 2.8.5-13.2.legacy fedoralegacyupdates mount.i386 2.11y-29.2.legacy fedoralegacyupdates openssl.i686 0.9.7a-33.13.legacy fedoralegacyupdates openssl-devel.i386 0.9.7a-33.13.legacy fedoralegacyupdates redhat-config-nfs.noarch 1.1.3-3.legacy fedoralegacyupdates util-linux.i386 2.11y-29.2.legacy fedoralegacyupdates Thanks. Michael. > ? > > Warm regards, > David Eisenstein > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list ------- End of Original Message ------- From jkeating at j2solutions.net Mon Dec 19 19:07:38 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 19 Dec 2005 11:07:38 -0800 Subject: Delay of FC5 Test2 (and thus FC3 going to Legacy) Message-ID: <1135019258.28062.58.camel@yoda.loki.me> We've decided to delay FC5 Test2 until after the holidays. New scheduled date for this release is January 16. This also means the transition of FC3 to Legacy is delayed. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From jkosin at beta.intcomgrp.com Tue Dec 20 17:41:33 2005 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Tue, 20 Dec 2005 12:41:33 -0500 Subject: [Fwd: FYI: branch-1-5: fix local denial of service in relink] Message-ID: <43A8424D.3080509@beta.intcomgrp.com> Everyone, Not sure if this interests anyone. I reported and the libtool group responded with a patch for the mktemp file patch supplied by redhat. The group did say it was an open security / DOS (denial of service) problem. Also, sorry about my email not being signed... Our network went from workgroup to domain and I lost my gpg signatures. Will have to make new later. Thanks, James Kosin ---- Original Message ---- From - Mon Dec 19 08:38:06 2005 X-Account-Key: account2 X-UIDL: AAwxUJBAAAQHAoeNlePNMK01LNu50oh5 X-Mozilla-Status: 1003 X-Mozilla-Status2: 00000000 Received: from smtp3.netcologne.de ([194.8.194.66]) by alpha-two.intcomgrp.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 18 Dec 2005 17:55:48 -0500 Received: from localhost.localdomain (xdsl-84-44-203-174.netcologne.de [84.44.203.174]) by smtp3.netcologne.de (Postfix) with ESMTP id 939B067490; Sun, 18 Dec 2005 23:51:01 +0100 (CET) Received: from ralf by localhost.localdomain with local (Exim 4.50) id 1Eo7Mr-0002bz-KH; Sun, 18 Dec 2005 23:51:01 +0100 Date: Sun, 18 Dec 2005 23:51:01 +0100 From: Ralf Wildenhues To: libtool-patches at gnu.org Cc: James Kosin Subject: FYI: branch-1-5: fix local denial of service in relink (was: LibTool-1.5.20 Test problems) Message-ID: <20051218225101.GB5502 at iam.uni-bonn.de> Mail-Followup-To: libtool-patches at gnu.org, James Kosin References: <4398449F.40205 at intcomgrp.com> <20051209075900.GD27592 at iam.uni-bonn.de> <43998D8D.40405 at intcomgrp.com> <20051209141321.GA6796 at iam.uni-bonn.de> <43999790.2030503 at intcomgrp.com> <20051218192425.GB20871 at iam.uni-bonn.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051218192425.GB20871 at iam.uni-bonn.de> Organization: Department of Numerical Simulation, University of Bonn User-Agent: Mutt/1.5.9i Return-Path: Ralf.Wildenhues at gmx.de X-OriginalArrivalTime: 18 Dec 2005 22:55:49.0187 (UTC) FILETIME=[30471130:01C60426] Applied to branch-1-5 (already fixed in HEAD). Cheers, Ralf * ltmain.in (func_mktempdir): New, backported from HEAD. (link mode): Use it. Fixes potential denial of service through malicious other local user. Reported by James Kosin . Index: ltmain.in =================================================================== RCS file: /cvsroot/libtool/libtool/Attic/ltmain.in,v retrieving revision 1.334.2.113 diff -u -r1.334.2.113 ltmain.in --- ltmain.in 18 Dec 2005 18:11:06 -0000 1.334.2.113 +++ ltmain.in 18 Dec 2005 18:37:12 -0000 @@ -141,6 +141,43 @@ # Shell function definitions: # This seems to be the best place for them +# func_mktempdir [string] +# Make a temporary directory that won't clash with other running +# libtool processes, and avoids race conditions if possible. If +# given, STRING is the basename for that directory. +func_mktempdir () +{ + my_template="${TMPDIR-/tmp}/${1-$progname}" + + if test "$run" = ":"; then + # Return a directory name, but don't create it in dry-run mode + my_tmpdir="${my_template}-$$" + else + + # If mktemp works, use that first and foremost + my_tmpdir=`mktemp -d "${my_template}-XXXXXXXX" 2>/dev/null` + + if test ! -d "$my_tmpdir"; then + # Failing that, at least try and use $RANDOM to avoid a race + my_tmpdir="${my_template}-${RANDOM-0}$$" + + save_mktempdir_umask=`umask` + umask 0077 + $mkdir "$my_tmpdir" + umask $save_mktempdir_umask + fi + + # If we're not in dry-run mode, bomb out on failure + test -d "$my_tmpdir" || { + $echo "cannot create temporary directory \`$my_tmpdir'" 1>&2 + exit $EXIT_FAILURE + } + fi + + $echo "X$my_tmpdir" | $Xsed +} + + # func_win32_libid arg # return the library type of file 'arg' # @@ -6095,18 +6132,7 @@ outputname= if test "$fast_install" = no && test -n "$relink_command"; then if test "$finalize" = yes && test -z "$run"; then - tmpdir="/tmp" - test -n "$TMPDIR" && tmpdir="$TMPDIR" - tmpdir="$tmpdir/libtool-$$" - save_umask=`umask` - umask 0077 - if $mkdir "$tmpdir"; then - umask $save_umask - else - umask $save_umask - $echo "$modename: error: cannot create temporary directory \`$tmpdir'" 1>&2 - continue - fi + tmpdir=`func_mktempdir` file=`$echo "X$file$stripped_ext" | $Xsed -e 's%^.*/%%'` outputname="$tmpdir/$file" # Replace the output file specification. -- Scanned by ClamAV - http://www.clamav.net From jpdalbec at ysu.edu Tue Dec 20 17:54:02 2005 From: jpdalbec at ysu.edu (John Dalbec) Date: Tue, 20 Dec 2005 12:54:02 -0500 Subject: createrepo Message-ID: <43A8453A.8060102@ysu.edu> I'm pleased to see that someone has run createrepo in http://download.fedoralegacy.org/redhat/7.3/updates/i386. Could that same person please run createrepo in http://download.fedoralegacy.org/redhat/7.3/os/i386? Thanks, John From jkeating at j2solutions.net Tue Dec 20 17:58:56 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 20 Dec 2005 09:58:56 -0800 Subject: createrepo In-Reply-To: <43A8453A.8060102@ysu.edu> References: <43A8453A.8060102@ysu.edu> Message-ID: <1135101536.4131.1.camel@yoda.loki.me> On Tue, 2005-12-20 at 12:54 -0500, John Dalbec wrote: > I'm pleased to see that someone has run createrepo in > http://download.fedoralegacy.org/redhat/7.3/updates/i386. Could that same > person please run createrepo in http://download.fedoralegacy.org/redhat/7.3/os/i386? > Thanks, > John Hah. I updated our generation script to use createrepo, but then forgot that we don't re-gen stuff in the os directories. I'll get this done today. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- 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 jkosin at beta.intcomgrp.com Tue Dec 20 18:24:14 2005 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Tue, 20 Dec 2005 13:24:14 -0500 Subject: Apache Security Advisory Message-ID: <43A84C4E.2090806@beta.intcomgrp.com> Everyone, Apache has this patch for 1.3 and 2.0 breanches of apache to fix CVE-2005-3352 http://issues.apache.org/bugzilla/show_bug.cgi?id=37874 I've just applied the patch to my version. I'm guessing that since they applied a patch to both branches this is definately a problem for all legacy users. James Kosin -- Scanned by ClamAV - http://www.clamav.net From jpdalbec at ysu.edu Tue Dec 20 18:32:58 2005 From: jpdalbec at ysu.edu (John Dalbec) Date: Tue, 20 Dec 2005 13:32:58 -0500 Subject: RPM/YUM/Mach catch-22 Message-ID: <43A84E5A.9080306@ysu.edu> Mach/apt is no longer supported Mach/yum doesn't work unless yum is at least the FC3 version RHL 7.3 libpng-devel is uninstallable using FC3 RPM because FC3 RPM expects versioned dependencies to include the epoch. I don't know whether adding the epoch to the versioned dependency would break RHL 7.3. Anyone see a way out of this? Thanks, John From jkeating at j2solutions.net Tue Dec 20 18:37:37 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 20 Dec 2005 10:37:37 -0800 Subject: RPM/YUM/Mach catch-22 In-Reply-To: <43A84E5A.9080306@ysu.edu> References: <43A84E5A.9080306@ysu.edu> Message-ID: <1135103857.4131.5.camel@yoda.loki.me> On Tue, 2005-12-20 at 13:32 -0500, John Dalbec wrote: > Mach/apt is no longer supported > Mach/yum doesn't work unless yum is at least the FC3 version > RHL 7.3 libpng-devel is uninstallable using FC3 RPM because FC3 RPM expects > versioned dependencies to include the epoch. > I don't know whether adding the epoch to the versioned dependency would break > RHL 7.3. When no epoch is present, 0 is assumed. Adding epoch 0 shouldn't break anything. Please try this and test within a chroot? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- 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 rdieter at math.unl.edu Tue Dec 20 18:59:00 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 20 Dec 2005 12:59:00 -0600 Subject: RPM/YUM/Mach catch-22 In-Reply-To: <43A84E5A.9080306@ysu.edu> References: <43A84E5A.9080306@ysu.edu> Message-ID: John Dalbec wrote: > Mach/apt is no longer supported > Mach/yum doesn't work unless yum is at least the FC3 version > RHL 7.3 libpng-devel is uninstallable using FC3 RPM because FC3 RPM > expects versioned dependencies to include the epoch. > I don't know whether adding the epoch to the versioned dependency would > break RHL 7.3. The missing epoch was/is a packaging bug, and fixing it won't break anything. -- Rex From rdieter at math.unl.edu Tue Dec 20 18:59:55 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 20 Dec 2005 12:59:55 -0600 Subject: RPM/YUM/Mach catch-22 In-Reply-To: <1135103857.4131.5.camel@yoda.loki.me> References: <43A84E5A.9080306@ysu.edu> <1135103857.4131.5.camel@yoda.loki.me> Message-ID: Jesse Keating wrote: > When no epoch is present, 0 is assumed. Adding epoch 0 shouldn't break > anything. Please try this and test within a chroot? Not with rh73's version of rpm. Epoch-less packages are the equivalent of Epoch -1 (ie, Epoch: 0 trumps a lack of Epoch). -- Rex From jkeating at j2solutions.net Tue Dec 20 19:17:07 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 20 Dec 2005 11:17:07 -0800 Subject: RPM/YUM/Mach catch-22 In-Reply-To: References: <43A84E5A.9080306@ysu.edu> <1135103857.4131.5.camel@yoda.loki.me> Message-ID: <1135106227.4131.23.camel@yoda.loki.me> On Tue, 2005-12-20 at 12:59 -0600, Rex Dieter wrote: > Not with rh73's version of rpm. Epoch-less packages are the equivalent > of Epoch -1 (ie, Epoch: 0 trumps a lack of Epoch). > Ah, my bad. I glazed over the whole epoch thing, going with 'dont add if not there, don't bump if there' -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- 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 rdieter at math.unl.edu Tue Dec 20 20:11:57 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 20 Dec 2005 14:11:57 -0600 Subject: mock/rh73 In-Reply-To: <43A84E5A.9080306@ysu.edu> References: <43A84E5A.9080306@ysu.edu> Message-ID: <43A8658D.3050308@math.unl.edu> John Dalbec wrote: > Mach/apt is no longer supported > Mach/yum doesn't work unless yum is at least the FC3 version Speaking of rh73... I've been trying to get mock/rh73 working (hosted on an rhel4 box), but have gotten stuck(*). Anyone have any luck with it? (*) chroot /var/lib/mock/redhat-7.3-i386/root seems to inherit the parent's (ie, the system/shell calling chroot) uids/guids, instead of pulling them from the chroot's passwd/group file. -- Rex From skvidal at linux.duke.edu Tue Dec 20 20:17:15 2005 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 20 Dec 2005 15:17:15 -0500 Subject: mock/rh73 In-Reply-To: <43A8658D.3050308@math.unl.edu> References: <43A84E5A.9080306@ysu.edu> <43A8658D.3050308@math.unl.edu> Message-ID: <1135109835.31481.66.camel@cutter> On Tue, 2005-12-20 at 14:11 -0600, Rex Dieter wrote: > John Dalbec wrote: > > Mach/apt is no longer supported > > Mach/yum doesn't work unless yum is at least the FC3 version > > Speaking of rh73... I've been trying to get mock/rh73 working (hosted on > an rhel4 box), but have gotten stuck(*). Anyone have any luck with it? > > (*) chroot /var/lib/mock/redhat-7.3-i386/root > seems to inherit the parent's (ie, the system/shell calling chroot) > uids/guids, instead of pulling them from the chroot's passwd/group file. > you're trying to get a chroot running INSIDE a chroot? -sv From rdieter at math.unl.edu Tue Dec 20 20:27:53 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 20 Dec 2005 14:27:53 -0600 Subject: mock/rh73 In-Reply-To: <1135109835.31481.66.camel@cutter> References: <43A84E5A.9080306@ysu.edu> <43A8658D.3050308@math.unl.edu> <1135109835.31481.66.camel@cutter> Message-ID: seth vidal wrote: > On Tue, 2005-12-20 at 14:11 -0600, Rex Dieter wrote: > >>John Dalbec wrote: >> >>>Mach/apt is no longer supported >>>Mach/yum doesn't work unless yum is at least the FC3 version >> >>Speaking of rh73... I've been trying to get mock/rh73 working (hosted on >>an rhel4 box), but have gotten stuck(*). Anyone have any luck with it? >> >>(*) chroot /var/lib/mock/redhat-7.3-i386/root >>seems to inherit the parent's (ie, the system/shell calling chroot) >>uids/guids, instead of pulling them from the chroot's passwd/group file. >> > > > you're trying to get a chroot running INSIDE a chroot? No, I was simulating what mock does by hand (since mock-helper gives no usable output), and found it failed calling 'useradd' with error "duplicate user id". -- Rex From jkeating at j2solutions.net Tue Dec 20 21:40:42 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 20 Dec 2005 13:40:42 -0800 Subject: [vendor-sec] New Fetchmail issue In-Reply-To: <200512202010.jBKKAMTt007149@devserv.devel.redhat.com> References: <200512202010.jBKKAMTt007149@devserv.devel.redhat.com> Message-ID: <1135114842.4131.39.camel@yoda.loki.me> On Tue, 2005-12-20 at 12:22 -0800, Josh Bressers wrote: > http://fetchmail.berlios.de/fetchmail-SA-2005-03.txt > > Just a DoS, nothing to cause a panic before the holiday :) From investigation and chatting w/ RH, seems only FC2 is affected by this (and FC3 but RH is fixing FC3). They recommend we update FC2's 6.2.5-2 to 6.2.5.5. The update is supposed to be security and serious bugfixes which fits into Legacy policy. Can someone file a bug? This isn't a private issue, so public bug is fine. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- 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 gene.heskett at verizon.net Wed Dec 21 05:05:57 2005 From: gene.heskett at verizon.net (Gene Heskett) Date: Wed, 21 Dec 2005 00:05:57 -0500 Subject: [vendor-sec] New Fetchmail issue In-Reply-To: <1135114842.4131.39.camel@yoda.loki.me> References: <200512202010.jBKKAMTt007149@devserv.devel.redhat.com> <1135114842.4131.39.camel@yoda.loki.me> Message-ID: <200512210005.57813.gene.heskett@verizon.net> On Tuesday 20 December 2005 16:40, Jesse Keating wrote: >On Tue, 2005-12-20 at 12:22 -0800, Josh Bressers wrote: >> http://fetchmail.berlios.de/fetchmail-SA-2005-03.txt >> >> Just a DoS, nothing to cause a panic before the holiday :) > >>From investigation and chatting w/ RH, seems only FC2 is affected by >this (and FC3 but RH is fixing FC3). They recommend we update FC2's >6.2.5-2 to 6.2.5.5. The update is supposed to be security and > serious bugfixes which fits into Legacy policy. > >Can someone file a bug? This isn't a private issue, so public bug is >fine. Thats fine to advise us Jesse, but the server is down again: ----------- [root at coyote /]# yum check-update Gathering header information file(s) from server(s) Server: Fedora Core 2 - Base retrygrab() failed for: http://download.fedoralegacy.org/fedora/2/os/i386/headers/header.info Executing failover method failover: out of servers to try Error getting file http://download.fedoralegacy.org/fedora/2/os/i386/headers/header.info [Errno 4] IOError: ------------ -- Cheers, Gene People having trouble with vz bouncing email to me should use this address: which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. From skvidal at linux.duke.edu Wed Dec 21 04:48:09 2005 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 20 Dec 2005 23:48:09 -0500 Subject: [vendor-sec] New Fetchmail issue In-Reply-To: <200512210005.57813.gene.heskett@verizon.net> References: <200512202010.jBKKAMTt007149@devserv.devel.redhat.com> <1135114842.4131.39.camel@yoda.loki.me> <200512210005.57813.gene.heskett@verizon.net> Message-ID: <1135140490.31481.93.camel@cutter> On Wed, 2005-12-21 at 00:05 -0500, Gene Heskett wrote: > On Tuesday 20 December 2005 16:40, Jesse Keating wrote: > >On Tue, 2005-12-20 at 12:22 -0800, Josh Bressers wrote: > >> http://fetchmail.berlios.de/fetchmail-SA-2005-03.txt > >> > >> Just a DoS, nothing to cause a panic before the holiday :) > > > >>From investigation and chatting w/ RH, seems only FC2 is affected by > >this (and FC3 but RH is fixing FC3). They recommend we update FC2's > >6.2.5-2 to 6.2.5.5. The update is supposed to be security and > > serious bugfixes which fits into Legacy policy. > > > >Can someone file a bug? This isn't a private issue, so public bug is > >fine. > > Thats fine to advise us Jesse, but the server is down again: > ----------- > [root at coyote /]# yum check-update > Gathering header information file(s) from server(s) > Server: Fedora Core 2 - Base > retrygrab() failed for: > http://download.fedoralegacy.org/fedora/2/os/i386/headers/header.info > Executing failover method > failover: out of servers to try > Error getting file http://download.fedoralegacy.org/fedora/2/os/i386/headers/header.info > [Errno 4] IOError: > ------------ no it's not. I just checked it and I checked its monitoring stats - it's not been down at all. You sure your network hasn't been having issues? -sv From deisenst at gtw.net Wed Dec 21 12:26:12 2005 From: deisenst at gtw.net (David Eisenstein) Date: Wed, 21 Dec 2005 06:26:12 -0600 (CST) Subject: Apache Security Advisory In-Reply-To: <43A84C4E.2090806@beta.intcomgrp.com> Message-ID: On Tue, 20 Dec 2005, James Kosin wrote: > Everyone, > > Apache has this patch for 1.3 and 2.0 breanches of apache to fix > CVE-2005-3352 > > http://issues.apache.org/bugzilla/show_bug.cgi?id=37874 > > I've just applied the patch to my version. I'm guessing that since they > applied a patch to both branches this is definately a problem for all > legacy users. > > James Kosin > This issue has been added to Fedora Legacy Bugzilla Issue #175406: . -David From deisenst at gtw.net Fri Dec 23 09:07:46 2005 From: deisenst at gtw.net (David Eisenstein) Date: Fri, 23 Dec 2005 03:07:46 -0600 (CST) Subject: CVE-2005-3962, Re: Perl Format String Vulnerability In-Reply-To: <439A026F.7080005@ysu.edu> Message-ID: On Fri, 9 Dec 2005, John Dalbec wrote: > Does this affect us? > > (1) HIGH: Perl Format String Vulnerability > Affected: > Perl versions 5.9.2 and 5.8.6 confirmed; potentially all Perl versions > Webmin version 1.23 and prior > > Description: Perl is widely used as a scripting language for a variety > of applications including web-based software. Perl contains a > vulnerability that can be triggered by passing a format specifier of the > form "%INT_MAXn". The vulnerability causes an integer variable in a Perl > function to wrap around (change its parity) that can be exploited to > execute arbitrary code. For instance, "%2147483647n" format specifier > will trigger the flaw in Perl running on 32-bit Operating Systems. Note > that the flaw can be exploited only via Perl-based applications that > contain a format string vulnerability. The discoverers have reportedly > found several applications that are vulnerable. > <> We are indeed vulnerable to this. As Pavel Kankovsky pointed out, RHL 7.3 is not likely vulnerable. But RHL 9, FC1 & FC2 appear to be vulnerable to this. This affects webmin as well, but we do not support webmin. Red Hat has issued updated packages for FC3, FC4, RHEL 3, and RHEL 4. >From RHEL-3's announcement: "An integer overflow bug was found in Perl's format string processor. It is possible for an attacker to cause perl to crash or execute arbitrary code if the attacker is able to process a malicious format string. This issue is only exploitable through a script wich passes arbitrary untrusted strings to the format string processor. The Common Vulnerabilities and Exposures project assigned the name CVE-2005-3962 to this issue." References: * CVE-2005-3962 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3962 * FEDORA-2005-1145 (FC3) http://www.redhat.com/archives/fedora-announce-list/2005-December/msg00043.html (which is updated by FEDORA-2005-1149 @ http://www.redhat.com/archives/fedora-announce-list/2005-December/msg00050.html). * FEDORA-2005-1144 (FC4) http://www.redhat.com/archives/fedora-announce-list/2005-December/msg00042.html * RHSA-2005:881 (RHEL3) http://rhn.redhat.com/errata/RHSA-2005-881.html * RHSA-2005:880 (RHEL4) http://rhn.redhat.com/errata/RHSA-2005-880.html > References: > DyadSecurity Advisory > http://www.dyadsecurity.com/perl-0002.html > http://www.dyadsecurity.com/webmin-0001.html > Posting by giarc > http://archives.neohapsis.com/archives/fulldisclosure/2005-12/0001.html > Posting by Dave Aitel > http://archives.neohapsis.com/archives/fulldisclosure/2005-12/0015.html > Webmin miniserv.pl Documentation > http://www.dyadsecurity.com/webmin-0001.html > Webmin Homepage > http://www.webmin.com > SecurityFocus BID > http://www.securityfocus.com/bid/15629 From mic at npgx.com.au Fri Dec 23 23:07:24 2005 From: mic at npgx.com.au (Michael Mansour) Date: Sat, 24 Dec 2005 09:07:24 +1000 Subject: CVE-2005-3962, Re: Perl Format String Vulnerability In-Reply-To: References: <439A026F.7080005@ysu.edu> Message-ID: <20051223230436.M48097@npgx.com.au> > > Does this affect us? > > > > (1) HIGH: Perl Format String Vulnerability > > Affected: > > Perl versions 5.9.2 and 5.8.6 confirmed; potentially all Perl versions > > Webmin version 1.23 and prior > > > > Description: Perl is widely used as a scripting language for a variety > > of applications including web-based software. Perl contains a > > vulnerability that can be triggered by passing a format specifier of the > > form "%INT_MAXn". The vulnerability causes an integer variable in a Perl > > function to wrap around (change its parity) that can be exploited to > > execute arbitrary code. For instance, "%2147483647n" format specifier > > will trigger the flaw in Perl running on 32-bit Operating Systems. Note > > that the flaw can be exploited only via Perl-based applications that > > contain a format string vulnerability. The discoverers have reportedly > > found several applications that are vulnerable. > > <> > > We are indeed vulnerable to this. As Pavel Kankovsky pointed out, > RHL 7.3 is not likely vulnerable. But RHL 9, FC1 & FC2 appear to be > vulnerable to this. This affects webmin as well, but we do not support > webmin. If you are running Webmin version 1.240 or older (and have logging via syslog enabled), then this affects you. Webmin version 1.250 has been out for a while which fixes this, so just upgrade. http://www.webmin.com Michael. From mic at npgx.com.au Tue Dec 27 01:36:58 2005 From: mic at npgx.com.au (Michael Mansour) Date: Tue, 27 Dec 2005 11:36:58 +1000 Subject: Latest contrib perl Message-ID: <20051227013429.M65826@npgx.com.au> Hi, I'm trying to apply the latest contrib perl from: http://www.fedoralegacy.org/contrib/perl/ namely: perl-5.8.3-19.2.legacy.i386.rpm perl-suidperl-5.8.3-19.2.legacy.i386.rpm but I get the following result: # rpm -Uvh perl-suidperl-5.8.3-19.2.legacy.i386.rpm perl-5.8.3-19.2.legacy.i386.rpm warning: perl-suidperl-5.8.3-19.2.legacy.i386.rpm: Header V3 DSA signature: NOKEY, key ID 5740edab error: Failed dependencies: libdb-4.2.so is needed by perl-5.8.3-19.2.legacy.i386 Where can I get libdb-4.2.so from? When I check via yum whatprovides, I can find everything except 4.2. Thanks. Michael. From deisenst at gtw.net Tue Dec 27 06:14:59 2005 From: deisenst at gtw.net (David Eisenstein) Date: Tue, 27 Dec 2005 00:14:59 -0600 (CST) Subject: Need discussion, Re: Latest contrib perl In-Reply-To: <20051227013429.M65826@npgx.com.au> Message-ID: On Tue, 27 Dec 2005, Michael Mansour wrote: > Hi, > > I'm trying to apply the latest contrib perl from: > > http://www.fedoralegacy.org/contrib/perl/ > > namely: > > perl-5.8.3-19.2.legacy.i386.rpm > perl-suidperl-5.8.3-19.2.legacy.i386.rpm > > but I get the following result: > > # rpm -Uvh perl-suidperl-5.8.3-19.2.legacy.i386.rpm > perl-5.8.3-19.2.legacy.i386.rpm > warning: perl-suidperl-5.8.3-19.2.legacy.i386.rpm: Header V3 DSA signature: > NOKEY, key ID 5740edab > error: Failed dependencies: > libdb-4.2.so is needed by perl-5.8.3-19.2.legacy.i386 > > Where can I get libdb-4.2.so from? > > When I check via yum whatprovides, I can find everything except 4.2. > > Thanks. > > Michael. What version of Linux are you using, Michael? The perl-5.8.3-19.2.legacy.i386.rpm series as posted to fedoralegacy.org/contrib is a pre-testing Legacy version of Perl compiled for use with Fedora Core 2. I was thinking you use Fedora Core 1. You may wish to check Bugzilla bug # 152845 at to make sure you're downloading the binaries for the Distro you are running. Assuming binaries are available there. (If you're running FC1, I have binaries at home on my system I can upload there that match the FC1 sources, if you want to use them. I've only uploaded the FC1 sources (perl-5.8.3-17.3.legacy.src.rpm) there. But you may want to wait for the version of Perl for your OS Distro being built now that should be pushed to updates-testing in a day or two.) Remember, Michael. The binary (and source!) packages published at have not been through full QA. You use them AT YOUR OWN RISK! NEW PERL BUGZILLA TICKET NEEDED? --- ---- -------- ------ ------- I think we need to open a new Bug report for the more recent Perl vulnerability(ies), CVE-2005-3962, "Integer overflow in the format string functionality...." Either that, or we need to add the fixes for this CVE to the current Perl Bugzilla 152845 that we are working on (and get some participation in QA'ing it!!!). Would appreciate your (and everyone's!) opinion on this, Michael. Because of low interest (or low prioritization for doing QA work) by participants of the Fedora Legacy Project for Perl, the Perl bug # 152845 has been open for more than a year and gotten rather long in the tooth: However, it has over that year accumulated a lot of important Security fixes. Just not yet CVE-2005-3962 (which is rated moderate security impact by the Red Hat Security Response Team) ... I am in the process of building (for updates-testing) binary Perl packages that have passed our PUBLISH QA in that bug (for all Security issues we know of except for CVE-2005-3962) on Fedora Legacy's build server, and I hope we can have test packages pushed to updates-testing within a day or two. But we can stop this process and fold in updates for CVE-2005-3962 if it is felt that it is necessary to do so at this point. My fear is, if we *DO* stop the build process to fold in CVE-2005-3962 for the vulnerable distro's, it will be yet another year before we get the necessary QA for Perl's source rpms so we can build for updates-testing, let alone push to updates! Whatever we decide to do, your QA on upcoming binary packages will be most warmly accepted. :) Thanks. Warm regards, David Eisenstein From deisenst at gtw.net Tue Dec 27 06:43:53 2005 From: deisenst at gtw.net (David Eisenstein) Date: Tue, 27 Dec 2005 00:43:53 -0600 (CST) Subject: Santa Source Code Message-ID: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% SANTA SOURCE CODE By Unknown #bash better !pout !cry better watchout lpr why santa claus town cat /etc/passwd >list ncheck list ncheck list cat list | grep naughty >nogiftlist cat list | grep nice >giftlist santa claus town who | grep sleeping who | grep awake who | egrep 'bag|good' for (goodnes sake) { be good } better !pout !cry better watchout lpr why santa claus town [original source unknown] as quoted from: THE JOURNAL OF AMERICAN UNDERGROUND COMPUTING ====================================================================== ISSN 1074-3111 Volume One, Issue Seven January 17, 1995 ====================================================================== From mic at npgx.com.au Tue Dec 27 08:48:56 2005 From: mic at npgx.com.au (Michael Mansour) Date: Tue, 27 Dec 2005 18:48:56 +1000 Subject: Need discussion, Re: Latest contrib perl In-Reply-To: References: <20051227013429.M65826@npgx.com.au> Message-ID: <20051227083935.M38121@npgx.com.au> Hi, > > Hi, > > > > I'm trying to apply the latest contrib perl from: > > > > http://www.fedoralegacy.org/contrib/perl/ > > > > namely: > > > > perl-5.8.3-19.2.legacy.i386.rpm > > perl-suidperl-5.8.3-19.2.legacy.i386.rpm > > > > but I get the following result: > > > > # rpm -Uvh perl-suidperl-5.8.3-19.2.legacy.i386.rpm > > perl-5.8.3-19.2.legacy.i386.rpm > > warning: perl-suidperl-5.8.3-19.2.legacy.i386.rpm: Header V3 DSA signature: > > NOKEY, key ID 5740edab > > error: Failed dependencies: > > libdb-4.2.so is needed by perl-5.8.3-19.2.legacy.i386 > > > > Where can I get libdb-4.2.so from? > > > > When I check via yum whatprovides, I can find everything except 4.2. > > > > Thanks. > > > > Michael. > > What version of Linux are you using, Michael? The I'm using FC1. > perl-5.8.3-19.2.legacy.i386.rpm series as posted to > fedoralegacy.org/contrib is a pre-testing Legacy version of Perl compiled > for use with Fedora Core 2. I was thinking you use Fedora Core 1. > > You may wish to check Bugzilla bug # 152845 at > > > > to make sure you're downloading the binaries for the Distro you are > running. Assuming binaries are available there. (If you're running > FC1, I have binaries at home on my system I can upload there that > match the FC1 sources, if you want to use them. I've only uploaded > the FC1 sources > (perl-5.8.3-17.3.legacy.src.rpm) there. But you may want to wait The perl versions I'm currently using on FC1 are from that directory: # rpm -q perl perl-suidperl perl-5.8.3-18.1.legacy perl-suidperl-5.8.3-18.1.legacy I was unaware that they may have been built for FC2. But either way I needed to upgrade as I was getting hacked at the time through perl exploits and those contrib perl's were protecting my system. > for the version of Perl for your OS Distro being built now that > should be pushed to updates-testing in a day or two.) Yeah I don't mind waiting, but I'm concerned that waiting (like I did before) would just invite hackers in. I have very good protection for alot of hacks and use things like nessus, blacklists, etc to monitor and protect my environment, but from the last hack attempt where they were successful, I just can't be too careful and see prevention being much better than fixing later. > Remember, Michael. The binary (and source!) packages published at > have not been through full QA. > You use them AT YOUR OWN RISK! Yes I understand that and am aware of it, but sometimes it's still worthwhile implementing them and fixing whatever they break than getting hacked. > NEW PERL BUGZILLA TICKET NEEDED? > --- ---- -------- ------ ------- > > I think we need to open a new Bug report for the more recent Perl > vulnerability(ies), CVE-2005-3962, "Integer overflow in the format string > functionality...." Either that, or we need to add the fixes for > this CVE to the current Perl Bugzilla 152845 that we are working on > (and get some participation in QA'ing it!!!). Would appreciate your > (and everyone's!) opinion on this, Michael. > > Because of low interest (or low prioritization for doing QA work) by > participants of the Fedora Legacy Project for Perl, the Perl bug # 152845 > has been open for more than a year and gotten rather long in the tooth: > However, it has over that year accumulated a lot of important > Security fixes. Just not yet CVE-2005-3962 (which is rated moderate > security impact by the Red Hat Security Response Team) ... > > I am in the process of building (for updates-testing) binary Perl packages > that have passed our PUBLISH QA in that bug (for all Security issues > we know of except for CVE-2005-3962) on Fedora Legacy's build server, > and I hope we can have test packages pushed to updates-testing > within a day or two. But we can stop this process and fold in > updates for CVE-2005-3962 if it is felt that it is necessary to do > so at this point. > > My fear is, if we *DO* stop the build process to fold in CVE-2005- > 3962 for the vulnerable distro's, it will be yet another year before > we get the necessary QA for Perl's source rpms so we can build for > updates-testing, let alone push to updates! > > Whatever we decide to do, your QA on upcoming binary packages will > be most warmly accepted. :) I'm more than happy to do this, as I run production FC1/FC2/FC3 servers, and have duplicates in test which I can apply on before I move them into production. Thanks for your comments mate and when you do publish the latest FC1 perl RPMs, I'll be sure to keep an eye out on this list to test them. Michael. > Thanks. > > Warm regards, > David Eisenstein > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list ------- End of Original Message ------- From nils at lemonbit.nl Tue Dec 27 09:29:13 2005 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Tue, 27 Dec 2005 10:29:13 +0100 Subject: Latest contrib perl In-Reply-To: <20051227013429.M65826@npgx.com.au> References: <20051227013429.M65826@npgx.com.au> Message-ID: Michael Mansour wrote: > I'm trying to apply the latest contrib perl from: > > http://www.fedoralegacy.org/contrib/perl/ > > namely: > > perl-5.8.3-19.2.legacy.i386.rpm > perl-suidperl-5.8.3-19.2.legacy.i386.rpm > > but I get the following result: > > # rpm -Uvh perl-suidperl-5.8.3-19.2.legacy.i386.rpm > perl-5.8.3-19.2.legacy.i386.rpm > warning: perl-suidperl-5.8.3-19.2.legacy.i386.rpm: Header V3 DSA > signature: > NOKEY, key ID 5740edab > error: Failed dependencies: > libdb-4.2.so is needed by perl-5.8.3-19.2.legacy.i386 > > Where can I get libdb-4.2.so from? > > When I check via yum whatprovides, I can find everything except 4.2. I have db4-4.2.52-3.1 installed on a FC2 box. # rpm -ql db4 | grep libdb-4.2 /lib/libdb-4.2.so /lib/tls/libdb-4.2.so /usr/lib/libdb-4.2.so /usr/lib/tls/libdb-4.2.so Nils. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From jpdalbec at ysu.edu Tue Dec 27 17:25:05 2005 From: jpdalbec at ysu.edu (John Dalbec) Date: Tue, 27 Dec 2005 12:25:05 -0500 Subject: Need discussion, Re: Latest contrib perl In-Reply-To: <20051227170018.E98E473627@hormel.redhat.com> References: <20051227170018.E98E473627@hormel.redhat.com> Message-ID: <43B178F1.4000907@ysu.edu> Michael Mansour wrote: > The perl versions I'm currently using on FC1 are from that directory: > > # rpm -q perl perl-suidperl > perl-5.8.3-18.1.legacy > perl-suidperl-5.8.3-18.1.legacy I built these versions for FC1; however, they are actually older than the -17.3.legacy versions. I didn't realize at the time that FC2 already had a -18 version. You should install the -17.3.legacy versions for the latest FC1 update. RPM will require that you give it the --oldpackage option because of the version numbering. I guess we could bump the epoch but it would really be preferable if we could avoid that. John From jkeating at j2solutions.net Tue Dec 27 18:19:36 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 27 Dec 2005 10:19:36 -0800 Subject: Need discussion, Re: Latest contrib perl In-Reply-To: References: Message-ID: <1135707576.2880.1.camel@ender> On Tue, 2005-12-27 at 00:14 -0600, David Eisenstein wrote: > > Whatever we decide to do, your QA on upcoming binary packages will be most > warmly accepted. :) My opinion on the matter is that if we already have some QA work done on a bug (like we do in this case) we shouldn't interrupt the process to add more fixes to the bug, unless other problems are found during the QA process. If no QA has been done then it is easy to add the new fix to the sources. This is only my opinion, I welcome others. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From mic at npgx.com.au Tue Dec 27 21:43:52 2005 From: mic at npgx.com.au (Michael Mansour) Date: Wed, 28 Dec 2005 07:43:52 +1000 Subject: Need discussion, Re: Latest contrib perl In-Reply-To: <43B178F1.4000907@ysu.edu> References: <20051227170018.E98E473627@hormel.redhat.com> <43B178F1.4000907@ysu.edu> Message-ID: <20051227214235.M23103@npgx.com.au> Hi John, > Michael Mansour wrote: > > The perl versions I'm currently using on FC1 are from that directory: > > > > # rpm -q perl perl-suidperl > > perl-5.8.3-18.1.legacy > > perl-suidperl-5.8.3-18.1.legacy > > I built these versions for FC1; however, they are actually older > than the -17.3.legacy versions. I didn't realize at the time that > FC2 already had a -18 version. You should install the -17.3.legacy > versions for the latest FC1 update. RPM will require that you give > it the --oldpackage option because of the version numbering. I > guess we could bump the epoch but it would really be preferable if > we could avoid that. John Where do I pickup the -17.3.legacy versions from? looking here: http://www.fedoralegacy.org/contrib/perl/ I only see the perl-5.8.3-17.3.legacy.src.rpm file, but I need both the perl binary rpm and the perl-suidperl binary rpm. Michael. From nils at lemonbit.nl Tue Dec 27 23:06:39 2005 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Wed, 28 Dec 2005 00:06:39 +0100 Subject: Need discussion, Re: Latest contrib perl In-Reply-To: <20051227214235.M23103@npgx.com.au> References: <20051227170018.E98E473627@hormel.redhat.com> <43B178F1.4000907@ysu.edu> <20051227214235.M23103@npgx.com.au> Message-ID: <26FD7A9B-2562-4FBF-A8C5-86A40686CA9F@lemonbit.nl> Michael Mansour wrote: >>> The perl versions I'm currently using on FC1 are from that >>> directory: >>> >>> # rpm -q perl perl-suidperl >>> perl-5.8.3-18.1.legacy >>> perl-suidperl-5.8.3-18.1.legacy >> >> I built these versions for FC1; however, they are actually older >> than the -17.3.legacy versions. I didn't realize at the time that >> FC2 already had a -18 version. You should install the -17.3.legacy >> versions for the latest FC1 update. RPM will require that you give >> it the --oldpackage option because of the version numbering. I >> guess we could bump the epoch but it would really be preferable if >> we could avoid that. John > > Where do I pickup the -17.3.legacy versions from? looking here: > > http://www.fedoralegacy.org/contrib/perl/ > > I only see the perl-5.8.3-17.3.legacy.src.rpm file, but I need both > the perl > binary rpm and the perl-suidperl binary rpm. You can build both binary rpms from that source rpm. Nils. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From deisenst at gtw.net Wed Dec 28 01:58:13 2005 From: deisenst at gtw.net (David Eisenstein) Date: Tue, 27 Dec 2005 19:58:13 -0600 (CST) Subject: Need discussion, Re: Latest contrib perl In-Reply-To: <20051227214235.M23103@npgx.com.au> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 28 Dec 2005, Michael Mansour wrote: > Hi John, > > > Michael Mansour wrote: > > > The perl versions I'm currently using on FC1 are from that directory: > > > > > > # rpm -q perl perl-suidperl > > > perl-5.8.3-18.1.legacy > > > perl-suidperl-5.8.3-18.1.legacy > > > > I built these versions for FC1; however, they are actually older > > than the -17.3.legacy versions. I didn't realize at the time that > > FC2 already had a -18 version. You should install the -17.3.legacy > > versions for the latest FC1 update. RPM will require that you give > > it the --oldpackage option because of the version numbering. I > > guess we could bump the epoch but it would really be preferable if > > we could avoid that. John > > Where do I pickup the -17.3.legacy versions from? looking here: > > http://www.fedoralegacy.org/contrib/perl/ > > I only see the perl-5.8.3-17.3.legacy.src.rpm file, but I need both the perl > binary rpm and the perl-suidperl binary rpm. Michael, Okay. I just today have built binary rpms for FC1's perl on FL's build server. They are now up to version "perl-5.8.3-17.4.legacy". The changelog is below. I will post these to the fedoralegacy.org/contrib directory since you seem to need them, Michael. Just be aware that the perl-5.8.3-17.4.legacy packagers do not cover the CVE-2005-3962 "Integer overflow in the format string functionality...." vulnerability. SHA1SUM PACKAGE NAME 1cb9e9361e3834ff0ceba92a149ae04bb81bb9da perl-5.8.3-17.4.legacy.src.rpm 8cbc8bcf70441aec5ae9d5c56a550ac6fb6a328d perl-5.8.3-17.4.legacy.i386.rpm 0af21553a7c40aac057d1ca7400485199eb6adae perl-suidperl-5.8.3-17.4.legacy.i386.rpm Note that these are *not* signed, but these are probably going to be the packages that will be pushed to updates testing. No testing at all has been done on these binary packages, but the 5.8.3-17.3 packages that they come from has been running on my own FC1 machine for months now with nary a glitch. Also note that no new security patches have been added in this package since the one you've downloaded and installed (perl-5.8.3-18.1.legacy). But there is some code cleanup and a bug was fixed that affects CGI.pm. -David Changelog for perl-5.8.3-17.4.legacy: - ------------------------------------- * Tue Dec 27 2005 David Eisenstein 3:5.8.3-17.4.legacy - - Added BuildRequires: byacc, groff * Sun Sep 19 2005 David Eisenstein 3:5.8.3-17.3.legacy - - Remove patch1005: perl-5.8.3-cgi.pm.patch introduces a bug and is unnecessary. See bug # 152845 comment 9. * Tue Sep 13 2005 David Eisenstein 3:5.8.3-17.2.legacy - - Re-do version number for FC1 release so as not to conflict with FC2. - - Put whitespace back to make an easier compare with 5.8.3-16 - - Remove patch for CAN-2005-0077 since it patches perl-DBI package, not this one. * Thu Jul 14 2005 John Dalbec 3:5.8.3-18.1.legacy - - integrate fixes for CAN-2004-0452 CAN-2005-0077 CAN-2005-0155 CAN-2005-0156 CAN-2005-0448 and a CGI.pm DoS. * Thu Dec 9 2004 John Dalbec 3:5.8.3-17.1.legacy - - integrate tmpfile patch from OWL/solar designer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFDsfE6xou1V/j9XZwRAph9AJ9hb2Q8EEumVbI7iORzNS3Z+vmgrQCeKFli CYOY8hzFJg0BFA84lUetASs= =3WX+ -----END PGP SIGNATURE----- From mic at npgx.com.au Wed Dec 28 21:23:49 2005 From: mic at npgx.com.au (Michael Mansour) Date: Thu, 29 Dec 2005 07:23:49 +1000 Subject: Need discussion, Re: Latest contrib perl In-Reply-To: References: <20051227214235.M23103@npgx.com.au> Message-ID: <20051228211832.M86461@npgx.com.au> Hi David, > > Hi John, > > > > > Michael Mansour wrote: > > > > The perl versions I'm currently using on FC1 are from that directory: > > > > > > > > # rpm -q perl perl-suidperl > > > > perl-5.8.3-18.1.legacy > > > > perl-suidperl-5.8.3-18.1.legacy > > > > > > I built these versions for FC1; however, they are actually older > > > than the -17.3.legacy versions. I didn't realize at the time that > > > FC2 already had a -18 version. You should install the -17.3.legacy > > > versions for the latest FC1 update. RPM will require that you give > > > it the --oldpackage option because of the version numbering. I > > > guess we could bump the epoch but it would really be preferable if > > > we could avoid that. John > > > > Where do I pickup the -17.3.legacy versions from? looking here: > > > > http://www.fedoralegacy.org/contrib/perl/ > > > > I only see the perl-5.8.3-17.3.legacy.src.rpm file, but I need both the perl > > binary rpm and the perl-suidperl binary rpm. > > Michael, > > Okay. I just today have built binary rpms for FC1's perl on FL's build > server. They are now up to version "perl-5.8.3-17.4.legacy". The > changelog is below. I will post these to the > fedoralegacy.org/contrib directory since you seem to need them, > Michael. Just be aware that the perl-5.8.3-17.4.legacy packagers > do not cover the CVE-2005-3962 "Integer overflow in the format > string functionality...." vulnerability. Yes that's fine and many thanks for doing this. > SHA1SUM PACKAGE NAME > 1cb9e9361e3834ff0ceba92a149ae04bb81bb9da perl-5.8.3-17.4.legacy.src.rpm > > 8cbc8bcf70441aec5ae9d5c56a550ac6fb6a328d perl-5.8.3-17.4.legacy.i386.rpm > 0af21553a7c40aac057d1ca7400485199eb6adae perl-suidperl-5.8.3-17.4.legacy.i386.rpm > > Note that these are *not* signed, but these are probably going to be > the packages that will be pushed to updates testing. No testing at > all has been done on these binary packages, but the 5.8.3-17.3 > packages that they come from has been running on my own FC1 machine > for months now with nary a glitch. I implemented them on two test servers, and just applied the packages to one production server. So far so good. > Also note that no new security patches have been added in this > package since the one you've downloaded and installed (perl-5.8.3- > 18.1.legacy). But there is some code cleanup and a bug was fixed > that affects CGI.pm. Again, thanks for this David, I appreciate it. Michael. > -David > > Changelog for perl-5.8.3-17.4.legacy: > - ------------------------------------- > > * Tue Dec 27 2005 David Eisenstein 3:5.8.3-17.4.legacy > - - Added BuildRequires: byacc, groff > > * Sun Sep 19 2005 David Eisenstein 3:5.8.3-17.3.legacy > - - Remove patch1005: perl-5.8.3-cgi.pm.patch introduces a bug and is > unnecessary. See bug # 152845 comment 9. > > * Tue Sep 13 2005 David Eisenstein 3:5.8.3-17.2.legacy > - - Re-do version number for FC1 release so as not to conflict with FC2. > - - Put whitespace back to make an easier compare with 5.8.3-16 > - - Remove patch for CAN-2005-0077 since it patches perl-DBI package, > not this one. > > * Thu Jul 14 2005 John Dalbec 3:5.8.3-18.1.legacy > - - integrate fixes for CAN-2004-0452 CAN-2005-0077 CAN-2005-0155 > CAN-2005-0156 CAN-2005-0448 and a CGI.pm DoS. > > * Thu Dec 9 2004 John Dalbec 3:5.8.3-17.1.legacy > - - integrate tmpfile patch from OWL/solar designer > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.3 (GNU/Linux) > > iD8DBQFDsfE6xou1V/j9XZwRAph9AJ9hb2Q8EEumVbI7iORzNS3Z+vmgrQCeKFli > CYOY8hzFJg0BFA84lUetASs= > =3WX+ > -----END PGP SIGNATURE----- > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list ------- End of Original Message ------- From deisenst at gtw.net Thu Dec 29 02:12:16 2005 From: deisenst at gtw.net (David Eisenstein) Date: Wed, 28 Dec 2005 20:12:16 -0600 (CST) Subject: Our wiki documentation Message-ID: Hi, I have just updated the "Help Wanted" page on the Fedora Wiki to reflect Legacy's need for volunteers. Have a look & please respond to this message if you have any thoughts or comments. . IRC's (Red Hat's Rahul Sundaram) had these addition comments of needs for documentation. Any takers? Questor, would be nice if you can get the FAQ into the wiki or add information on architecture and extras support to the FAQ Questor, also information on lifecycle with a table on when stuff gets releases, when its moved into legacy and when legacy stops support in that page would be useful Questor, http://fedoraproject.org/wiki/LifeCycle In the FAQ page you mean? Questor, right the legacy FAQ page also there should be a document on why users use legacy and how to contribute somewhere and preferrably in downloadable form for redistribution perhaps better information on choosing to stay with legacy/ moving to the next release Warm regards, David on Freenode IRC.