Merging Core and Extras affecting security updates

[David Eisenstein]

Pavel Kankovsky wrote:
> On Tue, 16 Jan 2007, Josh Bressers wrote:
> 
>> Initially, we're going to ignore embargoed issues.  Every time a security
>> conversation comes up, people start creating overly complex processes to
>> handle them.  Once there is a concrete team and process, this can be
>> investigated.  In the meantime, we'll just deal with issues once they're
>> public.
> 
> The process is quite straightforward imho:
> 
> 1. Data acquisition
>    - keep track of vulnerabilities
>      - CVE (a good start but it should not be the only source of data)
>      - vulnerability databases (Bugtraq, OSVDB, Secunia...)
>      - mailing lists (Bugtraq, Full-disclosure, Vendor-sec...)
>      - other distros (they might have caught something we missed)
>      - Oval?
>    - weed out bogus reports (false reports, issues for MS Windows...)
>    - merge duplicate reports
>    - update existing reports when needed (exploit availability...)
> 
> 2. Triage
>    - assess new and updated reports
>      - eliminate irrelevant reports (package not included in distro...)
>      - assign score to relevant reports (see below)
>    - reassess reports considered irrelevant when they become relevant
>        (new package added to distro...)
>    - prioritize reports according to their score
> 
> 3. Remediation
>    - select a report/issue to work on
>    - find or develop patches
>    - check whether the patches fix the vulnerabilities
>    - deploy fixed packages
> 

It has been awhile since I have done much here.  Got lots of questions.

My concern here is how does someone new to this process come about 
fairly easily and quickly knowing the status of any given vulnerability? 
  And how does someone know where to pitch in?

How many security issues might we have that could be open at the same time?

In order for any kind of orderly work to get done, a diverse and 
geographically-spread team would need to know what area of work needs 
the most work, and how to find out what issues are ones that they can 
work on, plus some way of flagging issues so someone else five minutes 
later signing on the the system to do some work won't start working on 
the very same thing (avoiding duplication of effort, if possible).

If we have, for example, people identifying issues -- how do we make it 
so a team of three identifiers don't identify the same issue three 
times?  (Or is that not a problem?)  Do we have a quick 'n dirty way of 
telling Joe Blow, a fellow scanning the Internet for vulnerabilities, 
that CVE-2007-yyyy is already in the database and needs triage (which I 
assume means "prioritization" = do we worry about this flaw today, 
tomorrow, or next Wednesday)?  Or of telling John Q. Public that 
CVE-2007-xxxx has been triaged and now needs patches to be found and 
published somewhere for Jim-Billy Bobb to go into the package CVS and 
build a new package?  How do we know when who does what and who has 
access to which information where to get work done?

And how does the QA process fit in with all of this?  Er, do we have 
some kind of package QA process for security vulnerabilities?  Would 
community members be welcome to pitch in on this if there is a QA 
process in place?

A good start might be a breakdown for those of us here who don't know -- 
who *now* does what for Core packages and for extras packages?  What 
does a security issue look like walked through the entire process, from 
identifying the vulnerability to the release of a fixed package?  What 
does the process *now* look like and how do Red Hat people envision 
opening up the process to let others in?  How is information going to be 
shared outside of the Security Response Team so it will be able to be 
efficiently known about by your community contributors (excluding 
embargoed issues, of course, for now)?  And are embargoed issues for 
former core packages now going to be ignored until the embargo is 
lifted, or are they going to be able to be worked on by trusted 
individuals inside Red Hat while embargoed, just as they are now?

If today I wanted to start being a security bug watcher, where do I 
report them?  Bugzilla?  Or is there a person or a group of people that 
already does this as a paid job inside of Red Hat?

Does the Fedora Security Team maintain a database (or "flat file") 
stored out in a Fedora CVS server somewhere that indicates status of any 
given CVE issue?  If it is there, is the "how to use it" documented 
anywhere?   Is manipulating this flat file the best way to get security 
bugs "into the system" for review?

If there are things that people know tacitly how to do, I would be more 
than happy to help document current processes.

Is there any estimate of an ideal level of manpower doing things?  And 
what levels of expertise are needed for each of the security tasks, 
especially when dealing with former Core packages by community members?

Thanks.

		-David