SCIENTIFIC-LINUX-USERS Archives

July 2009

SCIENTIFIC-LINUX-USERS@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:
Kelvin Raywood <[log in to unmask]>
Reply To:
Kelvin Raywood <[log in to unmask]>
Date:
Thu, 23 Jul 2009 19:04:57 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (67 lines)
Connie Sieh wrote:
>> The yum-conf should have been updated automatically unless it has been 
>> changed and in that case the .rpmnew was made.

Yes.  This is the whole point.  If you have modified the .repo files to 
enable signature checking, then your .repo files will not automatically 
get the path to the new key.  Thus packages in the repo signed with the 
new key cause updates to fail.

>> I think the way redhat did it was very confusing and would have caused 
>> other problems.

Perhaps.  But they did it that way so as not to cause security updates 
to fail on systems where it had been working up to that point.  I think 
the complexity of their solution indicates that introducing a new 
signing key to a live distribution is a problem with no easy solution.

>> We know this is a hard pill to swallow.

OK.  I accept that and I realise that it is not something you guys did 
lightly.  I just wanted to point out to other SL users what some of the 
consequences are.  Many, especially those not on this list, will wonder 
why security updates with signature checking are now failing even though 
they had been working fine.  Many others will not even notice.

Jon Peatfield wrote:
> Since we 'edit' all the standard .repo files to point to local mirrors

We do this also.

> it is fairly painless for us to add in any new keys as needed (and of 
> course for 'our' repos we stick in our signing keys as well).

Yes we have our own repos and signing key as well.  But once the 
automatic updates are failing, it is too late for us to apply a fix by 
updating some local custom rpm.

> If things were split into multiple repos (by key) then we would have to 
> re-work all sorts of scripts and testing those would take us much more 
> time and effort.

I'm not suggesting that this should be done now.  I just wanted to point 
out that it is a complex problem with no easy solution.

> ie of the possible choices I'd say that what Connie and Troy picked is 
> the best solution (for us anyway).

I really appreciate all their effort so I don't mean to complain.  For 
me, the timing was bad due to a summer vacation and I didn't manage to 
get out an update to a local rpm before packages signed with the new key 
hit the repos.

> Of course in our setup all the relevant machines are centrally managed 
> by us so we don't have to worry about user-admin'd boxes and can simply 
> arrange to sync over new .repo files from our nightly hack-things-about 
> scripts... :-)

We also have no problem with our centrally-managed machines but it did 
require that we (and you) do something rather than nothing.  For 
"user-admin'd boxes" I've sent an announcement asking people to import 
the new keys manually.  We have a mechanism to identify PCs on our 
network that are failing their nightly updates, and will contact the 
owners to remind them of what they need to do.

Kel Raywood
TRIUMF

ATOM RSS1 RSS2