Extras Security Policy
Hans de Goede
j.w.r.degoede at hhs.nl
Thu Sep 8 09:00:14 UTC 2005
Warren Togami wrote:
> Ralf Corsepius wrote:
>> IMO, the problem reaches deeper: FE entirely lacks a post-release QA
>> 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
-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
Besides that we need a clear security policy to be written and approved
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.
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.
More information about the fedora-extras-list