6:31 p.m.
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.
--
JB
6:37 p.m.
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.
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
7:10 a.m.
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
5:31 a.m.
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.
10:42 a.m.
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.
--
JB
10:52 a.m.
On Mon, 11 Jun 2007 11:42:05 -0400
Josh Bressers <bressers(a)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
10:59 a.m.
- 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
12:24 p.m.
>
>
> 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.
--
JB
1:44 p.m.
On Mon, 11 Jun 2007 13:24:34 -0400
Josh Bressers <bressers(a)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
10:04 p.m.
On Mon, 11 Jun 2007 13:24:34 -0400
Josh Bressers <bressers(a)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
10:41 p.m.
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)
11:55 a.m.
On Tue, 12 Jun 2007 12:41:12 +0900
Mamoru Tasaka <mtasaka(a)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
6:17 a.m.
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.
--
JB
2:23 p.m.
On Tue, 12 Jun 2007 07:17:01 -0400
Josh Bressers <bressers(a)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
1:55 p.m.
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.
5:54 p.m.
On Mon, 11 Jun 2007 14:55:43 -0400
Christopher Aillon <caillon(a)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
12:45 p.m.
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 ;)
6152
days inactive
6232
days old
security@lists.fedoraproject.org
16 comments
7 participants
participants (7)
-
Christopher Aillon -
Josh Bressers -
Kevin Fenzi -
Mamoru Tasaka -
Mark Cox -
Matthew Miller -
Ville Skyttä