SCIENTIFIC-LINUX-USERS Archives

January 2008

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:
Konstantin Olchanski <[log in to unmask]>
Reply To:
Konstantin Olchanski <[log in to unmask]>
Date:
Tue, 15 Jan 2008 10:19:28 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (29 lines)
Hello there - today at my door arrived another bunch of unsigned java
packages. This is what happens next: automatic updates of all machines
on site at TRIUMF are configured to refuse to install unsigned packages,
so installation of java packages fails, blocking any further
updates (no matter how urgent or important) until somebody manually
goes to each SL machine on site and updates the java rpms
manually (well, runs a script that runs rpm --install).

Surely this situation is not ideal and this problem has been
communicated to the perpetrators: packagers of java ought
to sign their stuff and authors of yum should fix this denial
of service vulnerability (where any bum package prevents
installation of security updates).

In the mean time, could java rpms be signed with the SL key?

Note that disabling the signature checks is a bad idea - in this case,
all machines on site are automatically owned if ftp.sl.org
or the local mirror site or the mirroring process becomes
compromised (think: DNS is tricked to resolve ftp.sl.org into an ip
address of an trojan ftp site full of trojaned rpms). This is not
theoretical, it is something that did happen to other linux distributions.

-- 
Konstantin Olchanski
Data Acquisition Systems: The Bytes Must Flow!
Email: olchansk-at-triumf-dot-ca
Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada

ATOM RSS1 RSS2