On 12/13/13 9:00 AM, Andreas Haupt wrote:
> Hi Christina,
>
> On Thu, 2013-12-12 at 23:22 +0100, [log in to unmask] wrote:
>
>> Until Monday sites could do:
>> # yum downgrade openssl\*
>> and will get the 1.0.0-27 from EMI third-party repository. With the
>> condition that emi2/3-third-party reopsitories have the same priority as
>> the sl-security repository (usually priority=1).
> an alternative is to install yum-plugin-versionlock and then:
>
> [root@lcg-cream ~]# cat /etc/yum/pluginconf.d/versionlock.list
> 0:openssl-devel-1.0.0-27.el6.x86_64
> 0:openssl-1.0.0-27.el6.x86_64
>
> But this is a real mess - we are currently in the situation to either
> run an insecure service or be unable to run the service at all!
That's why I sayd that "protecting" packages from sl-security is a hard
thing to do.
Especially because all the packages released by SL after the
openssl-1.0.1e-15 depend on the new library provided by this package. So
it is a matter of days... tunil we won't be able to rpotect anymore,
because it will not be possible to update any other packages from SL. or
CentOS
To answer to Maarten:
- when the openssl-1.0.1e-15 was released, the announcement didn't
contained any information regarding the fixes provided. Nothing else
than "updated for dependency resolution":
http://listserv.fnal.gov/scripts/wa.exe?A2=ind1312&L=scientific-linux-errata&T=0&P=571
As SL is downtream RedHat - one should go to see what RHEl says:
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/6.5_Release_Notes/bh-chap-security.html
IMHO there should be a broadcast advicing in the downgrade to 1.0.0
version AND on the protection with version lock (I say and because by
this time sites should have already got the update from the sl-security)
and threat the update of GridSite as emergency.
Again IMHO an update of openssl with such an important change was
passed...to "easly" without underlying the changes it provides.
You can see how happy people are ..around:
http://comments.gmane.org/gmane.mail.postfix.user/239960
Cristina
> What
> makes the situation even worse is that all the clients must update their
> libgridsite to a version that creates at least 1024-bit proxies by
> default (or did I understand this incorrectly?). Furthermore I currently
> don't have a chance see which clients still delegate 512-bit proxies to
> our cream instance to see how the situation improves over the next time.
>
> Any advises to handle this situation?
>
> Thanks,
> Andreas
|