Mailing List Archive

Days of yore
I remember the days, when summers were hot, winters were cold, and
notifications about kernel security were made using GLSAs.

Then they stopped without warning, and I posted:
http://archives.gentoo.org/gentoo-security/msg_04505.xml
"Now that summer time and 2005.1 are over, I expect that KISS will be
opened soon."

I must say that at the time, I didn't put much credence in that answer.

$ emerge search kiss
*** Deprecated use of action 'search', use '--search' instead
Searching...
[ Results for search key : kiss ]
[ Applications found : 0 ]


In the absence of this, can I request that kernel GLSAs are started
back up, as it seems strange that all packages use them, except for
the kernel.

I run glsa-check -l | grep '\[N\]' on my boxes each night, and get the
results emailed to me - it would be nice to get kernel notifications
too.
We can't all "monitor the "Kernel" component of the "Gentoo Security" product."

Calum
--
http://linuxvps.org/
--
gentoo-security@gentoo.org mailing list
Re: Days of yore [ In reply to ]
Another voice in agreement with the first.

On 4/16/07, Calum <caluml@gmail.com> wrote:
> I remember the days, when summers were hot, winters were cold, and
> notifications about kernel security were made using GLSAs.
>
> Then they stopped without warning, and I posted:
> http://archives.gentoo.org/gentoo-security/msg_04505.xml
> "Now that summer time and 2005.1 are over, I expect that KISS will be
> opened soon."
>
> I must say that at the time, I didn't put much credence in that answer.
>
> $ emerge search kiss
> *** Deprecated use of action 'search', use '--search' instead
> Searching...
> [ Results for search key : kiss ]
> [ Applications found : 0 ]
>
>
> In the absence of this, can I request that kernel GLSAs are started
> back up, as it seems strange that all packages use them, except for
> the kernel.
>
> I run glsa-check -l | grep '\[N\]' on my boxes each night, and get the
> results emailed to me - it would be nice to get kernel notifications
> too.
> We can't all "monitor the "Kernel" component of the "Gentoo Security" product."
>
> Calum
> --
> http://linuxvps.org/
> --
> gentoo-security@gentoo.org mailing list
>
>


--
Matthew Poletiek
www.chill-fu.net
--
gentoo-security@gentoo.org mailing list
Re: Days of yore [ In reply to ]
+1
Matt Poletiek wrote:
> Another voice in agreement with the first.
>
> On 4/16/07, Calum <caluml@gmail.com> wrote:
>> I remember the days, when summers were hot, winters were cold, and
>> notifications about kernel security were made using GLSAs.
--
gentoo-security@gentoo.org mailing list
Re: Days of yore [ In reply to ]
> In the absence of this, can I request that kernel GLSAs are started
> back up, as it seems strange that all packages use them, except for
> the kernel.

> Another voice in agreement with the first.

Yay, me too.

