1 |
El mié, 12-09-2012 a las 20:29 +0200, Jeroen Roovers escribió: |
2 |
> On Wed, 12 Sep 2012 19:59:01 +0200 |
3 |
> Pacho Ramos <pacho@g.o> wrote: |
4 |
> |
5 |
> > Hello |
6 |
> > |
7 |
> > Currently, package maintainers are CCed to security bugs when their |
8 |
> > are needed. The problem is that, once maintainers add a fixed version |
9 |
> > and tell security team they are ok to get it stabilized, maintainers |
10 |
> > are kept CCed until bug is closed by security team. This usually means |
11 |
> > getting a lot of mail after some time when security team discuss if a |
12 |
> > GLSA should be filled or not, if security bot adds some comment... |
13 |
> > some of that comments are applied to really old bugs that need no |
14 |
> > action from maintainers. |
15 |
> |
16 |
> So you would want to be re-CC'd when it is time to remove the vulnerable |
17 |
> versions, I guess. |
18 |
|
19 |
Personally, I have never been asked by them to remove old vulnerable |
20 |
versions (and this refers to bugs I get from gnome and dotnet herds) |
21 |
|
22 |
> |
23 |
> Also, I have problems with stating "getting too much mail" as the |
24 |
> actual problem. |
25 |
|
26 |
The problem is that one and, also, getting a comment months after the |
27 |
fixed version was stabilized with a comment like "GLSA vote = no" or |
28 |
similar. That comment is only useful to security team. |
29 |
|
30 |
> Perhaps your brain or your computer can smartly filter |
31 |
> them out? |
32 |
|
33 |
Perhaps things can be enhanced to not send useless mails that will need |
34 |
to get removed just after they are get, this is pretty annoying when I |
35 |
fetch a ton of mails after being out during August. |
36 |
|
37 |
> |
38 |
> > Maybe would be interesting to change the policy to unCC maintainers |
39 |
> > again when their action is no longer required. |
40 |
> |
41 |
> You can un-CC yourself. I don't see why security@ should be doing the |
42 |
> legwork. |
43 |
> |
44 |
> |
45 |
|
46 |
It shouldn't be so hard to do, they can do it just when they CC arches, |
47 |
instead of relaying some random team member to do it himself once a |
48 |
useless message is received |
49 |
|
50 |
> jer |
51 |
> |
52 |
> |