3:15 p.m.
Hello everybody.
In case you didn't see, there was a post by Thorsten Leemhuis to the
fedora-extras list regarding the creation of a Fedora Extras security
response team. The message can be seen here:
https://www.redhat.com/archives/fedora-extras-list/2006-April/msg01650.html
Here are the people I know have an interest in helping out with the
security response team:
Hans de Goede
Jason L Tibbitts III
Dennis Gilmore
Jochen Schmitt
Ville Skyttä
Michael J Knox
If you're interested, feel free to chime in.
Right now I have a pretty good idea of what's needed to get this project
off the ground. We have a mailing list (which would be step one).
I need to fix up some CVS space for things like tools and tracking text
files. This repository is here:
http://cvs.fedora.redhat.com/viewcvs/fedora-security/?root=fedora
We will need a package manifest. Basically a file that tells us which
packages and versions we're currently shipping in extras. A tool to
generate this will also be needed since we'll want to update this file on a
regular basis. Given how fast Extras changes I think this will be the
easiest way to check if we currently ship package <foo>.
An errata template is needed. I'm thinking we should copy the current
Fedora Core template for now. We can mangle it as we see fit at a later
date.
Process needs to be documented on the fedoraproject wiki. Since we don't
currently have a process, this is the only thing done :)
The most important part of this will be making it easy to specify what we
expect of ourselves. I hope to have some time this weekend to clean up the
security wiki pages a bit.
I think this is enough for now. Questions, Comments?
--
JB
3:30 p.m.
On Fri, 2006-04-28 at 16:15 -0400, Josh Bressers wrote:
If you're interested, feel free to chime in.
Add me to the list. I can try to help w/ packaging up stuff that gets
reported, or reviewing proposed updates.
I'm also really trying to drive this policy approval home within Extras.
--
Jesse Keating
Release Engineer: Fedora
3:47 p.m.
Hello everybody.
In case you didn't see, there was a post by Thorsten Leemhuis to the
fedora-extras list regarding the creation of a Fedora Extras security
response team. The message can be seen here:
https://www.redhat.com/archives/fedora-extras-list/2006-April/msg01650.html
It's been suggested that we call this group the "Fedora Security Response
Team". I don't have a complaint. Unless someone has a very good reason,
we'll say that's the name.
--
JB
4:10 p.m.
>>>> "JB" == Josh Bressers
<bressers(a)redhat.com> writes:
JB> We will need a package manifest. Basically a file that tells us
JB> which packages and versions we're currently shipping in extras.
Here's the query script I use:
#!/usr/bin/perl -w
$OWNERS='/home/tibbs/work/extras-cvs/owners/owners.list';
$MIRROR='/nas/redhat/mirror-extras';
@RELEASES=qw(3 4 5 development);
$qa=''; #quiet warning
open OWNERS, $OWNERS or die "Can't open $OWNERS: $!";
while (defined($l = <OWNERS>)) {
next if $l =~ /^#/;
chomp $l;
($distro, $package, $desc, $owner, $qa, $cc) = split(/\|/, $l);
last if $package eq $ARGV[0];
}
unless ($package) {
print "Could not find package $ARGV[0] in $OWNERS\n";
exit 1;
}
print "Found package $package in owners.list:\n";
print " Distro:\t$distro\n";
print " Desc:\t\t$desc\n";
print " Owner:\t$owner\n";
print " CC:\t\t$cc\n";
print " Releases and versions:\n";
for $release (@RELEASES) {
$dir = "$MIRROR/$release/SRPMS";
$release eq "development" && ($release = "dev");
opendir DIR, $dir or die "Can't opendir $dir: $!";
while (defined($f = readdir(DIR))) {
next unless $f =~ /^$package-(.*)\.src\.rpm$/;
next if $1 =~ /-.*-/;
($ver, $rev) = $1 =~ /^([^-]+)-([^-]+)$/;
print " $release\t$ver\t$rev\t$dir/$f\n";
}
}
releases xmms
Found package xmms in owners.list:
Distro: Fedora Extras
Desc: The X MultiMedia System, a media player which resembles Winamp
Owner: ville.skytta(a)iki.fi
CC:
Releases and versions:
4 1.2.10 19.fc4 /nas/redhat/mirror-extras/4/SRPMS/xmms-1.2.10-19.fc4.src.rpm
4 1.2.10 21.fc4 /nas/redhat/mirror-extras/4/SRPMS/xmms-1.2.10-21.fc4.src.rpm
5 1.2.10 22.fc5 /nas/redhat/mirror-extras/5/SRPMS/xmms-1.2.10-22.fc5.src.rpm
5 1.2.10 23.fc5 /nas/redhat/mirror-extras/5/SRPMS/xmms-1.2.10-23.fc5.src.rpm
dev 1.2.10 23.fc6
/nas/redhat/mirror-extras/development/SRPMS/xmms-1.2.10-23.fc6.src.rpm
- J<
7:50 p.m.
On Fri, Apr 28, 2006 at 04:15:19PM -0400, Josh Bressers wrote:
Hello everybody.
In case you didn't see, there was a post by Thorsten Leemhuis to the
fedora-extras list regarding the creation of a Fedora Extras security
response team. The message can be seen here:
https://www.redhat.com/archives/fedora-extras-list/2006-April/msg01650.html
Here are the people I know have an interest in helping out with the
security response team:
Hans de Goede
Jason L Tibbitts III
Dennis Gilmore
Jochen Schmitt
Ville Skyttä
Michael J Knox
If you're interested, feel free to chime in.
I'm definitely willing to help out.
luke
2:38 a.m.
Josh Bressers wrote:
Hello everybody.
In case you didn't see, there was a post by Thorsten Leemhuis to the
fedora-extras list regarding the creation of a Fedora Extras security
response team. The message can be seen here:
https://www.redhat.com/archives/fedora-extras-list/2006-April/msg01650.html
Here are the people I know have an interest in helping out with the
security response team:
Hans de Goede
Jason L Tibbitts III
Dennis Gilmore
Jochen Schmitt
Ville Skyttä
Michael J Knox
I'm most definetly still interested IOW count me in. I won't be doing
much of the monitoring and bookkeeping, expect for the checking of lwn's
weekly security report against extras. I already get way to much mail as
things are. I'm however "available" for helping out with / reviewing
less then trivial fixes (C and C++ only) and I'm available to fix
packages where the maintainer is not available or not responsive.
I would like to suggest the following procedure for any "help needed (in
any form)" requests:
-send a mail to this list with the "help" request
-if appropriate someone can claim this (assign bz ticket?)
-if appropriate once the fix is in CVS the fixer posts a request for
a review to this list.
Regards,
Hans
2:55 a.m.
bressers(a)redhat.com said:
A tool to generate this will also be needed since we'll want to
update this
file on a regular basis.
Should be easy to snarf a piece of my script here:
http://cvs.fedora.redhat.com/viewcvs/status-report-scripts/?root=fedora
Basically, you just need to retain the grabRepoList piece for Extras, keep a
bit more info than just the package name, and format the output to taste.
If no one beats me to it, I'm happy to do the job some time in the coming days
(sorry, a bit swamped right now...).
Cheers,
Christian
(who didn't notice the reply-to was not the list...)
9:35 a.m.
New subject: Fedora Security Response Team
I need to fix up some CVS space for things like tools and tracking text
files. This repository is here:
http://cvs.fedora.redhat.com/viewcvs/fedora-security/?root=fedora
I now have the ability to control who has commit access to this space, so
we're in good shape here now. If you want to check this repository out
anonymously you can do so as such:
cvs -d :pserver:anonymous@cvs.fedora.redhat.com:/cvs/fedora \
co fedora-security
The current plan is to create files called fe4 and fe5 to sit next to the
fc4 and fc5 files in this location. The format of fc[45] is currently
working, so I believe it's the correct way to go initially.
Those of you interested in being a part of the security response team will
need to send me your fedora account system username. I can then add access
and provide further instructions.
We will need a package manifest. Basically a file that tells us which
packages and versions we're currently shipping in extras. A tool to
generate this will also be needed since we'll want to update this file on a
regular basis. Given how fast Extras changes I think this will be the
easiest way to check if we currently ship package <foo>.
There have been a few scripts that have been brought to my attention for
this, unless someone else gets to it first, I'm going to create a "tools"
directory in CVS and add such a script.
Process needs to be documented on the fedoraproject wiki. Since we don't
currently have a process, this is the only thing done :)
The most important part of this will be making it easy to specify what we
expect of ourselves. I hope to have some time this weekend to clean up the
security wiki pages a bit.
Sadly I didn't get to this over the weekend. I'll do what I can this week.
At this point, there should be three primary focal points for the security
response team.
1) Tracking new issues
2) Tracking old issues
3) Documentation
#1 and #3 are entertaining tasks. #2 is going to be painful and horrible.
I'm not sure how far back we should go in CVE space. I guess as far back
as we can with people willing to do the work. These tasks do require a
manifest, which we don't technically have yet, but should soon.
Does this all sound sane to everyone else?
Thanks.
--
JB
9:40 a.m.
New subject: Fedora Security Response Team
On Tue, 2006-05-02 at 10:35 -0400, Josh Bressers wrote:
Those of you interested in being a part of the security response team
will
need to send me your fedora account system username. I can then add access
and provide further instructions.
'jkeating' is my username. Or it could be 'jkeating(a)redhat.com' not
sure.
Your plan does seem sane.
--
Jesse Keating
Release Engineer: Fedora
9:48 a.m.
New subject: Fedora Security Response Team
On Tuesday 02 May 2006 09:35, Josh Bressers wrote:
Those of you interested in being a part of the security response team
will
need to send me your fedora account system username. I can then add access
and provide further instructions.
ausil is my username
At this point, there should be three primary focal points for the
security
response team.
1) Tracking new issues
2) Tracking old issues
3) Documentation
#1 and #3 are entertaining tasks. #2 is going to be painful and horrible.
I'm not sure how far back we should go in CVE space. I guess as far back
as we can with people willing to do the work. These tasks do require a
manifest, which we don't technically have yet, but should soon.
Does this all sound sane to everyone else?
Thanks.
Sounds Sane to me
--
Regards
Dennis Gilmore, RHCE
Proud Australian
3:35 p.m.
New subject: Fedora Security Response Team
>
> We will need a package manifest. Basically a file that tells us which
> packages and versions we're currently shipping in extras. A tool to
> generate this will also be needed since we'll want to update this file on a
> regular basis. Given how fast Extras changes I think this will be the
> easiest way to check if we currently ship package <foo>.
There have been a few scripts that have been brought to my attention for
this, unless someone else gets to it first, I'm going to create a "tools"
directory in CVS and add such a script.
I just added a script which was written by Jason L Tibbitts III (it was a
bit help, thanks Jason). You can see it here if you wish:
http://cvs.fedora.redhat.com/viewcvs/fedora-security/tools/?root=fedora
Jason's original script relied on a local archive of things, this one grabs
what it needs remotely. It's not the fastest thing ever, but it should be
good enough for now.
% ./package-release nmh
Found package nmh in owners.list:
Distro: Fedora Extras
Desc: A mail handling system with a command line interface
Owner: bressers(a)redhat.com
CC:
Releases and versions:
3 1.1 13.fc3 /pub/fedora/linux/extras/3/SRPMS/nmh-1.1-13.fc3.src.rpm
3 1.1 14.fc3 /pub/fedora/linux/extras/3/SRPMS/nmh-1.1-14.fc3.src.rpm
4 1.1 13.fc4 /pub/fedora/linux/extras/4/SRPMS/nmh-1.1-13.fc4.src.rpm
4 1.1 14.fc4 /pub/fedora/linux/extras/4/SRPMS/nmh-1.1-14.fc4.src.rpm
5 1.1 18.fc5 /pub/fedora/linux/extras/5/SRPMS/nmh-1.1-18.fc5.src.rpm
dev 1.1 18.fc5 /pub/fedora/linux/extras/development/SRPMS/nmh-1.1-18.fc5.src.rpm
--
JB
8:11 a.m.
New subject: Fedora Security Response Team
Josh Bressers wrote:
I just added a script which was written by Jason L Tibbitts III (it
was a
bit help, thanks Jason). You can see it here if you wish:
http://cvs.fedora.redhat.com/viewcvs/fedora-security/tools/?root=fedora
Jason's original script relied on a local archive of things, this one grabs
what it needs remotely. It's not the fastest thing ever, but it should be
good enough for now.
% ./package-release nmh
Found package nmh in owners.list:
<<snip>>
5 1.1 18.fc5 /pub/fedora/linux/extras/5/SRPMS/nmh-1.1-18.fc5.src.rpm
dev 1.1 18.fc5 /pub/fedora/linux/extras/development/SRPMS/nmh-1.1-18.fc5.src.rpm
SO how hard would it be to re-tool this script to look up things in legacy's
repositories? (I haven't yet looked at the script in detail...)
-David
8:39 a.m.
New subject: Fedora Security Response Team
Josh Bressers wrote:
> I just added a script which was written by Jason L Tibbitts III (it was a
> bit help, thanks Jason). You can see it here if you wish:
> http://cvs.fedora.redhat.com/viewcvs/fedora-security/tools/?root=fedora
>
> Jason's original script relied on a local archive of things, this one grabs
> what it needs remotely. It's not the fastest thing ever, but it should be
> good enough for now.
>
> % ./package-release nmh
> Found package nmh in owners.list:
> <<snip>>
> 5 1.1 18.fc5 /pub/fedora/linux/extras/5/SRPMS/nmh-1.1-18.fc5.src.rpm
> dev 1.1 18.fc5
/pub/fedora/linux/extras/development/SRPMS/nmh-1.1-18.fc5.src.rpm
>
SO how hard would it be to re-tool this script to look up things in legacy's
repositories? (I haven't yet looked at the script in detail...)
It shouldn't be too hard. The bit where the file is displayed is sucked
off an ftp server.
--
JB
8:40 a.m.
New subject: Fedora Security Response Team
>>>> "DE" == Dave Eisenstein
<c438421(a)twinkie.homedns.org> writes:
DE> SO how hard would it be to re-tool this script to look up things
DE> in legacy's repositories?
There's not much to it, but it does extract information from the
owners.list file which wouldn't make much sense for Legacy (or Core,
for that matter). Without that you're basically looking through
directories for files with the right name.
DE> (I haven't yet looked at the script in detail...)
It's now on the order of 100 lines of perl after making everything
talk over the network to the FTP servers; nothing huge.
- J<
8:11 a.m.
New subject: Fedora Security Response Team
Josh Bressers wrote:
The current plan is to create files called fe4 and fe5 to sit next to
the
fc4 and fc5 files in this location. The format of fc[45] is currently
working, so I believe it's the correct way to go initially.
So is there a problem with creating and/or adding fc{3,2,1} rhl{7,9} files
here as well to track CVE issues with you all for Fedora Legacy issues?
If it's not a problem, I am wondering if any of you have any thoughts or
suggestions on how to go about generating such lists?
Those of you interested in being a part of the security response team will
need to send me your fedora account system username. I can then add access
and provide further instructions.
Probably would be a good idea to add me as well, if you don't mind, Josh,
since Fedora Legacy *is* security and critical updates to older distros.
That's all I and other Fedora Legacy workers do. My fedora account system
username is uh, "questor", <deisenst(a)gtw.net>. Thanks.
<snip>
At this point, there should be three primary focal points for the security
response team.
1) Tracking new issues
2) Tracking old issues
3) Documentation
#1 and #3 are entertaining tasks. #2 is going to be painful and horrible.
I'm not sure how far back we should go in CVE space. I guess as far back
as we can with people willing to do the work. These tasks do require a
manifest, which we don't technically have yet, but should soon.
Um ... since we've never started a list for Fedora Legacy for all the CVE's
that ever existed (or at least since the Fedora Legacy project has existed),
is the creation and maintenance of these going to be torturous and cumbersome?
Legacy tends to work on issues by sets of related CVE #s, opening one Legacy
Bugzilla ticket per .src.rpm package (or related packages) to handle all the
distros that a given (set of) CVE's address for that (those) package(s). We
also use package codes in the "Status Whiteboard" to indicate which distros
for a given package are affected by those CVE's. We therefore tend to
ignore the actual version tag at the top of a Bugzilla report (often setting
it to the legacy-specific value "unspecified") unless a vulnerability only
affects one of the 5 distros we maintain.
Due to this way of working with bugs, and to reduce duplication, my
temptation is to suggest that, if legacy may also maintain CVE status
file(s) there in CVS, for legacy's use, we just use one file (maybe name it
'legacy'?) with all the CVE entries, and mark each individual CVE line for
which particular distros that CVE affects (or at least seems to affect).
Doing this in lieu of maintaining 5 separate files with 5 separate
copies of all the CVE numbers would seem to be a big labor-saver. What do
you think, Jesse? Or anyone else?
Putting together a fairly complete list of all the CVE's and all the
packages that are vulnerable or fixed by all of these CVE's ... ugh, it
indeed sounds like a horrible task! Are there any plans or thoughts to have
something like "security days" whereby a bunch of us folks can get together
and do the work while yakking it up on an IRC channel, making the process at
least potentially a *little* more fun, and making it possible for us to get
to know one another better?
Does this all sound sane to everyone else?
Everything sounds sane to me, Josh. Thanks for taking the ball and running
with it in getting this stuff going. :-)
Warm regards,
David Eisenstein
9 a.m.
New subject: Fedora Security Response Team
So is there a problem with creating and/or adding fc{3,2,1} rhl{7,9} files
here as well to track CVE issues with you all for Fedora Legacy issues?
If it's not a problem, I am wondering if any of you have any thoughts or
suggestions on how to go about generating such lists?
If you have the information captured in bugzilla you may be able to extract
it from there. The descriptions MITRE provides for issues is prose, so
there isn't really a nice way to get what you need from there.
I have no complaints about tracking the Fedora Legacy distributions in CVS.
I think keeping things close together is wise. If we are tracking this
many distributions though, perhaps one file for each is not the right way
to go. Perhaps some thought and discussion is warranted.
Probably would be a good idea to add me as well, if you don't mind, Josh,
since Fedora Legacy *is* security and critical updates to older distros.
That's all I and other Fedora Legacy workers do. My fedora account system
username is uh, "questor", <deisenst(a)gtw.net>. Thanks.
Done.
>
> <snip>
>
> At this point, there should be three primary focal points for the security
> response team.
>
> 1) Tracking new issues
> 2) Tracking old issues
> 3) Documentation
>
> #1 and #3 are entertaining tasks. #2 is going to be painful and horrible.
> I'm not sure how far back we should go in CVE space. I guess as far back
> as we can with people willing to do the work. These tasks do require a
> manifest, which we don't technically have yet, but should soon.
Um ... since we've never started a list for Fedora Legacy for all the CVE's
that ever existed (or at least since the Fedora Legacy project has existed),
is the creation and maintenance of these going to be torturous and cumbersome?
The creation is painful as there are literally tens of thousands of CVE ids
per year. Once you're caught up things aren't as bad since the ids are
just a constant trickle of information.
Putting together a fairly complete list of all the CVE's and all the
packages that are vulnerable or fixed by all of these CVE's ... ugh, it
indeed sounds like a horrible task! Are there any plans or thoughts to have
something like "security days" whereby a bunch of us folks can get together
and do the work while yakking it up on an IRC channel, making the process at
least potentially a *little* more fun, and making it possible for us to get
to know one another better?
This isn't a half bad idea (what do others think?). At the very least perhaps an IRC
channel is in
order. I see #fedora-security already exists on Freenode, no doubt just
for this purpose :)
--
JB
10:04 a.m.
New subject: Fedora Security Response Team
On Wednesday 10 May 2006 09:00, Josh Bressers wrote:
> So is there a problem with creating and/or adding fc{3,2,1}
rhl{7,9}
> files here as well to track CVE issues with you all for Fedora Legacy
> issues?
>
> If it's not a problem, I am wondering if any of you have any thoughts or
> suggestions on how to go about generating such lists?
If you have the information captured in bugzilla you may be able to extract
it from there. The descriptions MITRE provides for issues is prose, so
there isn't really a nice way to get what you need from there.
a simple perl
script should be able to extract the info from the bugzilla
database and insert it into a text file. I did something kinda similar but
in reverse i extracted the component info from Fedora's describe
components page and inserted into Aurora's bugzilla database. it saved
much typing.
I have no complaints about tracking the Fedora Legacy distributions
in CVS.
I think keeping things close together is wise. If we are tracking this
many distributions though, perhaps one file for each is not the right way
to go. Perhaps some thought and discussion is warranted.
I think we should track
Legacy here. It serves the ultimate goal of having
one central location for Fedora Security. I see 3 ways to track the info
1) as we are one file per release perhaps merging extras and core into one
file. (not now but later)
2) use one file per CVE. has alot of files but you could have in it each
effected release
3) Time based rotation of files. List in a similar manner to currently done
but add the releases effected to the end and rotate files each
month/quarter/half year/full year
>
> Um ... since we've never started a list for Fedora Legacy for all the
> CVE's that ever existed (or at least since the Fedora Legacy project has
> existed), is the creation and maintenance of these going to be torturous
> and cumbersome?
The creation is painful as there are literally tens of thousands of CVE ids
per year. Once you're caught up things aren't as bad since the ids are
just a constant trickle of information.
Back tracking will be extremly painful.
and the further forward we move the
less neccesary it will become. for instance once Legacy drops FC1 supprot
there wont be much concern if older security ises were resolved or not.
> Putting together a fairly complete list of all the CVE's and
all the
> packages that are vulnerable or fixed by all of these CVE's ... ugh, it
> indeed sounds like a horrible task! Are there any plans or thoughts to
> have something like "security days" whereby a bunch of us folks can get
> together and do the work while yakking it up on an IRC channel, making
> the process at least potentially a *little* more fun, and making it
> possible for us to get to know one another better?
This isn't a half bad idea (what do others think?). At the very least
perhaps an IRC channel is in order. I see #fedora-security already exists
on Freenode, no doubt just for this purpose :)
I started #fedora-security back
when the SIG was first proposed Just for
this type of thing. the security days sounds like a great idea.
--
Regards
Dennis Gilmore, RHCE
Proud Australian
2:17 p.m.
New subject: Fedora Security Response Team
1) as we are one file per release perhaps merging extras and core into one
file. (not now but later)
This will depend on the outcome of the bizarre mating ritual that will no
doubt happen once core is freed.
2) use one file per CVE. has alot of files but you could have in
it each
effected release
This also complicates the issue of moving things forward. Right now, when
FE6 must be tracked, a 'cp fe5 fe6' is a pretty solid start.
3) Time based rotation of files. List in a similar manner to
currently done
but add the releases effected to the end and rotate files each
month/quarter/half year/full year
I don't think this is wise. The files will be rotated when EOL is reached.
Having everything in one easy to find place for each distribution is easier
IMO.
We can also just keep tracking things the way they currently are, but I
fear it won't scale. One entry, per package, per distribution. This fails
to scale with something like mozilla.
For each CVE id a mozilla application is assigned, we have to add a CVE id
for mozilla, thunderbird, firefox, seamonkey, in the FC[45], FE[45], and
all the legacy files (for those of you not counting on your fingers that
would be 16 lines added). This isn't ideal, but the files are great for
tracking, simply because each one contains a good set of information. If I
want to know what products CVE-2006-0123 affects, all I have to do is
'grep CVE-2006-0123 *'
I think the answer is tools. The data the tools output can be whatever we
want, this particular format being something I like. You might like
something different, which would be doable as it's all just information.
Ideally I should be able to visit a web page, or create a YAML file (or
some other format/process you prefer) which will note which versions of a
product and which packages are or are not vulnerable, why, then file
bugzilla bits for us automagically.
--
JB
6569
days inactive
6581
days old
security@lists.fedoraproject.org
17 comments
9 participants
participants (9)
-
Christian Iseli -
Dave Eisenstein -
David Eisenstein -
Dennis Gilmore -
Hans de Goede -
Jason L Tibbitts III -
Jesse Keating -
Josh Bressers -
Luke Macken