| 1 |
On 03/12/2017 11:05 PM, Alexis Ballier wrote: |
| 2 |
>> The severity levels and timelines are already defined in the |
| 3 |
>> referenced vulnerability treatment policy. We might be able to |
| 4 |
>> incorporate this suggestion by stronger reference to that for |
| 5 |
>> timeline, but in the end that should be the internal policy anyways. |
| 6 |
> |
| 7 |
> To me, this is the only thing that is *not* internal here. |
| 8 |
> |
| 9 |
> You have a target delay X. What happens after X expires ? After 2X ? |
| 10 |
> 10X ? When is it right for sec. team to intervene ? When is it right |
| 11 |
> for sec. team to intervene after maintainer has asked for a delay ? When |
| 12 |
> is it right for sec. team to intervene against maintainer wishes ? |
| 13 |
> |
| 14 |
> I'm pretty sure you have a good idea of when sec. team should act, and |
| 15 |
> you're right in the sense that severity analysis does not belong to the |
| 16 |
> GLEP, but something referencing your treatment policy and explicitly |
| 17 |
> stating in the GLEP that (any member of) sec. team is allowed to take |
| 18 |
> action after some multiple (possibly one) of the target delay would be |
| 19 |
> more clear and avoid entirely having the lead to take a decision every |
| 20 |
> time. |
| 21 |
|
| 22 |
makes sense, will try to write up some more info on this in GLEP, while |
| 23 |
still referencing the vulnerability treatment policy for the actual |
| 24 |
information as that needs to be possible to update from time to time. |
| 25 |
|
| 26 |
-- |
| 27 |
Kristian Fiskerstrand |
| 28 |
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net |
| 29 |
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 |
Archives