--
echo "dpefsAgmv{p/psh" | perl -pe 's/(.)/chr(ord($1)-1)/ge'
GnuPG key ID 0x6D2FF8B5 @ pgp.rediris.es
http://www.fluzo.org/
--
gentoo-security@gentoo.org mailing list
Re: Days of yore [ In reply to ]
Javier Barrio wrote:
>> In the absence of this, can I request that kernel GLSAs are started
>> back up, as it seems strange that all packages use them, except for
>> the kernel.
>>
>
>
>> Another voice in agreement with the first.
>>
>
> Yay, me too.
>
<aol>me too</aol>
--
gentoo-security@gentoo.org mailing list
Re: Days of yore [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

A vote here.


- --
Fabio A. Correa D.

Physics Dept, Universidad Nacional, Bogota, Colombia
facorread@gmail.com
ffaaccdd@yahoo.co.uk facorread@unal.edu.co
My webpage and OpenPGP key at http://facorread.150m.com
facorread@alexandria.cc is not working anymore!!!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGI1ONYOZCB4zf2uQRAt5OAJ0RMypFwu6wP5rk3q7FD0rb76yIVgCg7Ol9
nd840YNA2nu1qmkIZv8LOGs=
=wdsa
-----END PGP SIGNATURE-----
--
gentoo-security@gentoo.org mailing list
Re: Days of yore [ In reply to ]
Another Vote here

--
gentoo-security@gentoo.org mailing list
Re: Days of yore [ In reply to ]
On 4/16/07, Lars Hartman <psychosmurfz@googlemail.com> wrote:
> Another Vote here

Lots of "me toos" on this list....anyone who's also willing to put
their time where their mouth is and help out with GLSA wrangling?
That's been a chronic problem with the Gentoo Security team. Lots of
people want security notifications, but not nearly as many people are
willing to help make that happen.

For those of you willing to help, pop into #gentoo-security and talk
to the folks there about where you can contribute.

--kurt
--
gentoo-security@gentoo.org mailing list
Re: Days of yore [ In reply to ]
On 4/16/07, Kurt Lieber <klieber@gentoo.org> wrote:
> Lots of "me toos" on this list....

At least that means it's not just a bugbear of mine....

> anyone who's also willing to put
> their time where their mouth is and help out with GLSA wrangling?
> That's been a chronic problem with the Gentoo Security team. Lots of
> people want security notifications, but not nearly as many people are
> willing to help make that happen.

But the infrastructure is already in place for GLSA's. It was working
like that, it was removed (with no notice that I noticed, which left
me insecure for quite a while before I wondered "why haven't there
been any kernel GLSAs for a while" and asked on the list), and some
KISS idea was proposed.

There's no need to to anything different - just to include *-sources
in the GLSAs.

If it's not broken....

--
http://linuxvps.org/
--
gentoo-security@gentoo.org mailing list
Re: Days of yore [ In reply to ]
On 4/16/07, Calum <caluml@gmail.com> wrote:
> But the infrastructure is already in place for GLSA's.

With all due respect, you haven't the faintest idea how much work it
takes to issue a GLSA. It's not a simple matter of typing some stuff
in an email and hitting send. You have to chase devs down and get
them to patch their stuff. You have to chase arch maintainers down
and get them to test things and mark them stable. You have to chase
security people down to draft the GLSA. You have to chase more
security people down to peer review the GLSA.

I don't know that we've ever formally quantified how much time an
average GLSA takes, but my semi-educated guess would be in the
neighborhood of 10 hours per package.

Now, take that process and multiply it by the number of -sources in
the tree and you can start to get an idea for how much time it takes
to issue kernel updates.

So, again, #gentoo-security is where you can start being part of the solution.

--kurt
--
gentoo-security@gentoo.org mailing list
Re: Days of yore [ In reply to ]
On Mon, 2007-04-16 at 08:32 -0500, Kurt Lieber wrote:
> On 4/16/07, Calum <caluml@gmail.com> wrote:
> > But the infrastructure is already in place for GLSA's.
>
> You have to chase
> security people down to draft the GLSA. You have to chase more
> security people down to peer review the GLSA.

In my limited experience with vulnerabilities in packages I maintain.
The problem or delays seem to be with the last two steps listed. Not to
simplify them by any means, or the preceding steps.

http://bugs.gentoo.org/show_bug.cgi?id=173122
http://bugs.gentoo.org/show_bug.cgi?id=169433

Not to mention in my case upstream had already acted or etc, so no
patching or etc was needed on my behalf. Just bumps and stabilization if
anything.

> I don't know that we've ever formally quantified how much time an
> average GLSA takes, but my semi-educated guess would be in the
> neighborhood of 10 hours per package.

I would not be surprised, and surely that if they have to follow it
through from start to finish. Less if say maintaining devs are
responsible for addressing their vulnerable package, and not leaving it
up to others like security team. All must do their parts to get things
done in a timely manner.

> Now, take that process and multiply it by the number of -sources in
> the tree and you can start to get an idea for how much time it takes
> to issue kernel updates.

Kernel issues must be a nightmare for the security team.

> So, again, #gentoo-security is where you can start being part of the solution.

If I had the time I would go join and help. As is, already quite over
committed :)

--
William L. Thomson Jr.
Gentoo/Java
Re: Days of yore [ In reply to ]
On Monday 16 April 2007 16:05, William L. Thomson Jr. wrote:
> Not to mention in my case upstream had already acted or etc, so no
> patching or etc was needed on my behalf. Just bumps and stabilization if
> anything.
Yeah, this is because the Security team is simply understaffed as has been the
case for far too long. We only have a few very active members and due to
process and QA stuff it simply takes time. I hope we're going to bring it
down soon though.

Try searching for bugs in ebuild+ or ebuild++ status, that should give a hint
about what problems we face. Not to mention other + and ++ statuses.

> Kernel issues must be a nightmare for the security team.
Kernel issues are a nightmare because of the many sources and the way Gentoo
handles kernel sources. emerge gentoo-sources won't magically fix your
machine and besides not everyone want to upgrade their kernel for every small
issue. 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). 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. So if you want to help get
things back on track please join #gentoo-security and lets talk.

