1 |
Rich Freeman posted on Mon, 26 Jan 2015 09:20:30 -0500 as excerpted: |
2 |
|
3 |
> Honestly, I think we should really reconsider the current GLSA policy. |
4 |
|
5 |
What's the next step, not to step on anyone's toes? It's going to take |
6 |
coordination, so get a sense of the council first and then see what the |
7 |
security team and archs think? Security team first, then archs and |
8 |
council? |
9 |
|
10 |
Or start a new thread here with a security proposal title and see where |
11 |
that goes first? |
12 |
|
13 |
Because it's nice to think we should reconsider current policy, and I |
14 |
obviously think so too, but way down in this thread as it is, this could |
15 |
easily get lost and nothing will change, at present. And that would be a |
16 |
shame. It might be that the changes we're talking have a fatal flaw, but |
17 |
if so, better to get a proposal out there and have it properly shot down, |
18 |
ideally with another proposal substituted, than to have it sink and never |
19 |
know what that fatal flaw was. |
20 |
|
21 |
Because, well, I shudder to think of the actual security of a publicly |
22 |
accessible installation if they're waiting on GLSAs, the way thinks are |
23 |
now. That being the case, it'd arguably be better not to even have the |
24 |
charade. Yes, have a security team and have them do the updates they are |
25 |
doing now. Just don't have GLSAs at the end. So people can't have a |
26 |
false sense of security relying on them. |
27 |
|
28 |
But if they can be fixed, say by sending the GLSA at first-to-stable or |
29 |
even stable-request, I think the GLSAs would actually be useful, and it |
30 |
seems you, at least, are of the same opinion. |
31 |
|
32 |
So where /does/ it go from here? |
33 |
|
34 |
-- |
35 |
Duncan - List replies preferred. No HTML msgs. |
36 |
"Every nonfree program has a lord, a master -- |
37 |
and if you use the program, he is your master." Richard Stallman |