As everybody is no doubt aware, Fedora 7 is bringing a number of changes, one of which will be putting the burden of security on the Fedora Security Response Team. Right now it's basically the Red Hat Security Response Team working on Core, and not much of anything happening for Extras. This is going to change.
I'm going to be filing a request for some resources sometime this week. I have an IRC bot and an xmlrpc server that will initially run from there. The long term goal is to host the various security related tools that don't yet exist.
In the meantime, the task at hand should be to start tracking flaws for Fedora 7. What we usually would do at this point for core, is copy the fc6 file into fc7 in CVS. We then pour over the entries looking for questionable items. I'm thinking what we should do for Fedora 7, is merge the fe6 and fc6 files into a f7 (a better name is welcome) file, then start working through this file. We've never done this in a distributed manner before, so ideas are welcome.
On Mon, Apr 02, 2007 at 07:31:19PM -0400, Josh Bressers wrote:
questionable items. I'm thinking what we should do for Fedora 7, is merge the fe6 and fc6 files into a f7 (a better name is welcome) file, then start working through this file. We've never done this in a distributed
The disttag is staying "fc#" -- makes sense to keep other things that way too.
start working through this file. We've never done this in a distributed manner before, so ideas are welcome.
Once the F7 file is initially created it really needs a request tracking system, like we use RT for internally. That way the "CVE new" mails (as well, probably, as F7 errata announcements) can go into the queue and allow anyone to pick it up, triage, and close it after committing the new F7 file.
Mark
On Tuesday 03 April 2007, Josh Bressers wrote:
As everybody is no doubt aware, Fedora 7 is bringing a number of changes, one of which will be putting the burden of security on the Fedora Security Response Team. Right now it's basically the Red Hat Security Response Team working on Core, and not much of anything happening for Extras. This is going to change.
Any updates on this? It looks to me as if things have changed for worse.
I haven't seen any other activity in CVS than my own updates to the fe* files. There's no merged f7 audit file, and nobody appears to be keeping fc* up to date either, and security related Bugzilla entries besides the ones I've filed (if there are any others, dunno) do not seem to be Cc'd to this list.
As of now, I'm suspending my efforts to routinely track CVE's and other sources until the situation becomes clearer. With the number of people even reporting issues and keeping CVS up to date (*one* commit in 2007 to fe* by someone besides me, in February, and none in fc* by anyone since May) being close to zero, and being the only one who does that not being what I "signed up" for, I don't think it would be responsible behaviour from me to keep doing it in the current circumstances. Full, timely coverage is simply way too much work, and casually doing it might give a false impression to users and maintainers that things would be properly tracked.
Any updates on this? It looks to me as if things have changed for worse.
As of today, yes, things are pretty much a mess. I take personal responsibility for this and also plan to address the issues.
I haven't seen any other activity in CVS than my own updates to the fe* files. There's no merged f7 audit file, and nobody appears to be keeping fc* up to date either, and security related Bugzilla entries besides the ones I've filed (if there are any others, dunno) do not seem to be Cc'd to this list.
Most bugzilla entries are not CC'd to this list. I'm not sure that's the right thing to do as it generates a lot of noise. The fc file is horribly behind, but there have been numerous Fedora Core bugs filed. One of the issues we have is that when two data sources are used, one will get neglected. In this instance for the Red Hat Security Response Team it's the fc file.
As of now, I'm suspending my efforts to routinely track CVE's and other sources until the situation becomes clearer. With the number of people even reporting issues and keeping CVS up to date (*one* commit in 2007 to fe* by someone besides me, in February, and none in fc* by anyone since May) being close to zero, and being the only one who does that not being what I "signed up" for, I don't think it would be responsible behaviour from me to keep doing it in the current circumstances. Full, timely coverage is simply way too much work, and casually doing it might give a false impression to users and maintainers that things would be properly tracked.
I don't blame you Ville, your effort has been noticed and is appreciated. Thanks for the work you've done.
Here is what's going to happen later today. (I was on holiday last week and there was a shitstorm of security issues over the past few months). I've been putting this off for too long now.
I'm going to merge the fc6 and fe6 files. There are a number of CVE ids that are missing from this file. I have a rather extensive private list that I'll merge into this list. The result is going to be an fc7 file that will need a lot of work.
How you can help.
Any help will be appreciated and accepted. Once the FC7 file exists, we will need to go through the CVE ids and identify which flaws need to be addressed. Some of the ids will be low hanging fruit that will only take a few minutes to verify. Other will take a long time and it's possible you will have to go through source. I'm not sure how to section off this file, anyone with any ideas?
For the F8 timeline I hope to see bugzilla used extensively for tracking CVE ids. There is now a security response queue which was created for this exact purpose. For F7 though, I'd rather see an ugly system than none at all. We shall worry about the future once we have a present.
Sorry and thanks.
On Mon, 11 Jun 2007 11:42:05 -0400 Josh Bressers bressers@redhat.com wrote:
...snip...
I don't blame you Ville, your effort has been noticed and is appreciated. Thanks for the work you've done.
Yeah, I have been lurking in this list for a while and I really appreciate your efforts Ville.
Here is what's going to happen later today. (I was on holiday last week and there was a shitstorm of security issues over the past few months). I've been putting this off for too long now.
I'm going to merge the fc6 and fe6 files. There are a number of CVE ids that are missing from this file. I have a rather extensive private list that I'll merge into this list. The result is going to be an fc7 file that will need a lot of work.
How you can help.
I've been wanting to help, but not sure of practices and procedures used.
Perhaps we could clarify a few things for me:
- Only security bugs with CVE's are tracked? What if we spot something that has no CVE?
- Should the filed bug have a CC to the list? I guess you mentioned this above. I think it's probibly a good idea so folks can see the progress of fixes.
- Is there any key for the format of the audit cvs files?
- Is there any acl on the audit files? Who is allowed to update those?
Any help will be appreciated and accepted. Once the FC7 file exists, we will need to go through the CVE ids and identify which flaws need to be addressed. Some of the ids will be low hanging fruit that will only take a few minutes to verify. Other will take a long time and it's possible you will have to go through source. I'm not sure how to section off this file, anyone with any ideas?
Well, if it will be listed in cvs, can't we just have folks go and update as they process?
For the F8 timeline I hope to see bugzilla used extensively for tracking CVE ids. There is now a security response queue which was created for this exact purpose. For F7 though, I'd rather see an ugly system than none at all. We shall worry about the future once we have a present.
Quite.
Sorry and thanks.
kevin
- Only security bugs with CVE's are tracked? What if we spot something
that has no CVE?
If it's something that is already public (for example some description of the flaw exists outside of bugzilla and it's obvious it's a security issue) then we can alert Mitre and they'll assign a name within a day or two.
If it's something that's not particularly public (for example someone reports an issue but not obvious it has security consequences) then I am a Candidate Naming Authority for CVE and can allocate a name to Fedora.
Thanks, Mark -- Mark J Cox / Red Hat Security Response Team
How you can help.
I've been wanting to help, but not sure of practices and procedures used.
Perhaps we could clarify a few things for me:
- Should the filed bug have a CC to the list? I guess you mentioned
this above. I think it's probibly a good idea so folks can see the progress of fixes.
While I'm personally not a fan of this, if people want it, we should probably do it.
- Is there any key for the format of the audit cvs files?=20
Not really, look at what's there to get an idea of how it goes.
- Is there any acl on the audit files? Who is allowed to update those?
Here is the current list:
avail | mjc,bressers,jorton,notting,sopwith,katzj,holtmann | fedora-security avail | lkundrak | fedora-security avail | jkeating,ausil,tibbs,kaboom,scop,questor | fedora-security
If you're willing to help, access can be granted.
Any help will be appreciated and accepted. Once the FC7 file exists, we will need to go through the CVE ids and identify which flaws need to be addressed. Some of the ids will be low hanging fruit that will only take a few minutes to verify. Other will take a long time and it's possible you will have to go through source. I'm not sure how to section off this file, anyone with any ideas?
Well, if it will be listed in cvs, can't we just have folks go and update as they process?
Ideally, yes. I however don't want people to duplicate work. I suspect the easiest way is going to be for someone to just mark a block of ids as what they're working on. Something like
**** bressers **** CVE blah blah blah ... ===> Lots of CVE ids here CVE blah blah blah **** bressers ****
Check in some bits to make it known you're on it, then start wading through the manure.
Thanks.
On Mon, 11 Jun 2007 13:24:34 -0400 Josh Bressers bressers@redhat.com wrote:
How you can help.
I've been wanting to help, but not sure of practices and procedures used.
Perhaps we could clarify a few things for me:
- Should the filed bug have a CC to the list? I guess you mentioned
this above. I think it's probibly a good idea so folks can see the progress of fixes.
While I'm personally not a fan of this, if people want it, we should probably do it.
Well, I find it nice to be able to see replies from maintainers that they are looking at it, or need more info, etc.
I don't know how much traffic it will end up being tho when there is more coverage. Might need re-evaluating if it's a gigantic pile.
- Is there any key for the format of the audit cvs files?=20
Not really, look at what's there to get an idea of how it goes.
ok.
- Is there any acl on the audit files? Who is allowed to update
those?
Here is the current list:
avail | mjc,bressers,jorton,notting,sopwith,katzj,holtmann | fedora-security avail | lkundrak | fedora-security avail | jkeating,ausil,tibbs,kaboom,scop,questor | fedora-security
If you're willing to help, access can be granted.
Sure, I can assist. My FAS account is kevin...
Well, if it will be listed in cvs, can't we just have folks go and update as they process?
Ideally, yes. I however don't want people to duplicate work. I suspect the easiest way is going to be for someone to just mark a block of ids as what they're working on. Something like
**** bressers **** CVE blah blah blah ... ===> Lots of CVE ids here CVE blah blah blah **** bressers ****
Check in some bits to make it known you're on it, then start wading through the manure.
Yeah, that could work. We could use a wiki page, but since the cvs file is there, it makes sense to me to just use that.
Thanks.
kevin
On Mon, 11 Jun 2007 13:24:34 -0400 Josh Bressers bressers@redhat.com wrote:
...snipp..
Ideally, yes. I however don't want people to duplicate work. I suspect the easiest way is going to be for someone to just mark a block of ids as what they're working on. Something like
**** bressers **** CVE blah blah blah ... ===> Lots of CVE ids here CVE blah blah blah **** bressers ****
Check in some bits to make it known you're on it, then start wading through the manure.
ok. Looking at the nice big pile you checked in, I think we might be served better by folks taking particular packages. Ie, if you are already examining a package for one CVE, it might be easier to just keep going on that package rather than switch to another one and have to pull up more cvs files, bugzilla, etc.
Here's the top 10 of the ones you just checked in today:
30 (php) 14 (helixplayer) 11 (tomcat) 8 (fedoradirectoryserver) 7 (flash-plugin) 7 (acroread) 6 (openoffice.org) 6 (kernel) 5 (xscreensaver) 5 (wu-ftpd)
Should all the flash-plugin, acroread and wu-ftpd ones be marked "ignore" since we don't ship them? Or removed?
Also, what level of scrutiny should we use in checking for fixes? If a changelog lists the CVE being fixed, mark it? Should we check the patch against upstream or other distros fix?
Thanks.
kevin
Oh.. I sent a reply to Kevin and did not sent to mailing list, resending...
Kevin Fenzi wrote, at 06/12/2007 12:04 PM +9:00:
ok. Looking at the nice big pile you checked in, I think we might be served better by folks taking particular packages. Ie, if you are already examining a package for one CVE, it might be easier to just keep going on that package rather than switch to another one and have to pull up more cvs files, bugzilla, etc.
Here's the top 10 of the ones you just checked in today:
30 (php) 14 (helixplayer) 11 (tomcat) 8 (fedoradirectoryserver) 7 (flash-plugin) 7 (acroread) 6 (openoffice.org) 6 (kernel) 5 (xscreensaver) 5 (wu-ftpd)
For xscreensaver, all CVE entries which were added today are for <4.18 and no longer affects FC-5+ xscreensaver (4.24<=)
Mamoru (xscreensaver maintainer)
On Tue, 12 Jun 2007 12:41:12 +0900 Mamoru Tasaka mtasaka@ioa.s.u-tokyo.ac.jp wrote:
Oh.. I sent a reply to Kevin and did not sent to mailing list, resending...
Kevin Fenzi wrote, at 06/12/2007 12:04 PM +9:00:
ok. Looking at the nice big pile you checked in, I think we might be served better by folks taking particular packages. Ie, if you are already examining a package for one CVE, it might be easier to just keep going on that package rather than switch to another one and have to pull up more cvs files, bugzilla, etc.
Here's the top 10 of the ones you just checked in today:
30 (php) 14 (helixplayer) 11 (tomcat) 8 (fedoradirectoryserver) 7 (flash-plugin) 7 (acroread) 6 (openoffice.org) 6 (kernel) 5 (xscreensaver) 5 (wu-ftpd)For xscreensaver, all CVE entries which were added today are for <4.18 and no longer affects FC-5+ xscreensaver (4.24<=)
Excellent news. ;)
I looked around briefly and xscreensaver seems to not really note when these things are fixed. Nothing in the changelog at jwz's site, or in your spec file changelog mention CVE's or security issues that I could see off hand. Or is there somewhere that I am not looking?
That makes it hard to verify things. ;(
You might consider adding info about security fixes to your changelog, and/or talk to Jamie and see if he is willing to note them in the upstream changelog.
Thanks for the info.
Mamoru (xscreensaver maintainer)
kevin
ok. Looking at the nice big pile you checked in, I think we might be served better by folks taking particular packages. Ie, if you are already examining a package for one CVE, it might be easier to just keep going on that package rather than switch to another one and have to pull up more cvs files, bugzilla, etc.
This does make sense, yes. I'm also rather sure that most of the mess I checked in today is fixed in F7, so this would speed things up for the very reasons you mention.
Here's the top 10 of the ones you just checked in today:=20
30 (php) 14 (helixplayer) 11 (tomcat) 8 (fedoradirectoryserver) 7 (flash-plugin) 7 (acroread) 6 (openoffice.org) 6 (kernel) 5 (xscreensaver) 5 (wu-ftpd)Should all the flash-plugin, acroread and wu-ftpd ones be marked "ignore" since we don't ship them? Or removed?=20
Mark them ignore, no ship. The advantage to keeping the id in the file is that if we ever do start shipping those things, we have a list of things to look at.
Also, what level of scrutiny should we use in checking for fixes?=20 If a changelog lists the CVE being fixed, mark it? Should we check the patch against upstream or other distros fix?=20
If the changelog mentions it we should be inclined to believe it. If there is a reason to cast doubt we can invest more time.
Thanks.
On Tue, 12 Jun 2007 07:17:01 -0400 Josh Bressers bressers@redhat.com wrote:
ok. Looking at the nice big pile you checked in, I think we might be served better by folks taking particular packages. Ie, if you are already examining a package for one CVE, it might be easier to just keep going on that package rather than switch to another one and have to pull up more cvs files, bugzilla, etc.
This does make sense, yes. I'm also rather sure that most of the mess I checked in today is fixed in F7, so this would speed things up for the very reasons you mention.
Yeah. ;(
Should all the flash-plugin, acroread and wu-ftpd ones be marked "ignore" since we don't ship them? Or removed?=20
Mark them ignore, no ship. The advantage to keeping the id in the file is that if we ever do start shipping those things, we have a list of things to look at.
True. ok, marked. Feel free to tweak if I got any formatting wrong.
Also, what level of scrutiny should we use in checking for fixes?=20 If a changelog lists the CVE being fixed, mark it? Should we check the patch against upstream or other distros fix?=20
If the changelog mentions it we should be inclined to believe it. If there is a reason to cast doubt we can invest more time.
Makes sense. I just checked in my first quick pass on krb5... if anyone would like to check that over and confirm that I am processing things right that would be great.
Thanks.
kevin
Kevin Fenzi wrote:
- Should the filed bug have a CC to the list? I guess you mentioned
this above. I think it's probibly a good idea so folks can see the progress of fixes.
I don't think we want to do this. Imagine someone files a bug to us with an embargo date of: future. Someone reading the list archives could easily get that information and release it to the public ahead of the embargo date. Essentially, by cc:ing a public list, we broke the embargo ourselves.
We want to honor embargos as much as possible, so we can continue being in good favor with those who give us advance notification. Additionally, when we are planning to release something on a given day, and it turns out to get leaked, we have to scramble much more quickly. Not good for many reasons.
On Mon, 11 Jun 2007 14:55:43 -0400 Christopher Aillon caillon@redhat.com wrote:
Kevin Fenzi wrote:
- Should the filed bug have a CC to the list? I guess you mentioned
this above. I think it's probibly a good idea so folks can see the progress of fixes.
I don't think we want to do this. Imagine someone files a bug to us with an embargo date of: future. Someone reading the list archives could easily get that information and release it to the public ahead of the embargo date. Essentially, by cc:ing a public list, we broke the embargo ourselves.
Agreed, to be avoided. Can't we simply not add CC to the bugs that are under an embargo? Or is there no simple way to tell?
We want to honor embargos as much as possible, so we can continue being in good favor with those who give us advance notification. Additionally, when we are planning to release something on a given day, and it turns out to get leaked, we have to scramble much more quickly. Not good for many reasons.
Absolutely.
At the same time, bugs that are public already I think it's good to see progress on the list/in bugzilla. We may spot cases where maintainers need help, want more info, or otherwise could use input from the security list.
Just my 2cents tho... if it's decided not to CC the list thats fine too.
kevin
On Tuesday 12 June 2007, Kevin Fenzi wrote:
At the same time, bugs that are public already I think it's good to see progress on the list/in bugzilla. We may spot cases where maintainers need help, want more info, or otherwise could use input from the security list.
+1, and we avoid doing duplicate work ourselves when we see someone else has already reported issues we're about to investigate/report.
But of course, embargoed issues should not be leaked anywhere in public. Apart from just not Cc'ing the list and marking the bug as confidential in Bugzilla with a clear note why it is being marked confidential, I don't have many ideas how to handle that. Not that I would personally currently have access to non-public issues anyway ;)
security@lists.fedoraproject.org
-
Christopher Aillon -
Josh Bressers -
Kevin Fenzi -
Mamoru Tasaka -
Mark Cox -
Matthew Miller -
Ville Skyttä