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?
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.
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" == Josh Bressers bressers@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@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<
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
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
bressers@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...)
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.
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@redhat.com' not sure.
Your plan does seem sane.
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.
- Tracking new issues
- Tracking old issues
- 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
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@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
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
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.
"DE" == Dave Eisenstein c438421@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<
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@gtw.net. Thanks.
<snip>
At this point, there should be three primary focal points for the security response team.
- Tracking new issues
- Tracking old issues
- 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
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@gtw.net. Thanks.
Done.
<snip>
At this point, there should be three primary focal points for the security response team.
- Tracking new issues
- Tracking old issues
- 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 :)
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.
- 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.
- 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.
- 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.
security@lists.fedoraproject.org