--
Sune Kloppenborg Jeppesen
Gentoo Linux Security Team
Re: Days of yore [ In reply to ]
On Mon, 16 Apr 2007 09:36:30 +0100
Calum <caluml@gmail.com> wrote:

> I run glsa-check -l | grep '\[N\]' on my boxes each night, and get the
> results emailed to me - it would be nice to get kernel notifications
> too.

Not directly related, but you might be interested in the "affected"
target or the --mail option of glsa-check.

Marius
--
gentoo-security@gentoo.org mailing list
Re: Days of yore [ In reply to ]
On 4/16/07, Marius Mauch <genone@gentoo.org> 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/
--
gentoo-security@gentoo.org mailing list
Re: Days of yore [ In reply to ]
Hi Calum,

On Monday 16 April 2007 19:09, Calum wrote:
> 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.)
I'm not proud of the situation either, but it's not going to magically give me
the time/skills to actually do this stuff. I agree that it has been
mishandled, but given my timerestraints I simply can only wait for a good
recruit to appear.

I agree that policy should be updated to reflect this but that got bogged down
by other issues last I tried. I'll try again.

> > 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.
Volunteer projects unfortunately doesn't work the way normal paid work does.
If someone is willing to actually sponsor kernel GLSAs I'm sure someone will
step up:-)

> 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.
I would gladly see that happen, but I guess you have to talk to hlieberman
from security or some of the kernel maintainers (which are understaffed as
well as far as I undestand it). Or wait for others to reply.

If someone is willing to take the time to actually draft the GLSAs I'd be
happy to send/review.

--
Sune Kloppenborg Jeppesen
Gentoo Linux Security Team
Re: Days of yore [ In reply to ]
Okej.. I think I see how this is going.. I'm not able to code this
myself, but I can put my money where my mouth is. If there's nobody that
will say they can do it for $€£ price then I'll create a rentacoder
project and try to put together the details. I've no idea how much it
would cost and if it's complex/trivial. Anyone else interested in
pitching in?

Thanks

