1 |
On Wed, Jul 6, 2016 at 7:48 AM, Anthony G. Basile <blueness@g.o> wrote: |
2 |
> |
3 |
> It doesn't matter, there is a problem here which needs to be addressed. |
4 |
> I'm complaining because we need to fix a problem in our workflow. It |
5 |
> sounds like K_F is working on a glep for that, which I applaud. |
6 |
> |
7 |
|
8 |
Is everybody here at least agreed that this particular situation was |
9 |
not handled well? That was my sense of it earlier in the thread, but |
10 |
it seems like we're trying to argue over whether it was. |
11 |
|
12 |
If so, then let's move forward with better policy/etc. One-offs don't |
13 |
concern me much. However, it seems pretty obvious to me that if a |
14 |
typical package is suspected of creating a world-readable log file the |
15 |
reaction shouldn't be to mask it before talking to the maintainer. |
16 |
About the only thing that should warrant something like that is |
17 |
something like an sshd bug that lets arbitrary remote attackers |
18 |
connect as arbitrary users without authentication, and then the |
19 |
solution shouldn't be just a mask, but also some kind of immediate |
20 |
announcement (which is something we lack - we issue GLSAs sometimes |
21 |
ages after something is fixed on x86/amd64). Granted, that should be |
22 |
news enough that people are getting the message in other ways unless |
23 |
it is Gentoo-specific. |
24 |
|
25 |
I believe we already have a security severity classification system of |
26 |
some kind with targeted response times, so maybe we can tie policy |
27 |
into that? |
28 |
|
29 |
Like I said, one mistake doesn't make a trend, and we shouldn't |
30 |
over-react to a mistake. However, the way to handle a mistake is for |
31 |
everybody to say "this was a mistake," not "you're the only person who |
32 |
has a problem with this." Let's just fix whatever broke (if it isn't |
33 |
already fixed) and move on. We don't need to defend mistakes. |
34 |
|
35 |
-- |
36 |
Rich |