Extras Security Policy

[Hans de Goede]

Warren Togami wrote:
> Ralf Corsepius wrote:
> 
>>
>> IMO, the problem reaches deeper: FE entirely lacks a post-release QA
>> policy.
>>
>> Once a package has entered CVS, maintainers have all kind of freedom to
>> commit all kind of foolishness they want to commit ;)
>>
> 
> The old Fedora.us Extras enforced QA for every package update, but it 
> quickly became apparent that it was a huge waste of time and effort when 
> both are in short supply.
> 
> If a maintainer decides to commit all kinds of foolishness to their own 
> packages they can be warned, and if they continue we can easily pull 
> their CVS access.  It has not been a problem yet, but we can deal with 
> it if it does happen.
> 
> Warren Togami
> wtogami at redhat.com
> 

This thread is not going in the direction I intended it to go. Here's
the direction I'm thinking about:

For the review process add a security check (besides the upstream
  matching source) think about:
-checking for suid / sgid
-checking rpm scriptlets for weird things (tmp races, adding / removing
  users, etc.)
-probably more
-These should be placed high on the what todo when reviewing list,
  I personally scan very quickly over the past part (all the small
  nitpicks) of the list, one could argue it is too long and needs
  trimming.

Besides that we need a clear security policy to be written and approved
by fesco:

We really need an FE security team which wathces over FE's security aspects.

The procedure I'm thinking about is:
1) Watch for security notices from the usual sources
2) once a notice has been received mail the maintainer of the package
  that he should take urgent action
3) remind him after 3 days
4) remove the package from extras after 7 days, unless the maintainer
  has posted a message that he is working on this and has requested
  aditional  time, in that case remove the package after 14 days.
5) replace removed packages with an empty package with virtual provides
  for libs and scripts which says disabled because of security reasons
  for bins, and ofcourse a higher EVR.

Steps 1,2 and 3 should be automated by a script which tries to match 
names from the usual sources with FE and FC names, if a security notice 
can't be matched only then the FE security team should be mailed by this 
script that it can't match the security notice to a package automagicly, 
maintainers of packages which get a wrong match should have someway of 
telling the script to change the package.

Steps 4 and 5 should be initiated by the script by telling the FE 
security team that a security issue hasn't been fixed before the 
deadline, and then be handled by the descretion of the security team.

This may all sound a bit strong. but security is vital and because of 
the human involvement in step 4/5 this can all be done in a reasonable 
way, iow if a security issue is very minor the FE security team can of 
course decide to give the maintainer more time.

Regards,

Hans


p.s.

I'm in no way volunteering todo any of the work this will cause, not 
because I don't want to, but because I don't have the time.