On 4/16/07, Marius Mauch <[EMAIL PROTECTED]> wrote:
Not directly related, but you might be interested in the "affected" target or the --mail option of glsa-check.
I am interested in that - but I don't think those options were there when I started putting those cronjobs on my servers many moons ago. Thanks though - I'll investigate. Sune:
emerge gentoo-sources won't magically fix your machine and besides not everyone want to upgrade their kernel for every small issue.
Nope, of course. But those of us that used the GLSAs as a one-stop package security report were hung out to dry. (Talk about cold sweat when I found out....)
That's why plasmaroo wrote KISS, sadly he left before it went public and now we waiting for another tool for kernel issues. It's not even on the horizon yet (at least not to my knowledge).
Yep, It sounds like it might have been promising. However, who on earth thought it would be a good idea to remove the functioning kernel security alert system **before** the replacement was written, working, heavily tested, and all the users given 12 months of notice? (The obvious method of notification would have been to create a fake GLSA for glsa-check.)
This started out as a small problem that we thought would be temporary but has sadly turned kind of permanent without us informing users properly.
This is why, when people ask me if they can "temporarily" do things in my lab, I say no. Temporarily often has a habit of not being. Could we just get GLSAs going again for some of the most common sources for now then? Say gentoo, and hardened? x86, and AMD? Or some virtual ebuild that requires certain versions of kernels to be installed, that can be updated via Portage from time to time. Then you could script emerge -pv sys-kernel/secure-kernel-source, and when it said it would need to install hardened-sources 2.6.26, you'd know that there must have been a bug in <2.4.26. -- http://linuxvps.org/ -- [EMAIL PROTECTED] mailing list
