SCIENTIFIC-LINUX-DEVEL Archives

April 2009

SCIENTIFIC-LINUX-DEVEL@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Stephan Wiesand <[log in to unmask]>
Reply To:
Stephan Wiesand <[log in to unmask]>
Date:
Thu, 9 Apr 2009 17:53:46 +0200
Content-Type:
TEXT/PLAIN
Parts/Attachments:
TEXT/PLAIN (42 lines)
On Tue, 7 Apr 2009, Stephan Wiesand wrote:

> http://www-zeuthen.desy.de/~wiesand/SL5/openafs.SLx-1.4.7-68.2.src.rpm
>
> I could not yet test the resulting RPMs yet

These are running on a significant number of systems here now (SL4/5, 
32/64, UP/SMP, xen host/VM,..) and are doing fine. These are the binaries 
built here so far, but it would be the first time that there's a problem 
with the ones built at FNAL (which we generally use) but not with my 
builds.

> The patches do not apply to the 1.2.13 source (for SL3). It seems quite 
> feasible to apply the required changes (I wouldn't even call it 
> "backporting"),

An SRPM with the same changes for SL3 is here:

http://www-zeuthen.desy.de/~wiesand/SL/openafs-1.2.13-15.18.SL.src.rpm

When comparing the resulting patches to the ones against 1.4 from 
openafs.org, I'm fairly confident that they will do their job and no harm 
with 1.2.

I have the binaries running on three SL3 systems (i686, x86_64, ia32e, all 
SMP), and they seem to work.


If anyone feels like checking that what I've done makes sense, that would 
be much appreciated. If anyone came up with a way to actually prove that 
the security holes are no longer present in the patched builds, that would 
of course be even better.

Cheers,
 	Stephan

-- 
Stephan Wiesand
   DESY - DV -
   Platanenallee 6
   15738 Zeuthen, Germany

ATOM RSS1 RSS2