Notes from the discussions.. Risk assessments :-- * Risk assessments should be done early, at least within a few days of the issue being submitted * Agreed that risk assessment need improving * The Target Date (TD) should depend on risk * A Risk Assessment Team (RAT) should be formed * Issue should be initially assigned to a RAT member for Risk assessment * At least 2 members of the RAT should look at each issue - Possibly a developer, a deployment person, and a system Administrator * Exact form of Risk Assessment is not fixed. - Might look at extending Common Vulnerability Scoring System to take account of Grid factors. Might even get a paper out of this * When the Risk assesment is completed it is no longer the responsibility of the RAT member, but is assigned to an appropriate developer After the risk assessment:-- * When the Risk assessment is complete, the RAT members' job is done * It is then the responsibility of the developer, and the developer knows information on the issue will be released on the TD whether fixed or not * The developer to who the issue is assigned is responsible for writing information on the issue, e.g. what circumstances it can be exploited in, including which of the supported versions it is a problem with. Web page:-- * Initially, simply make it accessible to anyone with a certificate - At Manchester, controlled by GridSite - Some wanted the summary to not be Cert controlled, but I suggest for now should just have the whole thing accessible by those with appropriate CERT Information Release:-- * Broadly agree that we can move to releasing information on TD (whether fixed or not) if management approves - note that management should approve the principle of releasing information on TD, not approve each issue * Release should eventually be on an open web page. Issues already present:-- * Those that are closed (i.e. in LCG 2.7) we do nothing - we don't try and improve description of a problem even if some sites are still running * Those that are open - allocate to RAT members - proceed as for new issues - possibly I'll list the ones I think are more important, and suggest we try the new process with these first. Setting Target Date:-- * How to set a TD is not fully defined. - Probably won't be fully defined until we have established the RAT. * The Development Cluster leaders should be in the RAT, and they may have an impact on the TD, at least in the coming months - probably set longer target dates initially. Ss time goes on, maybe shorter target dates will be set * It is agreed that fixing a vulnerability issue should be given higher priority than new functionality - recognised that manpower is finite, and it may not be possible to fix an issue by TD, in which case another solution must be sought which may be to turn off the service Deployment issues:-- * Agree need to be able to get a fix out without waiting months, as is often the case at present. * Possibly through Quick Fix - or whatever the EGEE2 mechanism is * Set JRA1 mirror bugs to critical if reach TD, will need them to be set to critical before they reach TD so that * Some sites need to update more quickly than they have in the past and we need a way of exerting pressure for them to do so - Possibly if information is public this might exert pressure? GSVG membership:-- * Not throwing people out initially * Possibly in the future inactive people where there is no obvious reason for them to remain members may be removed. Other points * EGEE licence accepts no liability for the S/W - but we shouldn't keep issues we are aware of that we can't fix in a list indefinately, they need to be dealt with in a responsible way * Need a way of reporting a potential issue that is easier than submitting a Savannah bug. - Have a Vulnerability reporting E-mail address. (anyone can report an issue through Savannah, they do not need a Savannah account let alone be a member of the group.) * People are broadly happy with the plan for transition Not agreed - but suggested by me since:-- * If TD reached and developer has not written the summary, the developer is told to do this within 1 working day. If they do not, whatever information available is released * If an issue is considered high risk, yet hard to fix, then an alternative solution will have to be sought - Consider turning off service - Consider fix that reduces functionality, e.g. for the R-GMA pong servlet problem * RAT members may be consulted to approve the fix, or what is done to mitigate the problem.