Christopher
--
gentoo-security@gentoo.org mailing list
Re: Days of yore [ In reply to ]
On Monday 16 April 2007 20:31, Sune Kloppenborg Jeppesen wrote:
> I agree that policy should be updated to reflect this but that got bogged
> down by other issues last I tried. I'll try again.
Ohh well, I must have dropped my memory somewhere I forgot:(

I actually updated the Gentoo Linux Vulnerability Treatment Policy¹ last
August to reflect that:

"Kernels
Currently kernels are not covered by the GLSA release process.
Vulnerabilities must still be reported and will be fixed, but no GLSA will be
issued when everything is solved.
Note: This policy should be changed when new tools are added to cover
security vulnerabilities affecting the different kernel sources."

¹ http://www.gentoo.org/security/en/vulnerability-policy.xml

--
Sune Kloppenborg Jeppesen
Gentoo Linux Security Team
Re: Days of yore [ In reply to ]
the script I use to get email notifications of the affected ebuilds,
that also prepares a shell script that fixes the glsas.

might be useful for someone.


yours,
kos

#!/bin/bash
tmp="/tmp/.glsa-check"
update="/root/run-to-update.sh"
glsa="/usr/portage/metadata/glsa"

if [ -f $tmp ] ; then
rm -f $tmp
fi

if [ -f $update ] ; then
rm -f $update
fi

emerge --sync >/dev/null 2>&1
glsa-check -n --list affected 2> /dev/null > $tmp

arr=(`cat $tmp | awk '{print $1}'`)
BUGCOUNT=${#arr[@]}

if [ $BUGCOUNT -gt "0" ] ; then

echo -e '#!/bin/bash' > $update
echo -ne '#relevant as for ' >> $update
echo `date +%D` >> $update

n=0
while (($n < $BUGCOUNT)); do

echo "/usr/bin/glsa-check -f" ${arr[$n]} >> $update
cat $glsa/glsa-${arr[$n]}.xml | grep "# emerge" | grep -v "emerge
--sync" | \
sed 's/\&quot\;/\"/g' | sed 's/\&gt\;/\>/g' | sed 's/<\/code>//g' >>
$update
echo >> $update
let n+=1
done

echo -e "\nRun $update to update the system" >> $tmp
cat $tmp | /bin/mail -s GLSA_UNAPPLIED email_address@domain.com
rm -rf $tmp
fi





Sune Kloppenborg Jeppesen wrote:
> On Monday 16 April 2007 20:31, Sune Kloppenborg Jeppesen wrote:
>> I agree that policy should be updated to reflect this but that got bogged
>> down by other issues last I tried. I'll try again.
> Ohh well, I must have dropped my memory somewhere I forgot:(
>
> I actually updated the Gentoo Linux Vulnerability Treatment Policy¹ last
> August to reflect that:
>
> "Kernels
> Currently kernels are not covered by the GLSA release process.
> Vulnerabilities must still be reported and will be fixed, but no GLSA will be
> issued when everything is solved.
> Note: This policy should be changed when new tools are added to cover
> security vulnerabilities affecting the different kernel sources."
>
> ¹ http://www.gentoo.org/security/en/vulnerability-policy.xml
>

--
gentoo-security@gentoo.org mailing list
RE: Days of yore [ In reply to ]
Very nice, slick script .. thanks!

Lenny

-----Original Message-----
From: Konstnatin V. Gavrilenko [mailto:mlists@arhont.com]
Sent: Tuesday, May 22, 2007 11:33 AM
To: gentoo-security@lists.gentoo.org
Subject: Re: [gentoo-security] Days of yore

the script I use to get email notifications of the affected ebuilds,
that also prepares a shell script that fixes the glsas.

might be useful for someone.


yours,
kos

#!/bin/bash
tmp="/tmp/.glsa-check"
update="/root/run-to-update.sh"
glsa="/usr/portage/metadata/glsa"

if [ -f $tmp ] ; then
rm -f $tmp
fi

if [ -f $update ] ; then
rm -f $update
fi

emerge --sync >/dev/null 2>&1
glsa-check -n --list affected 2> /dev/null > $tmp

arr=(`cat $tmp | awk '{print $1}'`)
BUGCOUNT=${#arr[@]}

if [ $BUGCOUNT -gt "0" ] ; then

echo -e '#!/bin/bash' > $update
echo -ne '#relevant as for ' >> $update
echo `date +%D` >> $update

n=0
while (($n < $BUGCOUNT)); do

echo "/usr/bin/glsa-check -f" ${arr[$n]} >> $update
cat $glsa/glsa-${arr[$n]}.xml | grep "# emerge" | grep -v "emerge
--sync" | \
sed 's/\&quot\;/\"/g' | sed 's/\&gt\;/\>/g' | sed 's/<\/code>//g' >>
$update
echo >> $update
let n+=1
done

echo -e "\nRun $update to update the system" >> $tmp
cat $tmp | /bin/mail -s GLSA_UNAPPLIED email_address@domain.com
rm -rf $tmp
fi





Sune Kloppenborg Jeppesen wrote:
> On Monday 16 April 2007 20:31, Sune Kloppenborg Jeppesen wrote:
>> I agree that policy should be updated to reflect this but that got bogged
>> down by other issues last I tried. I'll try again.
> Ohh well, I must have dropped my memory somewhere I forgot:(
>
> I actually updated the Gentoo Linux Vulnerability Treatment Policy last
> August to reflect that:
>
> "Kernels
> Currently kernels are not covered by the GLSA release process.
> Vulnerabilities must still be reported and will be fixed, but no GLSA will be
> issued when everything is solved.
> Note: This policy should be changed when new tools are added to cover
> security vulnerabilities affecting the different kernel sources."
>
> http://www.gentoo.org/security/en/vulnerability-policy.xml
>

--
gentoo-security@gentoo.org mailing list


--
gentoo-security@gentoo.org mailing list