Re: RHEL subset of which FC ?
On Thu, Jan 18, 2007 at 11:11:29AM +0100, P. Martinez wrote: Am 18.01.2007 um 02:19 schrieb Stephen John Smoogen: If you are looking at one could attempt an upgrade from to then it would be that RHL-7.0, RHL-7.1, RHL-7.2 might be upgraded to RHEL-2.1 RHL-7.3, RHL-8, RHL-9 might be upgraded to RHEL-3 FCL-1, FCL-2, FCL-3 might be upgraded to RHEL-4 FCL-4, FCL-5, FCL-6 might be upgraded to RHEL-5 There could be individual circumstances but I upgraded two heavily hacked RHL-7.x machines to CentOS-4, which is from a software point of view really the same as RHEL-4, and this was a non-event. True, it required some coaxing to start the whole process and a careful cleanup afterwards (both 'yum-utils' and 'rpm' are helpful in that) but other than that, which means an extra work, this was not a problem. If you did not dump everything into one big partition in the first place then installing over system parts, while keeping local data, and restoring a desired configuration afterwards could be simpler and quicker. Selectively restoring from backups also can be an option. Make no mistake - a machine in use for a while is likely more customized then it looks at the first glance so getting to an equivalent configuration on a new installation is usually quite a bit more work than you think. Still with a bit of planning you may end up ahead. Till now, there is no decision about our current OS-strategies. Thinking in terms what can be, apparently, upgraded to what is possibly not that great idea. Michal -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: where? security updates for FC4
On Wed, Jan 03, 2007 at 04:44:56PM -0800, Florin Andrei wrote: Michal Jaegermann wrote: Version of what? RHEL or CentOS. Since they are really the same, you know. ;-) What you are interested in differs only by identifier strings in release parts. CentOS on purpose _precisely_ tracks RHEL only removing and/or replacing things like artworks, identifiers, etc. in order not to violate copyrights or create false impressions. As you can guess there are delays, ranging from few hours to few days, before CentOS equivalents of RHEL updates are showing on mirrors. I was merely asking for common sense suggestions. I do not expect anything to happen as if by magic. So you got, I hope, what you asked for. OTOH it is definitely easier to maintain some specific machines than a whole distro. You do have much more leeway. Patching sources of packages you are using is the safest and the most correct course of action. Still it happens then the only sane thing to do is to upgrade a version of something. Michal -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: where? security updates for FC4
On Thu, Jan 04, 2007 at 03:04:48AM +, Karanbir Singh wrote: Nils Breunese (Lemonbit) wrote: At release time, FC5 would have older packages than FC6 at release time, but FC5 has since seen updates etc. Eg. fc5 release firefox : firefox-1.5.0.1-9 fc5 latest firefox : firefox-1.5.0.9-1.fc5 centos-5beta firefox : firefox-1.5.0.8-1.el5.centos In this particular case this happens to be no problem. 1.5.0.9 is a security fix and firefox-1.5.0.9-0.1.el4.centos4 is in CentOS 4 updates now so whatever will eventually show up will be not lower. Besides I have seen an anoucement, even if I cannot find it currently, that support for firefox-1.5 series will end in not so distant future (April?) and backpatching those browsers is really hard and does not really buy much beyond headaches. In other words you can expect newer versions of Firefox soon. OTOH FC5 still has mozilla with known security issues ( https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195318 ) so maybe I am too optimistic here. Michal -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Upgrading FC releases via yum
On Wed, Nov 15, 2006 at 11:30:27AM -0600, Kirk Pickering wrote: Has anyone on this list tried the following method? http://www.makuchaku.info/blog/how-to-upgrade-from-fc4-to-fc5-via-yum You can do that but how easy/straightforward that be depends very much on what you got installed on a box and from where. I did something of that sort bringing a box from FC3 to FC5, and I finished with a working and correctly upgraded system; but this required some careful thinking and planning of stages, and in some moments the system was obviously broken but enough was working to make the progress possible. With a bad move somewhere you may get stuck. Not for a general public or faint in the heart. Looks to me that this is in if you have to read instructions how to do that you better not try this at home category. Sure, sometimes it will work even if you will just follow instructions. Michal -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Need SeaMonkey opinions - [Fwd: [RHSA-2006:0734-01] Critical: seamonkey security update]
On Wed, Nov 08, 2006 at 02:34:30PM -0500, Christopher Aillon wrote: David Eisenstein wrote: I favor SeaMonkey as a Mozilla replacement, as it covers all vulnerabilities in packages that dynamically link to the shared libraries. But perhaps there are other ideas. I see no reason that it won't work for Fedora given that it works for RHEL. I can probably offer some guidance as there were many hurdles that I had to overcome when building these packages for RHEL, though I probably don't remember them all off the top of my head. Thanks Chris! A while ago I basically stole your package from RHEL sources and redid it for FC4. It really should be basically the same thing for earlier distributions. An URL for source rpm was posted on this list and a number of people is aware of it. :-) Right now it needs an update, of course, but this should be straightforward. As a matter of fact I got impatient waiting for a resolution of https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195318 and did a similar thing for FC5 too. That one has bigger differences because it is using external packages for nss and nspr (and some other minor things). Michal -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora-legacy open bugs; following them c
On Sat, Oct 21, 2006 at 04:29:15AM -0500, David Eisenstein wrote: * Other bugs needing some attention: ... - openssh (bug 208727). Originally opened to deal with FC3, FC4, RHL 7.3 RHL 9 releases. A comment #2, put there by David Eisenstein, :-) in bug 208727 mentions ftp://ftp.harddata.com/pub/Legacy_srpms/openssh-4.2p1-fc4.10.1mj.src.rpm Lifting fixes from RHEL packages and applying to other distribution sources does not look here like a very big deal. In general whatever is available in Legacy_srpms is surely in worksforme state and in an actual use. OTOH FC4 machines around me most likely pretty soon will be moved to FC6. Michal -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: lwn article on the death of Fedora Legacy
On Fri, Oct 20, 2006 at 01:19:08PM -0400, Gene Heskett wrote: My email archive alone goes back into 1998 here. Yes, there are backups, and I do them rather religiously at the feet of a gal named amanda, but it would still be a weeks work to get stuff back to the Just Works(TM) state here if I was to put FC5 on this box today. Eh? How come? Not that I am trying to tell you upgrade right now but I have around machines which went through numerous release upgrades, some with original installations dating back to times of RH6.x realeases or maybe even earlier, and it never took me weeks to do such thing. Rather small hours when most of the time I was doing something else when a machine was busy installing updated packages. I am not trying to imply that there is no work involved. It is easier when you can do that over a network or from DVD, or otherwise you have to babysit a machine and switch CDs from time to time, but I never had a situation that such operation destroyed my data or made a machine inoperable. It is also true that after such step there is some cleanup to perform; but with possible small exceptions this is not extremely urgent and can be done here and there at your leisure. 'rpm -qa --last' will make you a list where possible leftovers are easy to pick up and you should go through assorted '.rpmnew' and '.rpmsave' files. 'locate' is of a great help here after you updated its database. On some occasions I did even such nasty things as 'rpm -Uvh --nodeps fedora-release*', with that rpm from a target distro, followed by 'yum update yum* rpm* python*' and after that 'yum update ...' (various things as needed), but such trickery may require assorted manual interventions which depend on what you really have already installed and falls into if you have to ask how to do that you should not be doing it category. Still it worked fine in the final account (with a different set of tradeoffs than a normal update). Yes, I know that some claim that to upgrade a release one should do an install from scratch and restore personal data from backups. Unless you really messed up previously your installation doing things like 'rpm --Uvh --nodeps ...' all over the place, and other nasties of that sort, this is misguided. But after an extended rattlesnake sorting session on my lappy, FC5 is now looking working pretty good, so FC6 will probably get installed when its out or shortly after. But I'm not about to do this every 6 months as planned by the FC people, I have other things these machines need to do, and do on a set it up in cron so I can forget about it scenario. My $0.02, adjust for inflation. :-) C) etc -- 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) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Mailman vulnerability
On Thu, Oct 05, 2006 at 09:19:48AM -0300, Martin Marques wrote: I have a FC4 web server installed and got this mailman report: http://www.securityfocus.com/bid/19831/discuss Is it to worry? Probably. See also http://rhn.redhat.com/errata/RHSA-2006-0600.html FC4 is using mailman-2.1.5-35 so fixes in sources used by RHEL4, as specified by RHSA-2006-0600, will likely apply directly or after minimal modifications. You can produce your own update before something general eventually will show up. Add patches, edit specs and rebuild rpm. Michal -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: openssl updates
On Sat, Sep 30, 2006 at 10:48:32PM -0700, Florin Andrei wrote: On Sat, 2006-09-30 at 22:50 -0600, Michal Jaegermann wrote: If you have already installed both (multilib situation) then you have to do both updates in one transaction. The i686 package is already installed (although I don't think anything is actually using it). If I try to remove it, that's rejected based on a list of dependencies longer than my arm. That would mean that something is using it. :-) Possibly in an indirect way. If I try to build an i686 package on the x86_64 system I get: # rpmbuild --rebuild --target=i686 openssl-0.9.7f-7.10.3mj.src.rpm [snip] /usr/bin/ld: warning: i386 architecture of input file `libcrypto.a(krb5_asn.o)' is incompatible with i386:x86-64 output Building i686 on x86_64 is a bit more involved than that. Jeff already mentioned 'mock'. If you have an access to a suitable 86 installation rebuilding there those missing packages may be a simpler option. Michal -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: openssl updates
On Sat, Sep 30, 2006 at 08:16:09PM -0700, Florin Andrei wrote: On Sat, 2006-09-30 at 13:13 -0600, Michal Jaegermann wrote: Is there any bugzilla report for that? I don't know. All right. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208744 M. -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: openssl updates
On Sat, Sep 30, 2006 at 08:16:09PM -0700, Florin Andrei wrote:
Actually, I was able to rebuild the src.rpm from that location on a FC4
system, but I had issues when trying to install the binary due to
conflicts between 32 bit and 64 bit OpenSSL packages (it's an AMD64
machine).
You cannot update an i386 (or compatible arch like i686) package
with x86_64 package or vice-versa. If you have already installed
both (multilib situation) then you have to do both updates in
one transaction. Something like
rpm -Fvh openssl*{686,x86_64}.rpm
Otherwise you will get conflicts. You can use also 'localinstall'
request in yum with something like the above but then use a
configuration which turns of gpgcheck for packages not signed with
any of installed keys.
The easiest way to check architectures of already installed
packages will be with something like
grep openssl /var/log/rpmpkgs
as /etc/cron.daily/rpm script, which writes that log, is already
using a format with an %{arch} tag in it.
It's probably trivial to work around, but I've little
experience with x86_64 distributions.
See above.
You mean on line 185 in a patched crypto/dh/dh_key.c? Looking at
this code you are definitely right.
So, if your packages include the bug, could you post a fixed version
please?
I already did. If you see openssl-0.9.7f-7.10.3mj.src.rpm then
this has that change (which is easy to check in %changelog).
Is there any bugzilla report for that?
I don't know.
Ok then, does Tomas Mraz is aware about the issue? :-)
Michal
--
fedora-legacy-list mailing list
fedora-legacy-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-list
updated srpms for firefox and seamonkey (mozilla)
With the current updates I replaced older packages with ftp://ftp.harddata.com/pub/Legacy_srpms/seamonkey-1.0.5-0.4.fc4.0.mj.src.rpm ftp://ftp.harddata.com/pub/Legacy_srpms/firefox-1.5.0.7-1.fc4.0.mj.src.rpm which I used to recompile browser for FC4 systems. These packages likely fit older installations too but I did not try. Have a shot at the above if you would rather run something with recent security patches against remote attacks than official. Once again - the seamonkey package above is configured to _replace_ old mozilla and not to be installed side-by-side (like what you can find in extras). This means that all packages which depend on 'mozilla' or its subpackages, starting with yelp, need to be recompiled too as some library locations change. This is purely mechanical and does not need any configuration modifications; required /usr/lib/pkgconfig/mozilla*.pc files are supplied by 'seamonkey-devel' and there are corresponding 'mozilla' provides. The same way like in similar packages from RHEL. The easiest way to check what on your system needs new binaries is, after seamonkey packages were installed, to type: yum remove 'semonkey*' respond no and see what were other candidates for a removal. If the above srpms were used as starting points for Legacy releases I would be only happy. Michal -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
ImageMagick and FC4
Source rpm for FC4 version of ImageMagick with recent security patches added is available at ftp://ftp.harddata.com/pub/Legacy_srpms/ImageMagick-6.2.2.0-3.fc4.2.1.mj.src.rpm This was a simple case as patches, extracted from FC5 updates, were for 6.2.2 in the first place. :-) Michal -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
mozilla (seamonkey) and firefox for FC4
For those interested in further checking, maybe cleanup and development there are available ftp://ftp.harddata.com/pub/Legacy_srpms/seamonkey-1.0.4-0.4.2.fc4.0.mj.src.rpm ftp://ftp.harddata.com/pub/Legacy_srpms/firefox-1.5.0.6-2.fc4.0.mj.src.rpm This is replace mozilla as in RHEL model seamonkey which provides 'mozilla' executable and corresponding libraries with dependencies, as opposed to what you can find in 'extras' which can be installed in parallel to now obsoleted mozilla packages. A spec file is sort of a cross of a spec from RHEL and extra packages and older mozilla. Firefox was derived from firefox-1.5.0.6-2.fc5 update by dropping pieces which do not fit FC4 (cairo, system nss and nspr and corresponding changes in firefox-mozconfig). Only after I recompiled all that stuff I realized that stripping is explicitely disabled in configuration options and most likely is really done while 'debuginfo' packages are created. So I ended with tons of '.so' libraries unstripped and resulting binary packages are somewhat fat as I turned off for a time beeing this 'debuginfo'. Moral - don't do that. :-) Also recompilation takes quite a bit of time and a disk space. Just compilation messages amount to something of an order of 5.5 Megs in each case. Anyway - so far results work for me just fine where I had a chance to try and have fixes for these long lists of security problems. Michal -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora products, to upgrade rather than backport?
On Mon, May 15, 2006 at 02:29:03PM -0500, Eric Rostetter wrote: Depends on what transparent means. If you want to be transparent in the sense of not breaking people's working machines, then no, you should backport. When people intimately familiar with a given code, because they authored it, do not even attempt to provide security patches for older versions as internals were completely re-written and it is not even clear how to patch old holes, you expect that a small group of volunteers will do a deep analysis and come quickly with correct and safe patches for whatever? Such request is not even funny. In case you wonder the above was exactly the case with relatively recent updates to sendmail and is normally the case with mozilla (try to peek into that code and you will see why). What is more such leaf applications, as opposed to deeply intertwined libraries, are not a real problem - packaging hiccups notwithstanding. On one occasion I was replacing sendmail with a current version on a system with a provenience susbtantially earlier than whatever is supported by Legacy. It was not an issue. True, compile options had to be adjusted to what was available and a symlink or two was needed, and one had to be mildly careful with a configuration, but no real show stoppers. Not mentioning, of course, that if you know proven patches to old versions then you should not sit on that information. Michal -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: New sendmail and missing /usr/lib/sendmail
On Sat, Mar 25, 2006 at 10:24:12AM -0500, David Eisner wrote: Eric Rostetter wrote: This sounds like what happens when we rush the QA processes... Other distros had advance warning about this vulnerability, and hence more time to apply patches and do testing. Personally I _hugely_ prefer fixed packages with minor packaging imperfections, which BTW can be trivially fixed by whomever is installing them by adding a link or two, then waiting for something which installs without a hitch and have a mail server owned in the meantime. Headaches in both cases do not even start to compare. I think that everybody should send Jesse big thanks for preparing new packages on such short notice. New-and-improved, which create all needed links automatically on an installation, can be issued later. Of course it would help if people experiencing problems would try to identify what went wrong (older 'alternatives' do not work like they should?, some typos in %post scripts?, something else?). Again, look at what 'rpm -q --scripts sendmail' reports and check is something is amiss there, as the first step, if you have seen troubles. Michal -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora Legacy Update : kdelibs dependency problems
On Wed, Mar 22, 2006 at 06:54:03PM +, A E Lawrence wrote: Synopsis: Updated kdelibs packages fix security issues Advisory ID: FLSA:178606 download.fedoralegacy.org/fedora/3/updates/x86_64/kdelibs-3.4.2-1.fc3.1.legacy.x86_64.rpm Trying to update (yum) the kdelibs and kdelibs-devel rpms fails on a AMD64 FC3 legacy system because all the other kde packages appear to require kdebase-3.3.1-4.3.FC3. There is something not kosher with your system as in August 2005 there was an FC3 update of various things KDE and this included kdelibs-3.4.2-0.fc3.2; on x86_64 too. I suspect that I can force the upgrade without breaking anything by a manual rpm -Fhv --nodeps ..., Don't do that. Quite likely something will break. I guess that you should first run all available updates from pre-legacy servers and only after that apply what was provided later. There is an assumption here that all earlier updates were already applied. Michal -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: US-CERT Technical Cyber Security Alert TA06-081A -- Sendmail Race Condition Vulnerability (fwd)
On Wed, Mar 22, 2006 at 10:29:27AM -0800, Kenneth Porter wrote: For those of us accepting mail from outside on pre-FC4 Fedora, are any updates in the pipe to address this? I should add that in sendmail.org annoucement, http://lwn.net/Articles/176595/, there is the following: However, note that those patches may not (cleanly) apply to versions other than 8.13.5 and 8.12.11, respectively. There are no patches for versions before 8.12 because those outdated versions use a different I/O layer and hence it would require a major effort to rewrite that layer. So, it is clear that those with older distros will have to do, if required, a sendmail version bump. If Sendmail, Inc. is refusing to patch that back then surely I am not going to try. I think that this seriously affects only RH7.3 but it is possible to reuse there sendmail-8.12.11-4.RHEL3.4 - likely with configuration changes in a spec file. Michal -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Latest squirrelmail for Fedora Core 1, 2, 3
On Fri, Mar 03, 2006 at 08:51:05PM -0500, Paul wrote: Anyhow, I have verified the latest squirrelmail 1.4.5-1 fixes this bug. The latest one is squirrelmail-1.4.6-1. Well, for FC4 but it will recompile anyway and it is fixing security issues. Is the above a typo? Michal -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Latest squirrelmail for Fedora Core 1, 2, 3
On Fri, Mar 03, 2006 at 09:51:25PM -0500, Paul wrote: On Fri, March 3, 2006 9:21 pm, Michal Jaegermann wrote: On Fri, Mar 03, 2006 at 08:51:05PM -0500, Paul wrote: Anyhow, I have verified the latest squirrelmail 1.4.5-1 fixes this bug. The latest one is squirrelmail-1.4.6-1. Well, for FC4 but it will recompile anyway and it is fixing security issues. Is the above a typo? No typo. I assume 1.4.5-1 fixes security bugs in 1.4.5 for Core 1,2,3. No, it does not. This is from a changelog: * Wed Mar 01 2006 David Woodhouse [EMAIL PROTECTED] 1.4.6-1 - Upgrade to 1.4.6 proper for CVE-2006-0377 CVE-2006-0195 CVE-2006-0188 Note 2006. New security problems were revealed in the meantime. Now, this is for legacy. Does not help unless you backport security fixes and I am not even going to try with PHP. Michal -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora Legacy Test Update Notification: gpdf
On Mon, Feb 20, 2006 at 07:58:41PM -0500, Marc Deslauriers wrote: - Fedora Legacy Test Update Notification FEDORALEGACY-2006-176751 fedora/3/updates-testing/i386/gpdf-2.8.2-7.2.1.legacy.i386.rpm At least this package is unsigned so yum, in a default configuration from legacy-yumconf-3-4.fc3 plus enabled 'legacy-testing', will not install that. sha1sum agrees with what was posted, though. Michal -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: PHP IMAP segfault
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 -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: PHP Attacks....
On Wed, Nov 09, 2005 at 02:12:45PM -0500, Josep L. Guallar-Esteve wrote: On Wednesday 09 November 2005 14:02, Matthew Nuzum wrote: Which worm is this that you're guarding against? I haven't heard of a new worm yet. http://www.securityfocus.com/bid/14088/info .. If I understand correctly that is really an XML_RPC vulnerability in pear libraries; so if you do not have such capability, or it is not turned on, then you are not vulnerable. Of course there are some applications which require that. Do I miss something? Michal -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: PHP Attacks....
On Wed, Nov 09, 2005 at 11:22:28AM -0800, Jesse Keating wrote: On Wed, 2005-11-09 at 14:12 -0500, Josep L. Guallar-Esteve wrote: http://www.securityfocus.com/bid/14088/info http://vil.nai.com/vil/content/v_136821.htm http://news.zdnet.com/2100-1009_22-5938475.html http://www.eweek.com/article2/0,1759,1882889,00.asp?kc=EWRSS03129TX1K616 http://news.com.com/New+worm+targets+Linuxsystems/2100-7349_3-5938475.html?part=rsstag=5938475subj=news http://linux.slashdot.org/article.pl?sid=05/11/08/140203tid=220tid=106 Does look like we need to patch this. RHEL issued an update, Do you mean that one from August? https://rhn.redhat.com/errata/RHSA-2005-748.html CAN ids between that one and http://www.securityfocus.com/bid/14088/info do not agree although the latest worm descriptions would suggest that RHSA-2005:748-05 is the correct one. Michal -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: PHP Attacks....
On Wed, Nov 09, 2005 at 04:19:35PM -0500, James Kosin wrote: On Wed, Nov 09, 2005 at 11:22:28AM -0800, Jesse Keating wrote: Does look like we need to patch this. RHEL issued an update, Do you mean that one from August? https://rhn.redhat.com/errata/RHSA-2005-748.html CAN ids between that one and http://www.securityfocus.com/bid/14088/info do not agree although the latest worm descriptions would suggest that RHSA-2005:748-05 is the correct one. Michal -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list The CVE website states that CAN-2005-2498 is not the same as CAN-2005-1921; so, I think to reason; both need to be fixed if we are vulnerable. Indeed. But sources referenced in RHSA-2005:564-15, where CAN-2005-1751 and CAN-2005-1921 are mentioned, are explicitely marked as outdated by RHSA-2005:748-05 (CAN-2005-2498) so the latest presumably have fixes for all these. Source packages are somewhat different for RHEL3 and RHEL4 so you possibly need a right fit for FC1 and FC2. In my earlier remarks I meant that it does not look that any fix is needed for RH7.3; simply because the code with problems is not there. Yesterday updates for FC3 include also php-4.3.11-2.8.src.rpm (and php-5.0.4-10.5.src.rpm for FC4). Michal -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: PHP Attacks....
On Wed, Nov 09, 2005 at 05:04:27PM -0500, James Kosin wrote: They also address CVE-2005-3353, CVE-2005-3388, CVE-2005-3389 and CVE-2005-3390... do we need to concern ourselves with these? Do you plan to wait until attacks will show up? Michal -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: dependency hell, version 2,197,386.1
On Wed, Oct 26, 2005 at 10:01:08AM -0400, Gene Heskett wrote: On Wednesday 26 October 2005 08:47, seth vidal wrote: when yum updates kernels it does not remove the older kernels. So there's no danger in yum installing the kernel for you. -sv Yes Seth, but it does tend to scrap the currently valid stuff in ones grub.conf, For a very long time I did not see an installation procedure to mess with my extra boot entries; it adds just new ones. In any case there is a very simple way to protect yourself. Edit your /etc/grub.conf with non-standard titles. That should be enough to sufficiently confuse an automatic editing so it will leave all of that configuration alone. Of course then it is up to you to fix things up after every change in boot images. and I'd rather do my own editing of grub.conf. Your choice; but if you prefer a manual installation labor then learn how to do it completely and resolve dependencies and override checks, where this makes sense, manually too. It is easier to mess up that way but it is doable. Still this leaves you without a valid complaint that some things are unhappy. I would think that a better way to achieve you goals would be to keep a copy of your current grub.conf, install, restore the previous version of grub.conf from that copy and edit results to your taste. Michal -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Upcoming transition of FC3
On Mon, Oct 24, 2005 at 11:26:41AM -0500, Eric Rostetter wrote: That said, I'd still vote for shipping it disabled... With what I have seen in the field I would rather have that enabled. People who care about such things can disable that easily enough. The problem is with those who expect that things will happen automagically. You can make the corresponding package to spit on stdout prominent warnings from a %post script; that does not matter in which state things will be eventually shipped. Michal -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora Legacy Test Update Notification: httpd and mod_ssl
On Mon, Oct 24, 2005 at 06:26:03PM -0400, Jim Popovitch wrote: I've got a few questions about this release of mod_ssl. 1) why is it bundled w/ httpd v2.0 and not a separate bug? Actually it exists a separate bug report: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168420 but it was closed with a reference to 166941 in order to track everything together. The subject for 166941 is indeed somewhat confusing in the context. 2) does anything in this apply to apache v1.3? Yes but indirectly. These are two different packages there. 3) why was it never tracked in Pekka's issues list? If you would look at that list a bit closer you would find the information above rather quickly. 4) why am I the only one inquiring about this. :-) Dunno. Others checked before asking? Michal -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Upcoming transition of FC3
On Fri, Oct 21, 2005 at 11:49:14AM -0400, Jeff Sheltren wrote: By the way, where to store the GPG key on FC3? I think /etc/pki wasn't brought around until FC4, so I am thinking that /usr/share/doc/ fedora-legacy/ would be a good place for it. If you want to store keys on a disk then I do not see what is wrong with /etc/pki. You can always create such location and I do not see a particular need to introduce spurious differences between distributions. Of course an URL to the key could be also in http://... , or some other protocol, form. You need to retrieve it only once and rpm from FC3 will import it. Michal -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Upcoming transition of FC3
On Fri, Oct 21, 2005 at 12:26:34PM -0400, Jeff Sheltren wrote: On Oct 21, 2005, at 12:08 PM, Michal Jaegermann wrote: Of course an URL to the key could be also in http://... , or some other protocol, form. You need to retrieve it only once and rpm from FC3 will import it. Yeah, that is also a good idea, but I couldn't remember if the FC3 version of yum supported the URL syntax... Yes, it does. I am not sure if there was actually a version of yum which did not but I did not see them all. Michal -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fwd: Re: releasing updates-testing packages without VERIFY votes
On Tue, Sep 27, 2005 at 10:36:46AM -0700, Benjamin Smith wrote: On Friday 23 September 2005 10:03, William Stockall wrote: I concur with Mr. McCarty. If untested updates are moved in with the tested updates then NONE of the updates can be trusted. ... What if a repo is set up just for these timed out packages, and if somebody wants to use them, they can set their yum.conf to include this semi-trusted repository? It seems to me that this is a terrible idea. Things are already quite fragmented in the context and that would create even further fragmentation and administrative headaches which someone would have to suffer. Besides I do not get it. There is a clamour for tested and verified packages but who is supposed to do that? Waiting for others does not help. If I am putting in a bug report a note that it is easy to recompile a package from updates to some other distribution, or give a reference to what I believe is a fixed package which I put together myself, then you can be sure that it works for me and is in an actual use. Beyond that I cannot tell very much on my own. Personally I think that if a release early, release often principle would be applied to Legacy releases too, with a quick re-release to follow for an occasional dud (which happened anyway), we would be much further in the whole project. This seems to be a minority opinion. As things are people are instead running for months with known security holes. Sure, if such box is heavily firewalled, and you are not ever using on it things like a web browser, then you may not care but this is not always the case. Oh, well ... I will probably get out of 7.3 business pretty soon anyway. Michal -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: [Fwd: [SECURITY] [DSA 817-1] New python2.2 packages fix arbitrary code execution]
On Sat, Sep 24, 2005 at 10:23:00AM -0400, Jim Popovitch wrote: Michal Jaegermann wrote: It is hard to imagine that somebody quietly fixed such hole in Python packages for Red Hat distributions and did not mention that anybody. Wouldn't this count: http://rhn.redhat.com/errata/RHSA-2005-761.html Count to what? That above is a bug in pcre itself and https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168516 is a corresponding bugzilla entry for Legacy packages. You were talking about the same bug showing up, unfortunately, in a different context. What David Eisenstein posted (thanks!) gives a lot of relevant cross-referrences. All that info should show up eventually in a Legacy bugzilla report. Michal -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: [Fwd: [SECURITY] [DSA 817-1] New python2.2 packages fix arbitrary code execution]
On Sat, Sep 24, 2005 at 03:15:15PM -0400, Jim Popovitch wrote: Michal Jaegermann wrote: On Sat, Sep 24, 2005 at 10:23:00AM -0400, Jim Popovitch wrote: Michal Jaegermann wrote: It is hard to imagine that somebody quietly fixed such hole in Python packages for Red Hat distributions and did not mention that anybody. Wouldn't this count: http://rhn.redhat.com/errata/RHSA-2005-761.html Count to what? Count towards showing that RH had indeed released fixes. Isn't that what you were stating above, that you hadn't seen any releases for RH yet? Sigh! The above is about pcre itself and we are talking here about a code embedded in Python. Unfortunately this is an independet, although related, issue. There are now bugzilla numbers for that (#166335 and #168318) but AFAICS no releases so far. Would you like, please, to write a corresponding bugzilla entry for Legacy packages or we should ask David for that? It appears that he already collected all data. Michal -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: [Fwd: [SECURITY] [DSA 817-1] New python2.2 packages fix arbitrary code execution]
On Thu, Sep 22, 2005 at 09:15:23AM -0400, Jim Popovitch wrote: Anyone know if this impacts FL? [ a description of Pyton problems from Debian advisory skipped ] Most likely this is the case. It is hard to imagine that somebody quietly fixed such hole in Python packages for Red Hat distributions and did not mention that anybody. Well, a pcre code could be possibly not compiled in but I am not sure if this is an option. If this is used as a shared library then fixing that in one place would fix all users but a quick look at some samples seems to show that this is not the case. OTOH I do not know in this moment if python-1.5, like the one used in RH7.3, has a code from pcre or not. If it does then the problem potentially is not limited to python2. I did a quick BugTraq look at Pekka's lists and didn't see it mentioned. Well, you could be the one who will add that to bugzilla. Of course if you would look first at patches Debian used, and also other pcre patches, and check before writing a bugzilla entry if they indeed apply that would be a truly good move. Michal -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: YUM Update of MOZILLA with FC2: Problem
On Tue, Sep 20, 2005 at 11:11:21AM -0500, Mike McCarty wrote:
$ rpm -V mozilla
missing/usr/lib/mozilla-1.7.10/chrome/overlayinfo/browser
missing/usr/lib/mozilla-1.7.10/chrome/overlayinfo/browser/content
missing/usr/lib/mozilla-1.7.10/chrome/overlayinfo/browser/skin
missing/usr/lib/mozilla-1.7.10/chrome/overlayinfo/cookie
missing/usr/lib/mozilla-1.7.10/chrome/overlayinfo/cookie/content
missing/usr/lib/mozilla-1.7.10/chrome/overlayinfo/editor
missing/usr/lib/mozilla-1.7.10/chrome/overlayinfo/editor/content
missing/usr/lib/mozilla-1.7.10/chrome/overlayinfo/global
missing/usr/lib/mozilla-1.7.10/chrome/overlayinfo/global/content
missing/usr/lib/mozilla-1.7.10/chrome/overlayinfo/global/skin
These directories (and they are all directories) are removed by %post.
Like this:
if [ -f /usr/lib/mozilla-1.7.10/mozilla-rebuild-databases.pl ]; then
/usr/lib/mozilla-1.7.10/mozilla-rebuild-databases.pl
fi
and
if ( -f /usr/lib/mozilla-1.7.10/regxpcom )
{
# remove all of the old files
rmtree(/usr/lib/mozilla-1.7.10/chrome/overlayinfo);
unlink /usr/lib/mozilla-1.7.10/chrome/*.rdf;
unlink(/usr/lib/mozilla-1.7.10/component.reg);
unlink(/usr/lib/mozilla-1.7.10/components/compreg.dat);
unlink(/usr/lib/mozilla-1.7.10/components/xpti.dat);
.
Nasty, but what we can do? Maybe they can be marked in specs as
'%ghost %config(missingok) ...' but I am not sure if this works on
directories.
Should I try a
# yum remove mozilla
# yum install mozilla
# yum update
The above shows that this will not help, at least with those
missing, and it is not a source of your problems. OTOH if
something went funny during an installation (multiple instances
locking itself out and so on) then maybe rerunning
/usr/lib/mozilla-1.7.10/mozilla-rebuild-databases.pl will resolve
the issues?
Michal
--
fedora-legacy-list mailing list
fedora-legacy-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-list
