rh_advisory_update: Automatically install RPMs from redhat-watch-list emails
Dan Harkless
and have been happy just doing updates manually. When I got an
advisory from the redhat-watch-list
(<http://www.redhat.com/mailman/listinfo/redhat-watch-list>), or
Bugtraq, if that copy showed up first, I'd wget the appropriate URLs
therein, cross-check the MD5 hashes in the mail against 'md5sum'
output, check the embedded MD5 hashes and signatures with 'rpm
--checksig', and then install.
Thought about writing a script to automate that, but never got around
to it. The *huge* KDE update from the other day finally pushed me
into it, though. Way too many RPMs in that update to comfortably
handle manually.
First, of course, I looked around to see what tools already existed to
do this, and found a bunch (rhupdate, rh_update, etc.), but they
weren't quite what I was looking for. For instance, they keyed off of
the FTP or web site rather than an advisory email, and thus didn't
reap the security benefit of a crypto hash delivered via an alternate
communications channel. Also they had complex features I didn't need
and complex setup I didn't want (e.g. related to unmanned installs).
Therefore I wrote my own script, rh_advisory_update:
http://harkless.org/dan/software/#rh_advisory_update
If you pass it a Red Hat Security Advisory or Bug Fix Advisory email
on stdin, it'll automatically download, double-verify (with md5sum and
'rpm --checksig') and install the appropriate RPMs for your
architecture and Red Hat release.
I've done a fair amount of testing and believe the script to be
bug-free, but if you encounter any problems, please let me know.
--
Dan Harkless
use...@harkless.org
http://harkless.org/dan/
Dan Harkless
news:<4189894b.03051...@posting.google.com>:
[...]
> Therefore I wrote my own script, rh_advisory_update:
>
> http://harkless.org/dan/software/#rh_advisory_update
>
> If you pass it a Red Hat Security Advisory or Bug Fix Advisory email
> on stdin, it'll automatically download, double-verify (with md5sum and
> 'rpm --checksig') and install the appropriate RPMs for your
> architecture and Red Hat release.
My apologies to anyone who tried to download my script over the past
few days and was unable to. My server suffered from an acute Murphy's
Law attack.
I've now finished rebuilding it and rh_advisory_update is again
available for downloading.
Eric Bursley
updates, and those you can generally perform manually.
--
Regards,
Eric Bursley
BCFP, MCSE+I, MCSE, MCSA, RHCE, SCNA, CCNA
HP IT Professional (HP-UX 11i)
"Dan Harkless" <use...@harkless.org> wrote in message
news:4189894b.03051...@posting.google.com...
Dan Harkless
> I prefer to just use apt-get for RPM. Works on everything except for kernel
> updates, and those you can generally perform manually.
Yeah, someone else recommended that one to me via email -- wasn't
familiar with it before that.
However, it requires you to trust apt repositories not maintained by
Red Hat, yes? Aside from security concerns with that, I would imagine
there's some delay between the time Red Hat releases updates and the
time they get into the APT repositories.
And I don't even see an 'rpm --checksig' step in the apt-get session
logs at <http://freshrpms.net/apt/examples.html>. I gather that as of
RPM 4.1 (RH 8.0), a verify happens automatically when you install an
RPM, but that wasn't true on earlier versions.
And if you rely solely on the embedded checksums/signature, rather
than also using checksums coming from an alternate communications
channel (as rh_advisory_update does with redhat-watch-list / Bugtraq
emails), then in the unlikely event that someone gained access to
updates.redhat.com or one of its mirrors after an advisory was
released, and also gained access to any trusted signing key that
people typically have installed in gpg/pgp (or in rpm, in versions 4.1
and up), then you could be trojaned.
Matthew Miller
>However, it requires you to trust apt repositories not maintained by
>Red Hat, yes? Aside from security concerns with that, I would imagine
You can enable signature checking, to insure that only packages which have
been GPG signed by Red Hat or someone else you trust are allowed.
>there's some delay between the time Red Hat releases updates and the
>time they get into the APT repositories.
No longer than it takes to propagate to other mirrors. It's maybe not as
fast as up2date, but since RH's public servers are usually overloaded when
an important update comes out, it can actually be *faster* than waiting on
the official site.
>And I don't even see an 'rpm --checksig' step in the apt-get session
>logs at <http://freshrpms.net/apt/examples.html>. I gather that as of
>RPM 4.1 (RH 8.0), a verify happens automatically when you install an
>RPM, but that wasn't true on earlier versions.
Nonetheless, they can be enabled -- we've been doing it at BU for a couple
of years.
>And if you rely solely on the embedded checksums/signature, rather
>than also using checksums coming from an alternate communications
>channel (as rh_advisory_update does with redhat-watch-list / Bugtraq
>emails), then in the unlikely event that someone gained access to
>updates.redhat.com or one of its mirrors after an advisory was
>released, and also gained access to any trusted signing key that
>people typically have installed in gpg/pgp (or in rpm, in versions 4.1
>and up), then you could be trojaned.
If you're paranoid about this, you could write a Lua script for apt that
would make it also check these external checksums.
--
Matthew Miller mat...@mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
ynotssor
news:slrnbckbi3...@jadzia.bu.edu
>> However, it requires you to trust apt repositories not maintained by
>> Red Hat, yes? Aside from security concerns with that, I would imagine
>
> You can enable signature checking, to insure that only packages which have
> been GPG signed by Red Hat or someone else you trust are allowed.
How is this done, please?
There is no reference to "signature" and/or "GPG" in the apt-get man page.
tony
--
use hotmail com for any email replies
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Dan Harkless
> >there's some delay between the time Red Hat releases updates and the
> >time they get into the APT repositories.
>
> No longer than it takes to propagate to other mirrors. It's maybe not as
> fast as up2date, but since RH's public servers are usually overloaded when
> an important update comes out, it can actually be *faster* than waiting on
> the official site.
Yes, I'm well familiar with that phenomenon. That's why I added the
-u parameter to rh_advisory_update, so you can specify any
updates.redhat.com mirror you like. Heck of a lot easier to
substitute in a different mirror this way than when copying and
pasting URLs manually, as I used to do.
> If you're paranoid about this, you could write a Lua script for apt that
> would make it also check these external checksums.
Not paranoid about it, per se. I just like having the extra security
check in there, since it's easy to do and could potentially be very
important.