I just recieved email with the subject "Red Hat Network Announcement"
which included the following claim:
- Priority bandwidth during heavy traffic periods. Paid subscribers have
immediate access to errata and ISOs, ensuring that their systems are
kept up to date and always secure.
Our company evaluated current [1], nrh-up2date [2] and openup [3] to
provide up2date services to one pool of our servers. While none of the
three programs provide full RHN functionality, they did provide
functionality that we needed that RHN does not provide. The issue has
been that these servers are running packages made available from the
contrib directory of the Red Hat public ftp site or using RPMs based from
spec files provided from RH PowerTools which we rebuilt. So rather than
up2date once for Red Hat RPMs and then manually add updates to contrib/our
own RPMs, we do it all with a single up2date which RHN would not allow us
to do. However, for a small pool of servers with little or no additional
packages, we have continued to use paid RHN accounts.
The major difference in security responce came about when the update for
CUPS remote root vulnerablity [4] was released. The pool of servers that
contact our in-house up2date server where upgraded to a non-effected
version of CUPS on December 20th. There where no complaints or issues
discovered by the users after the upgrade. To try to avoid any issues of
getting support from Red Hat in the future, the CUPS packages on the paid
RHN accounts where not updated until offical RHN update was provided on
January 9th [5]. Considering the amount of time permitted to pass, I find
the claim offensive that this could be consider ensuring systems are
"always secure." Does Red Hat have an online defination of "secure" that
RHN adheres to? What is the maxium time period that a paid account should
expect to pass from the public announcement of a patch to a remote root
vulnerablity and the ensured update?
References:
[1] http://current.tigris.org/
[2] http://www.nrh-up2date.org/
[3] http://openup.colug.net/
[4] http://www.idefense.com/advisory/12.19.02.txt
[5] https://rhn.redhat.com/errata/RHSA-2002-295.html
--
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-list
