Re: You Need Fedora Legacy!! Re: [fab] looking at our surrent state a bit
Eric Rostetter wrote: Quoting Axel Thimm [EMAIL PROTECTED]: The issue is also not the infrstructure IMO, it's simply lack of human resources and either someone needs to assign them to it if that entity (Red Hat/board/whatever) considers that a worthy goal, or the resources need to come from more voluntary people, e.g. FL needs a marketing manager. I think it is both Infrastructure and lack of humans, plus stupid barriers that shouldn't exist. The learning curve is high, people look down at volunteers just because they don't/won't/can't use some technology (e.g. IRC), and there is little effort expended to get people to participate (though much flaming people for not participating). I, for one, appreciate the hard work that you do, Eric. What do you suggest as an alternative for IRC for folks who are not able or interested in using it? Warm regards, David Eisenstein -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Mailman vulnerability
On Thu, 5 Oct 2006, Michal Jaegermann wrote: 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. Sorry for the delay. I'm working on this right now. But I found that patches for RHEL are for mailman 2.1.5 and we are on 2.1.8, making patches fail. So I'm trying to build new patches based on the RHEL ones. Would you people like to see the patches first or do I send the src.rpm? -- 21:50:04 up 2 days, 9:07, 0 users, load average: 0.92, 0.37, 0.18 - Lic. Martín Marqués | SELECT 'mmarques' || Centro de Telemática| '@' || 'unl.edu.ar'; Universidad Nacional| DBA, Programador, del Litoral | Administrador --- 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 Wednesday 08 November 2006 05:43, David Eisenstein wrote: What say ye?? I'd say go with seamonkey. RHEL is showing us a good example. The mozilla codebase is dead and has been resurrected as seamonkey, so unless we want to generate our own patches (shudder) I'd highly recommend we take the RHEL route and replace mozilla with seamonkey. -- Jesse Keating Release Engineer: Fedora pgp1TMIcqk7pj.pgp Description: PGP signature -- 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 04:43:24AM -0600, David Eisenstein wrote: Does anyone have any comments on how you wish the Legacy Project to approach this? 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 think this is the only reasonable choice. Backporting all of the fixes would be herculean -- for very little gain. -- Matthew Miller [EMAIL PROTECTED] http://mattdm.org/ Boston University Linux -- http://linux.bu.edu/ -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Mailman vulnerability
On Wed, 8 Nov 2006, Jesse Keating wrote:
On Wednesday 08 November 2006 06:45, Martin Marques wrote:
Would you people like to see the patches first or do I send the src.rpm?
Either way. We now manage FC-4 in CVS so adding just a patch to generate a
updates-testing rpm is easy enough.
Excelent, because this one is giving me a hard time (attached file). I get
this error when trying to build the rpm:
Patch #9 (mailman-2.1-CVE-2006-3636.patch):
+ patch -p1 -b --suffix .CVE-2006-3636 -s
9 out of 9 hunks FAILED -- saving rejects to file
Mailman/Cgi/edithtml.py.rej
error: Bad exit status from /var/tmp/rpm-tmp.59741 (%prep)
--
21:50:04 up 2 days, 9:07, 0 users, load average: 0.92, 0.37, 0.18
-
Lic. Martín Marqués | SELECT 'mmarques' ||
Centro de Telemática| '@' || 'unl.edu.ar';
Universidad Nacional| DBA, Programador,
del Litoral | Administrador
mailman-2.1.8.orig/Mailman/Cgi/admindb.py 2005-12-30 15:50:07.0
-0300
+++ Mailman/Cgi/admindb.py 2006-11-08 08:42:11.0 -0300
@@ -313,7 +313,7 @@
'nbsp;' + _('Permanently ban from this list')
# While the address may be a unicode, it must be ascii
paddr = addr.encode('us-ascii', 'replace')
-table.AddRow(['%sbrem%s/em' % (paddr, fullname),
+table.AddRow(['%sbrem%s/em' % (paddr, Utils.websafe(fullname)),
radio,
TextBox('comment-%d' % id, size=40)
])
@@ -357,8 +357,8 @@
mlist.HandleRequest(id, mm_cfg.DISCARD)
continue
num += 1
-table.AddRow(['%sbrem%s/em' % (addr, fullname),
+table.AddRow(['%sbrem%s/em' % (addr, Utils.websafe(fullname)),
RadioButtonArray(id, (_('Defer'),
_('Approve'),
_('Reject'),
--- mailman-2.1.8.orig/Mailman/Cgi/create.py2005-12-30 15:50:07.0
-0300
+++ Mailman/Cgi/create.py 2006-11-08 08:56:01.0 -0300
@@ -190,15 +190,24 @@
mlist.Create(listname, owner, pw, langs, emailhost)
finally:
os.umask(oldmask)
-except Errors.EmailAddressError, s:
+except Errors.EmailAddressError, e:
+if e.args:
+s = Utils.websafe(e.args[0])
+else:
+s = Utils.websafe(owner)
request_creation(doc, cgidata,
_('Bad owner email address: %(s)s'))
return
except Errors.MMListAlreadyExistsError:
+# MAS: List already exists so we don't need to websafe it.
request_creation(doc, cgidata,
_('List already exists: %(listname)s'))
return
-except Errors.BadListNameError, s:
+except Errors.BadListNameError, e:
+if e.args:
+s = Utils.websafe(e.args[0])
+else:
+s = Utils.websafe(listname)
request_creation(doc, cgidata,
_('Illegal list name: %(s)s'))
return
@@ -321,15 +330,17 @@
ftable.AddRow([Center(Italic(_('List Identity')))])
ftable.AddCellInfo(ftable.GetCurrentRowIndex(), 0, colspan=2)
-safelistname = Utils.websafe(cgidata.getvalue('listname', ''))
+listname = cgidata.getvalue('listname', '')
+# MAS: Don't websafe twice. TextBox does it.
ftable.AddRow([Label(_('Name of list:')),
- TextBox('listname', safelistname)])
+ TextBox('listname', listname)])
ftable.AddCellInfo(ftable.GetCurrentRowIndex(), 0, bgcolor=GREY)
ftable.AddCellInfo(ftable.GetCurrentRowIndex(), 1, bgcolor=GREY)
-safeowner = Utils.websafe(cgidata.getvalue('owner', ''))
+owner = cgidata.getvalue('owner', '')
+# MAS: Don't websafe twice. TextBox does it.
ftable.AddRow([Label(_('Initial list owner address:')),
- TextBox('owner', safeowner)])
+ TextBox('owner', owner)])
ftable.AddCellInfo(ftable.GetCurrentRowIndex(), 0, bgcolor=GREY)
ftable.AddCellInfo(ftable.GetCurrentRowIndex(), 1, bgcolor=GREY)
--- mailman-2.1.8.orig/Mailman/Cgi/options.py 2005-12-02 22:07:13.0
-0300
+++ Mailman/Cgi/options.py 2006-11-08 08:58:00.0 -0300
@@ -702,8 +702,8 @@
fullname = Utils.uncanonstr(mlist.getMemberName(user), userlang)
if fullname:
-presentable_user += ', %s' % fullname
+presentable_user += ', %s' % Utils.websafe(fullname)
# Do replacements
replacements = mlist.GetStandardReplacements(userlang)
--- mailman-2.1.8.orig/Mailman/Cgi/edithtml.py 2006-01-09 04:06:52.0
-0300
+++ Mailman/Cgi/edithtml.py 2006-11-08 08:59:50.0 -0300
@@ -143,8
Re: Need SeaMonkey opinions - [Fwd: [RHSA-2006:0734-01] Critical: seamonkey security update]
On Wednesday 08 November 2006 05:43, David Eisenstein wrote: Hello Fedora Legacy and Extras folks, This below RHEL advisory just came out, along with advisories like this for Thunderbird and for Firefox. We in Legacy need to get busy on these, because they are critical bugs, and we haven't updated any Firefox, Thunderbird, or SeaMonkey (er, Mozilla) packages in a LONG time. There are some old Bugzilla's that had been open for RHL 7.3, RHL 9, FC 1, FC 2, and FC 3 for Mozilla. There has been a running discussion (and no action -- largely my fault -- sorry!) about how and whether we upgrade Mozilla to SeaMonkey so that SeaMonkey becomes a Mozilla replacement (Core) package rather than an Extras package on a Bugzilla ticket for SeaMonkey. The Bugzilla number is 209167: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209167. My understanding is that Michal Jaegermann (Fedora Legacy contributor) has done work on at least one or more previous versions of SeaMonkey, having created (FC4?) packages that should, once installed, act as a Mozilla replacement, not unlike what the RHEL packages mentioned in RHSA-2006-0734 do. The advantage of having SeaMonkey do this is that all other packages (such as yelp, epiphany, possibly others) will inherit the more secure code from SeaMonkey, since they tap into the shared-library (.so) files that SeaMonkey would be providing. My understanding then also would be that SeaMonkey is meant to be API compatible with Mozilla, so that other programs that depend on functions (or objects) in Mozilla's shared-library should continue to work okay, possibly without recompilation, but probably requiring recompilation and pushing to updates. Does anyone have any comments on how you wish the Legacy Project to approach this? 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. Since Legacy Mozilla/Firefox/Thunderbird security bugs have been open since June (and not worked on), I also advocate that we in Legacy build SeaMonkey packages for *all* releases of Fedora Core that we have ever supported (since older releases were supported at that time) and RHL 7.3 and RHL 9. Does anyone object to that? What say ye?? As an interested sidewalk superintendant, I'd say go with seamonkey since a lot of that stuff comes for free with it. Regards, David Eisenstein Original Message Subject: [RHSA-2006:0734-01] Critical: seamonkey security update Date: Wed, 8 Nov 2006 04:48:59 -0500 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] - Red Hat Security Advisory Synopsis: Critical: seamonkey security update Advisory ID: RHSA-2006:0734-01 Advisory URL: https://rhn.redhat.com/errata/RHSA-2006-0734.html Issue date:2006-11-08 Updated on:2006-11-08 Product: Red Hat Enterprise Linux CVE Names: CVE-2006-5462 CVE-2006-5463 CVE-2006-5464 CVE-2006-5747 CVE-2006-5748 - 1. Summary: Updated seamonkey packages that fix several security bugs are now available for Red Hat Enterprise Linux 2.1, 3, and 4. This update has been rated as having critical security impact by the Red Hat Security Response Team. 2. Relevant releases/architectures: ... (RHEL 2.1, RHEL 3, RHEL 4) ... 3. Problem description: SeaMonkey is an open source Web browser, advanced email and newsgroup client, IRC chat client, and HTML editor. Several flaws were found in the way SeaMonkey processes certain malformed Javascript code. A malicious web page could cause the execution of Javascript code in such a way that could cause SeaMonkey to crash or execute arbitrary code as the user running SeaMonkey. (CVE-2006-5463, CVE-2006-5747, CVE-2006-5748) Several flaws were found in the way SeaMonkey renders web pages. A malicious web page could cause the browser to crash or possibly execute arbitrary code as the user running SeaMonkey. (CVE-2006-5464) A flaw was found in the way SeaMonkey verifies RSA signatures. For RSA keys with exponent 3 it is possible for an attacker to forge a signature that would be incorrectly verified by the NSS library. SeaMonkey as shipped trusts several root Certificate Authorities that use exponent 3. An attacker could have created a carefully crafted SSL certificate which be incorrectly trusted when their site was visited by a victim. This flaw was previously thought to be fixed in SeaMonkey 1.0.5, however Ulrich Kuehn discovered the fix was incomplete (CVE-2006-5462) Users of SeaMonkey are advised to upgrade to these erratum packages, which contains SeaMonkey version 1.0.6 that corrects these issues. snip -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please
Re: Need SeaMonkey opinions - [Fwd: [RHSA-2006:0734-01] Critical: seamonkey security update]
Quoting David Eisenstein [EMAIL PROTECTED]: There are some old Bugzilla's that had been open for RHL 7.3, RHL 9, FC 1, FC 2, and FC 3 for Mozilla. There has been a running discussion (and no action -- largely my fault -- sorry!) about how and whether we upgrade Mozilla to SeaMonkey so that SeaMonkey becomes a Mozilla replacement (Core) package rather than an Extras package on a Bugzilla ticket for SeaMonkey. The Bugzilla number is 209167: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209167. I personally think this would be a good thing. I'd vote for upgrading from mozilla to seamonkey, as long as we can get people to do the work... The advantage of having SeaMonkey do this is that all other packages (such as yelp, epiphany, possibly others) will inherit the more secure code from SeaMonkey, since they tap into the shared-library (.so) files that SeaMonkey would be providing. My understanding then also would be that SeaMonkey is meant to be API compatible with Mozilla, so that other programs that depend on functions (or objects) in Mozilla's shared-library should continue to work okay, possibly without recompilation, but probably requiring recompilation and pushing to updates. We'd need some real good testing for this upgrade of course. But I'm definately in favor of trying. Does anyone have any comments on how you wish the Legacy Project to approach this? 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 think that going to seamonkey is the logical thing to do for RHL and early FC releases. Not sure how later FC releases should be handled, since I don't use them. Note this is in-line with mozilla.org and redhat.com, and basically is the industry standard upgrade path. So I think we are fully justified in doing so. Since Legacy Mozilla/Firefox/Thunderbird security bugs have been open since June (and not worked on), I also advocate that we in Legacy build SeaMonkey packages for *all* releases of Fedora Core that we have ever supported (since older releases were supported at that time) and RHL 7.3 and RHL 9. Does anyone object to that? Sounds great. I can test them on RHL 7.3, RHl 9 and FC 3 64-bit. I'm willing to do any installation/functionality testing required on those versions. Those are the only versions I have access to for testing. What say ye?? Sounds good to me. Regards, David Eisenstein -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: You Need Fedora Legacy!! Re: [fab] looking at our surrent state a bit
Quoting David Eisenstein [EMAIL PROTECTED]: What do you suggest as an alternative for IRC for folks who are not able or interested in using it? I work in several opensource projects that have IRC channels, and I've never used IRC for any of them, and no one has ever complained about that fact except for here on FL. Instead, I use e-mail (the project mailing lists in all cases, except for here on FL where I sometimes use private e-mail also). Not a real big fan of the private e-mail, but it works here for some FL stuff. I've never had any lack of ability to do anything I wanted using e-mail instead of IRC on any of the projects I've worked on. I'm not knocking IRC. It has some limitations though, such as timezone issues, etc. Plus, some of us work on FL stuff at work, and IRC may be blocked at our work place or disruptive to our work. This can be a real issue for some of us. Hence, I never use IRC/IM at work, and hence since 99% of my opensource work is done at the office and not at home, that means I really can't use IRC/IM for these projects. Now, I think IRC is very useful for some things. For example, if you have a board or core group that has regular meetings, IRC is a great way to have those meetings. But for the typical FL user who isn't a core/board member, it is overkill. And I just don't see why I should be forced to install (IRC) software on my machine, learn how to use it, wonder if the University Network Folks will come knocking on my door because of it, and let it disrupt my work, just so I can ask a question that I can ask via e-mail. Now, e-mail lists have advantages also. A nice, searchable archive of the messages for reference by others, reference for myself later, and as a source for creating the documenation on the issues addressed there. Plus of course the asynchronous nature which allows people in all different time zones to participate, etc. So I'm not for getting rid of IRC, just for making it an additional option and not a required option. Warm regards, David Eisenstein -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! -- 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]
David Eisenstein wrote: Does anyone have any comments on how you wish the Legacy Project to approach this? 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. -- 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
